数据丢失是误删每一个数据库管理员和开发者都不愿面对的噩梦。然而，数据意外总是别慌帮忙难免，当不小心删除了重要的误删数据，如何才能迅速而有效地进行恢复呢？数据在数据库中有二进制日志 (Binlog)，它不仅记录了所有更改数据的别慌帮忙事件，还可以帮助将数据库恢复到任何一个特定的误删时间点。本篇文章将带您深入了解如何利用 Binlog 来应对数据丢失问题，数据在面对数据误删时不再慌张。别慌帮忙 启用 BinlogBinlog (二进制日志)的误删介绍在这里就不过多描述了，不了解 Binlog 的数据同学，可以前往GreatSQL用户手册中 GreatSQL 日志章节查看：（https://greatsql.cn/docs/8.0.32-26/2-about-greatsql/4-3-greatsql-binary-log.html）。别慌帮忙 
为了利用 Binlog (二进制日志) 进行数据恢复，误删首先需要确保 Binlog 已经在 GreatSQL 数据库中启用并正确配置。数据以下是别慌帮忙详细的配置步骤、状态检查方法及 Binlog 文件的存储位置和命名规则。 配置 Binlog 的步骤找到并编辑 GreatSQL 配置文件my.cnf。该文件的路径因系统和安装方式不同而有所不同，常见路径包括 /etc/my.cnf、/etc/mysql/my.cnf。 添加或修改以下配置项： 复制[mysqld] log-bin=binlog binlog-format=ROW server-id=1033061.2.3.4. log-bin：指定启用 Binlog，亿华云并设置 Binlog 文件的基本名称。这里使用 binlog 作为前缀。binlog-format：设置 Binlog 的记录格式。推荐使用 ROW 格式，因为它记录的是行级别的变更，更详细和准确。server-id：为服务器设置唯一的 ID，必须设置该选项才能启用 Binlog。对于单个服务器，任何正整数都可以。对于主从复制环境，确保每个服务器的 server-id 唯一。推荐 Binlog 配置但关于 Binlog 的配置还不止这些，在 GreatSQL 推荐 my.cnf 模板(https://greatsql.cn/docs/8.0.32-26/3-quick-start/3-4-quick-start-with-cnf.html)中还有以下几个关于 Binlog 的配置。 复制$ cat /etc/my.cnf |grep bin sync_binlog = 1 binlog_cache_size = 4M max_binlog_cache_size = 2G max_binlog_size = 1G #控制binlog总大小，避免磁盘空间被撑爆 binlog_space_limit = 500G binlog_rows_query_log_events = 1 binlog_expire_logs_seconds = 604800 binlog_checksum = CRC321.2.3.4.5.6.7.8.9.10. sync_binlog = 1配置 GreatSQL 每次提交事务后都将 binlog 同步到磁盘。确保在系统崩溃时不会丢失已提交的事务，但可能会略微影响性能。同时配合innodb_flush_log_at_trx_commit=1即所说的双1，这是最安全的设置。免费信息发布网binlog_cache_size = 4M设置 Binlog 缓存大小为 4MB。当事务中的 SQL 语句较多时，事务的所有更改会被暂时保存在 Binlog 缓存中，然后一次性写入 Binlog 文件。max_binlog_cache_size = 2G设置 Binlog 缓存的最大大小为 2GB。这限制了单个事务可以使用的 Binlog 缓存大小，防止过大的事务占用过多内存。max_binlog_size = 1G设置单个 Binlog 文件的最大大小为 1GB。当 Binlog 文件达到此大小时，GreatSQL 会自动创建一个新的 Binlog 文件。这有助于管理和分割日志文件，使其更易于处理和备份。binlog_space_limit = 500G设置 Binlog 文件的总存储空间限制为 500GB。如果 Binlog 文件的总大小超过此限制，GreatSQL 会自动删除最旧的 Binlog 文件。这可以防止 Binlog 文件占用过多磁盘空间。binlog_rows_query_log_events = 1启用 Binlog 中的行查询日志事件。这将记录生成的行更改时的原始 SQL 语句，有助于调试和审计。binlog_expire_logs_seconds = 604800设置 Binlog 文件的站群服务器过期时间为 604800 秒（7 天）。超过此时间的 Binlog 文件将自动删除。这有助于管理存储空间并限制 Binlog 文件的数量。binlog_checksum = CEC32控制二进制日志 (binlog) 文件的校验和机制。启用 CRC32 校验和，以确保 Binlog 文件的数据完整性和正确性配置完成后需要重启 GreatSQL 服务，使配置生效； 复制$ systemctl restart greatsql1. 检查 Binlog 状态配置完 Binlog 并重启 GreatSQL 服务后，可以通过以下方法检查 Binlog 是否已正确启用； 登录 GreatSQL 并执行以下命令； 检查 Binlog 启用状态 复制greatsql> SHOW VARIABLES LIKE log_bin; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | log_bin | ON | +---------------+-------+ 1 row in set (0.00 sec)1.2.3.4.5.6.7. 如果返回结果为 ON，表示 binlog 已启用。 检查 Binlog 格式 复制greatsql> SHOW VARIABLES LIKE binlog_format; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | binlog_format | ROW | +---------------+-------+ 1 row in set (0.01 sec)1.2.3.4.5.6.7. 确保 Binlog 格式为 ROW； 查看 Binlog 文件列表 复制greatsql> SHOW BINARY LOGS; +---------------+-----------+-----------+ | Log_name | File_size | Encrypted | +---------------+-----------+-----------+ | binlog.000037 | 2347 | No | | binlog.000038 | 220 | No | | binlog.000039 | 703 | No | | binlog.000040 | 428473707 | No | +---------------+-----------+-----------+ 4 rows in set (0.00 sec)1.2.3.4.5.6.7.8.9.10. 该命令将列出所有当前存在的 Binlog 文件及其大小； Binlog 文件的存储位置和命名规则存储位置：Binlog 文件的存储位置通常由 log-bin 选项的值和 GreatSQL 数据目录共同决定。如果在 my.cnf 中未指定路径，binlog 文件会存储在 GreatSQL 数据目录下。 可以通过以下命令查看 GreatSQL 数据目录： 复制greatsql> SHOW VARIABLES LIKE datadir; +---------------+-----------------+ | Variable_name | Value | +---------------+-----------------+ | datadir | /data/GreatSQL/ | +---------------+-----------------+ 1 row in set (0.00 sec)1.2.3.4.5.6.7. 如果 log-bin 选项指定了路径，则 binlog 文件存储在该路径下。例如： 复制log-bin=/data/GreatSQL/binlog1. 命名规则：Binlog 文件名由 log-bin 选项的值和一个数字序列组成。例如，如果 log-bin 设置为 binlog，则生成的 binlog 文件名类似于 binlogn.000001、binlog.000002 等。 序列号是自动递增的，当一个 Binlog 文件达到最大大小（由 max_binlog_size 变量控制）时，GreatSQL 会创建一个新的 Binlog 文件，并将序列号递增。 模拟数据误删场景此次测试环境情况如下： 数据库：GreatSQL 8.0.32-26操作系统：Linux myarch 6.6.3-arch1-1 x86_64 GNU/Linux创建测试数据创建一个testdb库和employees表 复制greatsql> CREATE DATABASE testdb; Query OK, 1 row affected (0.01 sec) greatsql> USE testdb; Database changed greatsql> CREATE TABLE employees ( -> id INT AUTO_INCREMENT PRIMARY KEY, -> name VARCHAR(100), -> position VARCHAR(100), -> salary DECIMAL(10, 2) -> ); Query OK, 0 rows affected (0.07 sec)1.2.3.4.5.6.7.8.9.10.11.12.13. 并插入几条示例数据 复制greatsql> INSERT INTO employees (name, position, salary) VALUES (Alice, Manager, 60000.00), (Bob, Developer, 50000.00), (Charlie, Analyst, 40000.00), (greatsql, DBA, 66666.00); Query OK, 4 rows affected (0.05 sec) Records: 4 Duplicates: 0 Warnings: 01.2.3.4.5.6.7. 确认插入成功 复制greatsql> SELECT * FROM employees; +----+----------+-----------+----------+ | id | name | position | salary | +----+----------+-----------+----------+ | 1 | Alice | Manager | 60000.00 | | 2 | Bob | Developer | 50000.00 | | 3 | Charlie | Analyst | 40000.00 | | 4 | greatsql | DBA | 66666.00 | +----+----------+-----------+----------+ 4 rows in set (0.00 sec)1.2.3.4.5.6.7.8.9.10. 模拟数据误删除这时候要删除一条id=2的字段，而你却不小心删除了id=1的字段； 复制greatsql> DELETE FROM employees WHERE name = Alice;1. 查看表确认被误删除了； 复制greatsql> SELECT * FROM employees; +----+----------+-----------+----------+ | id | name | position | salary | +----+----------+-----------+----------+ | 2 | Bob | Developer | 50000.00 | | 3 | Charlie | Analyst | 40000.00 | | 4 | greatsql | DBA | 66666.00 | +----+----------+-----------+----------+ 3 rows in set (0.00 sec)1.2.3.4.5.6.7.8.9. 恢复数据的步骤在数据误删后，恢复数据的关键在于使用 GreatSQL 的二进制日志 (Binlog)。二进制日志记录了所有对数据库进行更改的操作，包括插入、更新和删除。因此，通过解析和重放 Binlog，可以恢复误删的数据。 确定误删的时间点记录下 GreatSQL 服务器的时间 复制greatsql> SELECT NOW(); +---------------------+ | NOW() | +---------------------+ | 2024-06-07 14:04:23 | +---------------------+ 1 row in set (0.00 sec)1.2.3.4.5.6.7. 记录下当前时间，以确定误删操作发生的大致时间范围。 查找相应的 Binlog 文件GreatSQL 的 Binlog 文件按时间顺序记录了所有对数据库的更改。你需要找到包含误删操作的 Binlog 文件。 复制greatsql> SHOW BINARY LOGS; +---------------+-----------+-----------+ | Log_name | File_size | Encrypted | +---------------+-----------+-----------+ | binlog.000037 | 2347 | No | | binlog.000038 | 220 | No | | binlog.000039 | 703 | No | | binlog.000040 | 428477097 | No | +---------------+-----------+-----------+ 4 rows in set (0.00 sec)1.2.3.4.5.6.7.8.9.10. 根据误删操作的大致时间，确定可能包含误删操作的 Binlog 文件。例如，如果误删操作发生在最近，可能需要检查 binlog.000040。 或使用SHOW MASTER STATUS命令确认当前正在使用的 Binlog； 复制greatsql> SHOW MASTER STATUS \G | 
喜欢
讨厌