MySQL binlog导入失败

一个同事问我，说他用innobackupex恢复数据后用mysqlbinlog导入增量数据时，发现数据没有导入进去并且也没有报错。

mysqlbinlog /u01/mysql_py/database/mysql3306/logs/mysql-bin.  /u01/mysql_py/database/mysql3306/logs/mysql-bin. --start-position= | mysql -uroot -p

最后发现是因为启动GTID导致，解决方法，添加 --skip-gtids=true参数

mysqlbinlog --skip-gtids=true /u01/mysql_py/database/mysql3306/logs/mysql-bin.  /u01/mysql_py/database/mysql3306/logs/mysql-bin. --start-position=  | mysql -uroot -p

我们先来看一下使用了GTID的数据库binlog解析后是什么样的：

mysqlbinlog -vvv  -bin. >test.sql  

vi test.sql  

/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at
# :: server id   end_log_pos  CRC32 0xfe109258  Start: binlog v , server v 5.6.-enterprise-commercial-advanced-log created  ::
BINLOG '
lDaVWA8CAAAAdAAAAHgAAAAAAAQANS42LjI2LWVudGVycHJpc2UtY29tbWVyY2lhbC1hZHZhbmNl
ZC1sb2cAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXAAEGggAAAAICAgCAAAACgoKGRkAAViS
EP4=
'/*!*/;
# at
# :: server id   end_log_pos  CRC32 0xaeaa9a7f  Previous-GTIDs
# 6876c0ce-b41e-11e5-a40c-005056b1efab:-
# at
# :: server id   end_log_pos  CRC32 0xb257069f  GTID [commit=yes]
SET @@SESSION.GTID_NEXT= '6876c0ce-b41e-11e5-a40c-005056b1efab:2895702'/*!*/;
# at
# :: server id   end_log_pos  CRC32 0x2342af31  Query   thread_id=    exec_time=     error_code=
use `test1`/*!*/;
SET TIMESTAMP=/*!*/;
SET @@session.pseudo_thread_id=/*!*/;
SET @@session.foreign_key_checks=, @@session.sql_auto_is_null=, @@session.unique_checks=, @@session.autocommit=/*!*/;
SET @@session.sql_mode=/*!*/;
SET @@session.auto_increment_increment=, @@session.auto_increment_offset=/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=,@@session.collation_connection=,@@session.collation_server=/*!*/;
SET @@session.lc_time_names=/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
DROP TABLE IF EXISTS `test` /* generated by server */
/*!*/;
# at
# :: server id   end_log_pos  CRC32 0x761a7e8f  GTID [commit=yes]
SET @@SESSION.GTID_NEXT= '6876c0ce-b41e-11e5-a40c-005056b1efab:2895703'/*!*/;
# at
# :: server id   end_log_pos  CRC32 0x8975b5b5         Query   thread_id=    exec_time=     error_code=  

##我们发现解析后的binlog文件中每个事物开始前，都执行了SET @@SESSION.GTID_NEXT=操作来执行下一个要执行的GTID。但是这些GTID都已经存在数据库的Executed_Gtid_Set中(因为这些GTID都之前已经在实例上执行过)，所以我们执行解析后的binlog文件时，所有的事物都被忽略(已经存在于Executed_Gtid_Set集合中的GTID会跳过)。

在使用GTID时，如果我们想通过解析binlog来恢复数据的话，在使用mysqlbinlog解析binlog日志时需要指定--skip-gtids=true，这样的话解析出来的文件中就不会包含SET @@SESSION.GTID_NEXT=

参考：

GTID binlog解析后导入无效 - CSDN博客
https://blog.csdn.net/shaochenshuo/article/details/54863522