binlog解析出来的日志为何无法恢复？

首先再次强调线上操作要非常谨慎，如果只是普通的DML操作，建议事先打开事务模式，这样万一误操作了还能执行 rollback 回滚。

但如果是DDL操作，则基本上只能依赖备份或者延迟从库，所以务必再三确认是在测试环境还是线上环境，以及即将执行的命令影响如何。

再回到问题本身。

在执行 mysqlbinlog 解析binlog并尝试恢复时，观察新的binlog，确认没有写入新数据，说明确实没执行恢复操作。

解析binlog查看，并没有类似 SET SQL_LOG_BIN=0 等忽略binlog的设置，而如果复制SQL指令执行出来手动执行，却是可以成功的。说明binlog本身没问题，是其他原因导致的。

再查看 binlog event 时注意到启用了 GTID 模式，在 GTID 模式下有个特点是要求 全局唯一。

除了GTID值持续递增之外，有个不容易注意的特点是，当事务GTID在已执行过的GTID集合（Executed_Gtid_Set）中的话，就不会再次被执行。假设以下几种场景：

• 假设当前Executed_Gtid_Set集合是 1-10，如果下一个GTID是5，它在这个范围内，则无法被执行。
• 假设当前Executed_Gtid_Set集合是 1-10, 20-30，如果下一个GTID是13，不在这个范围内，则可以被执行。
  
  

分别做个测试：

1. # 查看当前gtid
   
2. [yejr]> show master status;
   
3. +---------------+----------+--------------+------------------+----------------------------------------------+
   
4. | File          | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                            |
   
5. +---------------+----------+--------------+------------------+----------------------------------------------+
   
6. | binlog.000004 |      762 |              |                  | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1:1-15:20 |
   
7. +---------------+----------+--------------+------------------+----------------------------------------------+
   
8. 
   
9. # 下一个GTID在范围内，不会被执行
   
10. [yejr]> set session gtid_next='aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1:13';
    
11. [yejr]> insert into t1 select 6;
    
12. Query OK, 0 rows affected (0.00 sec)   #<-- 0 rows
    
13. 
    
14. # 下一个GTID不在范围内，会被执行
    
15. [yejr]> set session gtid_next='aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1:17';
    
16. [yejr]> insert into t1 select 6;
    
17. Query OK, 1 row affected (0.01 sec)   #<-- 1 row affected
    
18. Records: 1  Duplicates: 0  Warnings: 0
    
19. 
    
20. # 再次查看gtid
    
21. [yejr]> show master status;
    
22. +---------------+----------+--------------+------------------+-------------------------------------------------+
    
23. | File          | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                               |
    
24. +---------------+----------+--------------+------------------+-------------------------------------------------+
    
25. | binlog.000004 |     1091 |              |                  | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1:1-15:17:20 |
    
26. +---------------+----------+--------------+------------------+-------------------------------------------------+

复制代码

验证结果确实如上所说。

知道原因就好办了，查看 mysqlbinlog 的帮助文档，查看选项 --skip-gtids 的解释：

1.   --skip-gtids        Do not preserve Global Transaction Identifiers; instead
   
2.                       make the server execute the transactions as if they were
   
3.                       new.

复制代码

它可以使得解析出来的binlog event不再保留原来的 GTID 信息，这就可以当成新的 event 被执行了。所以，如果想要从binlog恢复数据，执行mysqlbinlog时，记得加上 --skip-gtids 选项。