GTID binlog解析后导入无效

最新推荐文章于 2025-06-18 15:07:29 发布

渔夫数据库笔记

最新推荐文章于 2025-06-18 15:07:29 发布

阅读量2.7k

点赞数 1

CC 4.0 BY-SA版权

分类专栏： Mysql 文章标签： GTID binlog GTID binlog解析后导入无效

本文链接：https://blog.youkuaiyun.com/shaochenshuo/article/details/54863522

Mysql 专栏收录该内容

220 篇文章

订阅专栏

本文探讨了在启用了GTID的MySQL环境中，通过解析binlog进行数据恢复时遇到的问题。解析出的binlog文件中包含了GTID设置指令，由于这些GTID已存在于目标数据库的Executed_Gtid_Set中，导致所有事务被跳过。文章提供了解决方案，即使用mysqlbinlog工具时添加--skip-gtids=true参数。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

群里一个朋友问了个问题，他说他通过解析binlog日志来恢复某些数据，但是发现虽然执行了解析出来的binlog(执行过程中未报任何错误)，但是发现数据并没有被导入。后来仔细问了一下他enable 了GTID。那这个问题跟GTID有什么关系呢？

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

mysqlbinlog -vvv  3306-bin.000062 >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 4
#170204 10:04:04 server id 2  end_log_pos 120 CRC32 0xfe109258  Start: binlog v 4, server v 5.6.26-enterprise-commercial-advanced-log created 170204 10:04:04
BINLOG '
lDaVWA8CAAAAdAAAAHgAAAAAAAQANS42LjI2LWVudGVycHJpc2UtY29tbWVyY2lhbC1hZHZhbmNl
ZC1sb2cAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXAAEGggAAAAICAgCAAAACgoKGRkAAViS
EP4=
'/*!*/;
# at 120
#170204 10:04:04 server id 2  end_log_pos 191 CRC32 0xaeaa9a7f  Previous-GTIDs
# 6876c0ce-b41e-11e5-a40c-005056b1efab:1-2895701
# at 191
#170204 10:04:26 server id 2  end_log_pos 239 CRC32 0xb257069f  GTID [commit=yes]
SET @@SESSION.GTID_NEXT= '6876c0ce-b41e-11e5-a40c-005056b1efab:2895702'/*!*/;
# at 239
#170204 10:04:26 server id 2  end_log_pos 379 CRC32 0x2342af31  Query   thread_id=58    exec_time=0     error_code=0
use `test1`/*!*/;
SET TIMESTAMP=1486173866/*!*/;
SET @@session.pseudo_thread_id=58/*!*/;
SET @@session.foreign_key_checks=0, @@session.sql_auto_is_null=0, @@session.unique_checks=0, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=524288/*!*/;
SET @@session.auto_increment_increment=3, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
DROP TABLE IF EXISTS `test` /* generated by server */
/*!*/;
# at 379
#170204 10:04:26 server id 2  end_log_pos 427 CRC32 0x761a7e8f  GTID [commit=yes]
SET @@SESSION.GTID_NEXT= '6876c0ce-b41e-11e5-a40c-005056b1efab:2895703'/*!*/;
# at 427
#170204 10:04:26 server id 2  end_log_pos 3318 CRC32 0x8975b5b5         Query   thread_id=58    exec_time=1     error_code=0

##我们发现解析后的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=