MySQLbinlog日志02binlog日志用于数据恢复

Posted coe2coe

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了MySQLbinlog日志02binlog日志用于数据恢复相关的知识，希望对你有一定的参考价值。

 

本系列博客主要介绍mysql数据库的binlog日志的相关内容，这个系列的主题包括：

MySQLbinlog日志01binlog日志基本操作

MySQLbinlog日志02binlog日志用于数据恢复

MySQLbinlog日志03binlog日志字节码解析

MySQLbinlog日志04binlog日志字节码解析之二Write_Rows事件

 

 

本博客主要内容如下：

binlog日志的记录次序

binlog日志恢复数据

binlog数据库闪回工具myfash

 

 

 

1. binlog日志的记录次序

binlog日志是在事务提交时才写入到binlog日志文件中的，这就决定了binlog日志文件中的事件记录的次序由所在的事务提交的时间点的次序决定，而不是由SQL语句执行时的次序决定。因此binlog日志文件中，每个事务作为整体依据事务提交的次序排列，每个事件内部的各个事件按照时间次序先后排列。

按照以下操作可以验证上述结论。

先建立一个表：

mysql> create table t5 (id int auto_increment  primary key, who  varchar (10) , time  timestamp default current_timestamp on update current_timestamp ); 

Query OK, 0 rows affected (0.01 sec)

 

其中id字段表示记录被添加的次序， who字段表示那个事务添加的， time字段表示添加时的时间戳。

 

 

时间次序

事务A

事务B

1

begin;

 

2

insert into t5 (who) values (‘A‘);

 

3

 

begin;

4

 

insert into t5 (who) values (‘B‘);

5

insert into t5 (who) values (‘A‘);

 

6

 

insert into t5 (who) values (‘B‘);

7

 

commit;

8

insert into t5 (who) values (‘A‘);

 

9

commit;

 

 

 

执行结果如下：

mysql> select * from t5;

+----+------+---------------------+

| id | who  | time                |

+----+------+---------------------+

|  1 | A    | 2018-09-20 22:05:25 |

|  2 | B    | 2018-09-20 22:06:11 |

|  3 | A    | 2018-09-20 22:06:51 |

|  4 | B    | 2018-09-20 22:07:00 |

|  5 | A    | 2018-09-20 22:07:21 |

+----+------+---------------------+

5 rows in set (0.00 sec)

 

 

查看binlog事件信息：

 

使用以下命令也可以查看到这两个事务的全部binlog事件信息，同样可以观察到这个现象。

mysqlbinlog --base64-output=DECODE-ROWS mysql_binlog.000003 -vv 

也可以使用以下的命令仅仅查看binlog文件中的SQL语句信息(这些SQL语句不是通常的SQL语句，有比较独特的语法，不能独立执行)：

[[email protected] binlog]# mysqlbinlog   -v  --base64-output=DECODE-ROWS  mysql_binlog.000003 |grep -E -v  "^/*" |grep -E "^(###)|(COMMIT)"|sed ‘s/^### //g‘

INSERT INTO `binlog`.`t5`

SET

  @1=2

  @2=‘B‘

  @3=1537452371

INSERT INTO `binlog`.`t5`

SET

  @1=4

  @2=‘B‘

  @3=1537452420

COMMIT/*!*/;

INSERT INTO `binlog`.`t5`

SET

  @1=1

  @2=‘A‘

  @3=1537452325

INSERT INTO `binlog`.`t5`

SET

  @1=3

  @2=‘A‘

  @3=1537452411

INSERT INTO `binlog`.`t5`

SET

  @1=5

  @2=‘A‘

  @3=1537452441

COMMIT/*!*/;

 

 

可以看到事务B的全部事件排列在前面，然后才是事务A的全部事件。事务A内部的各个事件按照执行的时间次序排列，事务B也是。

经过实际验证，这个次序跟事务隔离级别没有关系，在READ COMMITTED和REPEATABLE READ隔离级别下都是相同的结果。

 

通过这个操作过程，可以得出3个结论：

（1）事务提交的次序决定事务的事件数据在binlog日志文件中的先后次序，

（2）事务内部的所有事件集中在一起，不同事务的事件不会交叉出现在binlog日志文件中。

（3）事务内部的所有事件按照时间次序排列。

 

 

2. binlog日志恢复数据

 

假设先执行了以下的操作：

 

mysql> desc t7;

+-------+-------------+------+-----+-------------------+-----------------------------+

| Field | Type        | Null | Key | Default           | Extra                       |

+-------+-------------+------+-----+-------------------+-----------------------------+

| id    | int(11)     | NO   | PRI | NULL              | auto_increment              |

| who   | varchar(10) | YES  |     | NULL              |                             |

| time  | timestamp   | YES  |     | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP |

+-------+-------------+------+-----+-------------------+-----------------------------+

3 rows in set (0.01 sec)

 

mysql> insert into t7 (who) values (‘A1‘);

Query OK, 1 row affected (0.01 sec)

 

mysql> insert into t7 (who) values (‘A2‘);

Query OK, 1 row affected (0.00 sec)

 

mysql> insert into t7 (who) values (‘A3‘);

Query OK, 1 row affected (0.01 sec)

 

mysql> insert into t7 (who) values (‘A4‘);

Query OK, 1 row affected (0.00 sec)

 

mysql> insert into t7 (who) values (‘A5‘);

Query OK, 1 row affected (0.00 sec)

 

mysql> insert into t7 (who) values (‘A6‘);

Query OK, 1 row affected (0.00 sec)

 

mysql> insert into t7 (who) values (‘A7‘);

Query OK, 1 row affected (0.01 sec)

 

mysql> insert into t7 (who) values (‘A8‘);

Query OK, 1 row affected (0.00 sec)

 

mysql> insert into t7 (who) values (‘A9‘);

Query OK, 1 row affected (0.00 sec)

 

mysql> insert into t7 (who) values (‘A10‘);

Query OK, 1 row affected (0.00 sec)

 

mysql> select * from t7;

+----+------+---------------------+

| id | who  | time                |

+----+------+---------------------+

|  1 | A1   | 2018-09-20 22:55:55 |

|  2 | A2   | 2018-09-20 22:55:57 |

|  3 | A3   | 2018-09-20 22:55:58 |

|  4 | A4   | 2018-09-20 22:56:06 |

|  5 | A5   | 2018-09-20 22:56:08 |

|  6 | A6   | 2018-09-20 22:56:39 |

|  7 | A7   | 2018-09-20 22:56:41 |

|  8 | A8   | 2018-09-20 22:56:43 |

|  9 | A9   | 2018-09-20 22:56:45 |

| 10 | A10  | 2018-09-20 22:56:47 |

+----+------+---------------------+

10 rows in set (0.00 sec)

 

mysql> create table t8 like t7;

Query OK, 0 rows affected (0.01 sec)

 

mysql> insert into t8 (who) values (‘B1‘);

Query OK, 1 row affected (0.02 sec)

 

mysql> insert into t8 (who) values (‘B2‘);

Query OK, 1 row affected (0.00 sec)

 

mysql> insert into t8 (who) values (‘B3‘);

Query OK, 1 row affected (0.00 sec)

 

mysql> insert into t8 (who) values (‘B4‘);

Query OK, 1 row affected (0.01 sec)

 

mysql> insert into t8 (who) values (‘B5‘);

Query OK, 1 row affected (0.00 sec)

 

mysql> insert into t7 (who) values (‘A100‘);

Query OK, 1 row affected (0.00 sec)

 

mysql> insert into t7 (who) values (‘A101‘);

Query OK, 1 row affected (0.00 sec)

 

mysql> select * from t8;

+----+------+---------------------+

| id | who  | time                |

+----+------+---------------------+

|  1 | B1   | 2018-09-20 22:57:24 |

|  2 | B2   | 2018-09-20 22:57:26 |

|  3 | B3   | 2018-09-20 22:57:28 |

|  4 | B4   | 2018-09-20 22:57:29 |

|  5 | B5   | 2018-09-20 22:57:31 |

+----+------+---------------------+

5 rows in set (0.00 sec)

 

此时t7和t8表中都有正常数据。

 

 

这时由于某种疏忽执行了以下的delete语句。

mysql> delete from t8;

Query OK, 5 rows affected (0.02 sec)

 

mysql> select * from t8;

Empty set (0.00 sec)

 

结果是t8表的全部数据都被删除了。

现在的问题是需要恢复这些被删除的数据。

 

使用binlog可以实现这个目标。

先找到当前使用的binlog文件名称。

mysql> show binary logs;

+---------------------+-----------+

| Log_name            | File_size |

+---------------------+-----------+

| mysql_binlog.000001 |       439 |

| mysql_binlog.000002 |      1149 |

| mysql_binlog.000003 |      1319 |

| mysql_binlog.000004 |       361 |

| mysql_binlog.000005 |      1319 |

| mysql_binlog.000006 |      6392 |

+---------------------+-----------+

6 rows in set (0.01 sec)

 

mysql> flush binary logs;

Query OK, 0 rows affected (0.01 sec)

 

执行之前那些数据增删操作对应的事件记录在mysql_binlog.000006文件中。

 

基本的思路是先找到binlog中对t8表的正常操作(insert)的binlog事件，不包括delete语句的事件，然后将这些事件在数据库中重新执行一遍即可。先需要确定这些事件的位置范围的开始位置和结束位置。

 

 

在binlog文件还存在的情况下，使用以下SQL语句查询这个binlog文件中的事件。

mysql> show binlog events in ‘mysql_binlog.000006‘;

 

 

开始位置：

找到先前执行的t8表的第一个insert事件的开始位置。3805 (BEGIN)

结束位置：

找到先前执行的t8表的最后一个insert事件的结束位置。5375(COMMIT)

在3805到5375范围内的binlog事件全部是t8的insert语句相关的事件。

 

使用mysqlbinlog提取这些事件产生SQL语句，并通过mysql程序执行提取的SQL语句。

[[email protected] binlog]# mysqlbinlog --start-position=3805 --stop-position=5375 mysql_binlog.000006  |mysql -uroot -p123456 -S /tmp/mysql.sock

 

 

此时查看t8表的数据：

mysql> select * from t8;

+----+------+---------------------+

| id | who  | time                |

+----+------+---------------------+

|  1 | B1   | 2018-09-20 22:57:24 |

|  2 | B2   | 2018-09-20 22:57:26 |

|  3 | B3   | 2018-09-20 22:57:28 |

|  4 | B4   | 2018-09-20 22:57:29 |

|  5 | B5   | 2018-09-20 22:57:31 |

+----+------+---------------------+

5 rows in set (0.00 sec)

 

 

t8表的数据恢复成功。

 

在执行这个操作之前，可以先通过以下命令先产生SQL语句，确认无误后再通过mysql程序导入数据。

 mysqlbinlog --start-position=3805 --stop-position=5375 mysql_binlog.000006  -vv

 

 

可以同时指定位置范围和时间戳范围，这样更准确的过滤数据，可以通过以下命令查看截取的数据。

 mysqlbinlog --start-position=3805 --stop-position=5375  --start-datetime=20180920225724 --stop-datetime=20180920225732 -vv  mysql_binlog.000006

 

确认无误后同样根据以下命令导入这部分数据到t8表中。

 mysqlbinlog --start-position=3805 --stop-position=5375  --start-datetime=20180920225724 --stop-datetime=20180920225732 -vv  mysql_binlog.000006  |mysql -uroot -p123456 -S /tmp/mysql.sock

 

 

这个简单的方法的最大缺点是当这个范围内包含有对其它数据表的操作时，这些操作将会影响到其它数据表。

 

mysqlbinlog还有一些参数：

--disable-log-bin  ：作用是本次操作不记录binlog日志。如果不希望本次操作影响到复制中的slave从机，则可以添加这个参数。

 

--database=XXXX：

在ROW模式下，作用是本次操作仅仅包含对XXXX数据库的操作，跟是否使用use无关。

在SQL模式下，作用比较隐晦，此时最好都通过use语句指定数据库，而不是通过数据库名.表名的方式。

 

以下文字来自man mysqlbinlog的输出信息：

  mysqlbinlog --database=test does not output the first two INSERT statements because there is no default database. It outputs the three INSERT statements following USE test,

           but not the three INSERT statements following USE db2.

 

           mysqlbinlog --database=db2 does not output the first two INSERT statements because there is no default database. It does not output the three INSERT statements following USE

           test, but does output the three INSERT statements following USE db2.

 

           Row-based logging. mysqlbinlog outputs only entries that change tables belonging to db_name. The default database has no effect on this. Suppose that the binary log just

           described was created using row-based logging rather than statement-based logging.  mysqlbinlog --database=test outputs only those entries that modify t1 in the test database,

           regardless of whether USE was issued or what the default database is.  If a server is running with binlog_format set to MIXED and you want it to be possible to use mysqlbinlog

           with the --database option, you must ensure that tables that are modified are in the database selected by USE. (In particular, no cross-database updates should be used.)

 

 

 

3. binlog数据库闪回工具myfash

myflash是一款MySQL binlog数据库闪回工具，核心机制是读取binlog文件的INSERT/UPDATE?DELETE事件，并将这些事件的基础上产生相应的逆向（回滚）事件，然后逆序保存到binlog文件中，最后执行这些binlog文件，从而达到数据库快速回滚某一段时间范围或者binlog位置范围内的数据操作的目的。

 

flashback的参数指定的位置范围和时间范围是“误操作”产生的事件数据的范围，比如前面例子中的误操作就是delete from t8这个SQL语句。因此需要找到这个语句。

通过以下SQL语句来查找，

mysql> show binlog events in ‘mysql_binlog.000006‘;

 

 

 

或者直接通过binlog文件来查找：

# at 6102

#180920 22:58:52 server id 101  end_log_pos 6176 CRC32 0x26716c36  Query thread_id=4 exec_time=0 error_code=0

SET TIMESTAMP=1537455532/*!*/;

BEGIN

/*!*/;

# at 6176

#180920 22:58:52 server id 101  end_log_pos 6214 CRC32 0x763a5d60  Rows_query

# delete from t8

# at 6214

#180920 22:58:52 server id 101  end_log_pos 6266 CRC32 0x33416fc0  Table_map: `binlog`.`t8` mapped to number 145

# at 6266

#180920 22:58:52 server id 101  end_log_pos 6361 CRC32 0xfe4e1cba  Delete_rows: table id 145 flags: STMT_END_F

 

BINLOG ‘

rLWjWx1lAAAAJgAAAEYYAACAAA5kZWxldGUgZnJvbSB0OGBdOnY=

rLWjWxNlAAAANAAAAHoYAAAAAJEAAAAAAAEABmJpbmxvZwACdDgAAwMPEQMKAAAGwG9BMw==

rLWjWyBlAAAAXwAAANkYAAAAAJEAAAAAAAEAAgAD//gBAAAAAkIxW6O1VPgCAAAAAkIyW6O1VvgD

AAAAAkIzW6O1WPgEAAAAAkI0W6O1WfgFAAAAAkI1W6O1W7ocTv4=

‘/*!*/;

### DELETE FROM `binlog`.`t8`

### WHERE

###   @1=1 /* INT meta=0 nullable=0 is_null=0 */

###   @2=‘B1‘ /* VARSTRING(10) meta=10 nullable=1 is_null=0 */

###   @3=1537455444 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */

### DELETE FROM `binlog`.`t8`

### WHERE

###   @1=2 /* INT meta=0 nullable=0 is_null=0 */

###   @2=‘B2‘ /* VARSTRING(10) meta=10 nullable=1 is_null=0 */

###   @3=1537455446 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */

### DELETE FROM `binlog`.`t8`

### WHERE

###   @1=3 /* INT meta=0 nullable=0 is_null=0 */

###   @2=‘B3‘ /* VARSTRING(10) meta=10 nullable=1 is_null=0 */

###   @3=1537455448 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */

### DELETE FROM `binlog`.`t8`

### WHERE

###   @1=4 /* INT meta=0 nullable=0 is_null=0 */

###   @2=‘B4‘ /* VARSTRING(10) meta=10 nullable=1 is_null=0 */

###   @3=1537455449 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */

### DELETE FROM `binlog`.`t8`

### WHERE

###   @1=5 /* INT meta=0 nullable=0 is_null=0 */

###   @2=‘B5‘ /* VARSTRING(10) meta=10 nullable=1 is_null=0 */

###   @3=1537455451 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */

# at 6361

#180920 22:58:52 server id 101  end_log_pos 6392 CRC32 0xeb934c3d  Xid = 295

COMMIT/*!*/;

 

最后找到的位置范围是6102到6392，时间范围180920 22:58:52到180920 22:58:52。

 

在此基础上，可以执行flashback程序，产生对应的“回滚”binlog日志文件。

 

[email protected] binary]# ./flashback --databaseNames=binlog --tableNames=t8 --start-position=6102 --stop-position=6392  --start-datetime="2018-09-20 22:58:52" --stop-datetime="2018-09-20 22:58:52"  --sqlTypes=delete --binlogFileNames=/opt/mysql/binlog/mysql_binlog.000006

 

产生的binlog日志文件：

binlog_output_base.flashback

 

使用mysqlbinlog查看这个binlog日志文件的内容：

[[email protected] binary]# mysqlbinlog binlog_output_base.flashback   -vv

/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;

/*!50003 SET @[email protected]@COMPLETION_TYPE,COMPLETION_TYPE=0*/;

DELIMITER /*!*/;

# at 4

#180920 22:45:53 server id 101  end_log_pos 123 CRC32 0x516e9591  Start: binlog v 4, server v 5.7.22-log created 180920 22:45:53

BINLOG ‘

obKjWw9lAAAAdwAAAHsAAAAAAAQANS43LjIyLWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA

AZGVblE=

‘/*!*/;

# at 123

#180920 22:58:52 server id 101  end_log_pos 175 CRC32 0x33416fc0  Table_map: `binlog`.`t8` mapped to number 145

# at 175

#180920 22:58:52 server id 101  end_log_pos 270 CRC32 0xfe4e1cba  Write_rows: table id 145 flags: STMT_END_F

 

BINLOG ‘

rLWjWxNlAAAANAAAAK8AAAAAAJEAAAAAAAEABmJpbmxvZwACdDgAAwMPEQMKAAAGwG9BMw==

rLWjWx5lAAAAXwAAAA4BAAAAAJEAAAAAAAEAAgAD//gBAAAAAkIxW6O1VPgCAAAAAkIyW6O1VvgD

AAAAAkIzW6O1WPgEAAAAAkI0W6O1WfgFAAAAAkI1W6O1W7ocTv4=

‘/*!*/;

### INSERT INTO `binlog`.`t8`

### SET

###   @1=1 /* INT meta=0 nullable=0 is_null=0 */

###   @2=‘B1‘ /* VARSTRING(10) meta=10 nullable=1 is_null=0 */

###   @3=1537455444 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */

### INSERT INTO `binlog`.`t8`

### SET

###   @1=2 /* INT meta=0 nullable=0 is_null=0 */

###   @2=‘B2‘ /* VARSTRING(10) meta=10 nullable=1 is_null=0 */

###   @3=1537455446 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */

### INSERT INTO `binlog`.`t8`

### SET

###   @1=3 /* INT meta=0 nullable=0 is_null=0 */

###   @2=‘B3‘ /* VARSTRING(10) meta=10 nullable=1 is_null=0 */

###   @3=1537455448 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */

### INSERT INTO `binlog`.`t8`

### SET

###   @1=4 /* INT meta=0 nullable=0 is_null=0 */

###   @2=‘B4‘ /* VARSTRING(10) meta=10 nullable=1 is_null=0 */

###   @3=1537455449 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */

### INSERT INTO `binlog`.`t8`

### SET

###   @1=5 /* INT meta=0 nullable=0 is_null=0 */

###   @2=‘B5‘ /* VARSTRING(10) meta=10 nullable=1 is_null=0 */

###   @3=1537455451 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */

SET @@SESSION.GTID_NEXT= ‘AUTOMATIC‘ /* added by mysqlbinlog */ /*!*/;

DELIMITER ;

# End of log file

/*!50003 SET [email protected]_COMPLETION_TYPE*/;

/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

 

总共包含了5条INSERT语句，正好插入5条数据记录，从而可以借此达到“回滚”的目标。

 

最后通过mysqlbinlog产生对应的 SQL语句，并通过mysql程序执行，最终恢复了t8表的5条被误操作删除的记录。

[[email protected] binary]# mysqlbinlog -vv binlog_output_base.flashback  |mysql -uroot -p123456 -S /tmp/mysql.sock

 

mysql> select * from t8;

+----+------+---------------------+

| id | who  | time                |

+----+------+---------------------+

|  1 | B1   | 2018-09-20 22:57:24 |

|  2 | B2   | 2018-09-20 22:57:26 |

|  3 | B3   | 2018-09-20 22:57:28 |

|  4 | B4   | 2018-09-20 22:57:29 |

|  5 | B5   | 2018-09-20 22:57:31 |

+----+------+---------------------+

5 rows in set (0.00 sec)

 

 

myflash工具的适用条件：

 

（1）binlog_format=row

如果binlog记录sql语句而不是行记录数据，那么没办法仅仅根据一个sql语句产生反向的“回滚”binlog事件。因此不适用于STATEMENT模式或者MIXED模式。

在STATEMENT模式下，delete from t8对应的binlog数据的内容为：

BEGIN

/*!*/;

# at 302

#180921  0:54:48 server id 101  end_log_pos 394 CRC32 0x3cb196cf  Query thread_id=2 exec_time=0 error_code=0

use `binlog`/*!*/;

SET TIMESTAMP=1537462488/*!*/;

delete from t8

/*!*/;

# at 394

#180921  0:54:48 server id 101  end_log_pos 425 CRC32 0xa4634f24  Xid = 21

COMMIT/*!*/;

 

没有包含任何行记录数据信息，因此myflash工具也没法产生反向操作insert所需要的数据。

 

 

（2）binlog_row_image=full

如果binliog中记录的行记录中缺少一部分字段的值，则很可能没办法产生反向的“回滚”binlog事件。

在binlog_row_image=minimal的情况下，delete from t8产生的binlog事件如下：

# delete from t8

# at 331

#180921  0:35:08 server id 101  end_log_pos 383 CRC32 0x571c1559  Table_map: `binlog`.`t8` mapped to number 117

# at 383

#180921  0:35:08 server id 101  end_log_pos 443 CRC32 0xc220f346  Delete_rows: table id 117 flags: STMT_END_F

 

BINLOG ‘

PMyjWx1lAAAAJgAAAEsBAACAAA5kZWxldGUgZnJvbSB0OO9WEy8=

PMyjWxNlAAAANAAAAH8BAAAAAHUAAAAAAAEABmJpbmxvZwACdDgAAwMPEQMKAAAGWRUcVw==

PMyjWyBlAAAAPAAAALsBAAAAAHUAAAAAAAEAAgADAf4BAAAA/gIAAAD+AwAAAP4EAAAA/gUAAABG

8yDC

‘/*!*/;

### DELETE FROM `binlog`.`t8`

### WHERE

###   @1=1 /* INT meta=0 nullable=0 is_null=0 */

### DELETE FROM `binlog`.`t8`

### WHERE

###   @1=2 /* INT meta=0 nullable=0 is_null=0 */

### DELETE FROM `binlog`.`t8`

### WHERE

###   @1=3 /* INT meta=0 nullable=0 is_null=0 */

### DELETE FROM `binlog`.`t8`

### WHERE

###   @1=4 /* INT meta=0 nullable=0 is_null=0 */

### DELETE FROM `binlog`.`t8`

### WHERE

###   @1=5 /* INT meta=0 nullable=0 is_null=0 */

 

其中的5条DELETE语句每个仅仅包含了主键字段id的值，而没有包含其它的字段，此时myflash工具无法产生包含完整的原始字段数据的INSERT语句。

此时myflash工具产生的binlog数据如下：

### INSERT INTO `binlog`.`t8`

### SET

###   @1=1 /* INT meta=0 nullable=0 is_null=0 */

### INSERT INTO `binlog`.`t8`

### SET

###   @1=2 /* INT meta=0 nullable=0 is_null=0 */

### INSERT INTO `binlog`.`t8`

### SET

###   @1=3 /* INT meta=0 nullable=0 is_null=0 */

### INSERT INTO `binlog`.`t8`

### SET

###   @1=4 /* INT meta=0 nullable=0 is_null=0 */

### INSERT INTO `binlog`.`t8`

### SET

###   @1=5 /* INT meta=0 nullable=0 is_null=0 */

 

依靠这个数据是没法产生t8表的其它字段的数据的。

 

 

（3）只能是INSERT/DELETE/UPDATE这三种语句，而不能是DDL语句，也不能是TRUNCATE TABLE语句。

如果是DDL语句，则可能没法产生反向的“回滚”binlog事件。TRUNCATE TABLE语句产生的binlog事件不包含行数据信息，因此也无法回滚。

 

 

以上是关于MySQLbinlog日志02binlog日志用于数据恢复的主要内容，如果未能解决你的问题，请参考以下文章

MySQLbinlog日志01binlog日志基本操作

MySQLbinlog日志04binlog日志字节码解析之二Write_Rows事件

Mysql的binlog日志与mysqlbinlog命令

mysql 利用binlog日志恢复问题

mysql之 binlog维护详细解析（开启binlog相关参数作用mysqlbinlog解读binlog删除）

使用mysqlbinlog提取二进制日志