Mysql57使用binary log恢复数据

 以下操作内容是建立在已经开启mysql57 binary log功能，并且是row模式前提下

开启 Mysql57开启binary log功能https://blog.csdn.net/sunwork888/article/details/129930865

binlog是二进制文件，普通文件查看器cat、more、vim等都无法打开，必须使用自带的mysqlbinlog命令查看。 

快速语句

#查看binlog功能是否开启 NO 为开启
show variables like 'log_bin';

#确认是开启binlog日志功能的row模式；
show variables like 'binlog_format';

#查看binlog日志列表
show master logs;

#查看具体binlog日志内容
#1.Format_desc：每个binlog文件总是以Format Description Event作为日志开始。
#2.Rotate：Rotate Event（Stop Event）作为结束。
#3.Table_map：表示INSERT、DELETE、UPDATE操作的表结构。
#4.Write_rows：插入记录。
#5.Update_rows：更新记录。
#6.Delete_rows：删除记录。
show binlog events in 'mysql_bin.000004';
show binlog events in 'mysql_bin.000004' from 123 limit 2,5;

#生成新的日志文件
#举例，每间隔一个小时，执行一次Flush logs;生成一个新的 binlog 文件。便于根据时间去找寻日志
Flush logs;

#查看日志文件路径
show variables like "%basedir%";

#使用mysqlbinlog获取出sql语句
mysqlbinlog --start-position=1935 --stop-position=2038 --database=testdb mysql_bin.000004 | mysql -uroot -p123456

mysqlbinlog --start-position=1935 --stop-position=2038 --database=testdb mysql_bin.000004 >testdbdelete.sql

#一定不要使用重置（清空）所有binlog日志 谨慎点
#reset master;

 

 

读懂日志

#show binlog events命令的格式
show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count];

#例子1
show binlog events in 'mysql_bin.000004';

#例子2
show binlog events in 'mysql_bin.000004' from 123;

#例子3
show binlog events in 'mysql_bin.000004' from 123 limit 2,5;

说明：

1. IN ‘log_name’：指定要查询的binlog文件名（如果省略此参数，则默认指定第一个binlog文件）；
2. FROM pos：指定从哪个pos起始点开始查起（如果省略此参数，则从整个文件的第一个pos点开始算）；
3. LIMIT【offset】：偏移量（默认为0）；
4. row_count：查询总条数（如果省略，则显示所有行）。

• 事件日志列说明

 

 说明：

1. Log_name：当前事件所在的binlog日志名称；
2. Pos：当前事件的开始位置，每个事件都占用固定的字节大小，结束位置(End_log_pos)减去Pos，就是这个事件占用的字节数。第一个事件位置并不是从0开始，而是从4开始。Mysql会通过文件中的前4个字节，来判断这是不是一个binlog文件。
3. Event_type：表示事件的类型；
4. Server_id：表示产生这个事件的mysql server_id，通过设置my.ini中的server-id选项进行配置（话说和我设置的server_id不一致）；
5. End_log_pos：下一个事件的开始位置；
6. Info：当前事件的描述信息。

• Row模式下的Event_type

Event_type事件说明

1. Format_desc：每个binlog文件总是以Format Description Event作为日志开始。
2. Rotate：Rotate Event（Stop Event）作为结束。
3. Table_map：表示INSERT、DELETE、UPDATE操作的表结构。
4. Write_rows：插入记录。
5. Update_rows：更新记录。
6. Delete_rows：删除记录。

恢复

系统：windows11

 mysql安装环境：D:\Program\mysql-5.7.37-winx64\data

方法一，熟知mysqlbinlog日志的运行逻辑，并且明确知道那个范围的日志，中的那段语句进行删除操作，执行删除操作前的语句来进行恢复

#恢复时关闭二进制日志
set sql_Log_bin=0;

#将日志的语句段落在数据库重新执行
mysqlbinlog --no-defaults --database=testdb --start-position=4 --stop-position=1790 ../data/mysql_bin.000004   | mysql -uroot -pqwe123

#恢复结束开启二进制日志
set sql_Log_bin=0;

举个例子，下图日志中红色一头一尾标记的是我新建了一个用户，然后修改，黄色部门是最后的删除。

注：因为是本地测试，预期内容恢复的比较理想，但是在生产库中，除非是把日志切成1小时或者是几小时的段落才可以，并且还需要根据丢失数据的范围来确定处理办法。

方法二，网上流传的将“mysql_bin.000004”日志转为sql语句文件，查找里面的删除语句段落，然后使用mysqlbinlog运行恢复（这种方法在实际过程是无法通过sql命令执行的，这种转sql方式应该是便于排查原因，确定语句段落，通过关键表关键数据定位）

无效方法、无效方法、无效方法

#日志转sql文件
mysqlbinlog --no-defaults -vv --start-position=4 --stop-position=2069 ../data/mysql_bin.000004 > ../data/bin_data.sql

打开的sql文件类似于下图

将红色段落删除

 运行MySQL 数据库 source 命令恢复或者使用界面画工具运行恢复

# mysql -u username -P [dbname] < filename.sql
# username 表示用户名称；
# dbname 表示数据库名称，该参数是可选参数。如果 filename.sql 文件为 mysqldump 命令创建的包含创# # 建数据库语句的文件，则执行时不需要指定数据库名。如果指定的数据库名不存在将会报错；
# filename.sql 表示备份文件的名称。
mysql -u root -p testdb < C:\all.sql

结果提示 

其他恢复工具或方法 

 例如：binlog2sql

 

其他遇到的问题 

问题1：“ERROR 1790 (HY000) at line 19: @@SESSION.GTID_NEXT cannot be changed by a client that owns a GTID. The client owns ANONYMOUS. Ownership is released on COMMIT or ROLLBACK.”，原因是恢复语句设置的--start-position=1935 --stop-position=2038不是一个完整的句子，如图，通过语句的规律我们会发现Query到Xid这算是一段语句，而这段话执行的是删除操作，即便我知道原因，修改完后。提示内容为“ERROR 1032 (HY000) at line 30: Can't find record in 'sys_user'”

将事件转为导出sql如下图