技术分享 | Xtrabackup 备份中 Xtrabackup_binlog_info 文件记录的 GTID 信息是否准确？

作者：何政
本文来源：原创投稿
*原创内容未经授权不得随意使用，转载请联系小编并注明来源。

---

Xtrabackup 是由 percona 开源的免费数据库热备份软件，它能对 InnoDB 和 XtraDB 存储引擎的数据库非阻塞地备份。
为了方便建立从库，Xtrabackup 在备份完成后会将 binlog position 与 GTID 的相关信息保存于 xtrabackup_binlog_info 文件中。
但是当你使用 Xtrabackup 生成的备份建立一个从库时，会发现恢复后的实例执行 show master status，显示的 Executed_Gtid_Set 与 xtrabackup_binlog_info 文件中记录的信息并不一致，而且使用 Xtrabackup 2.4 与 8.0（对 MySQL 8.0 进行备份）生成的备份在恢复后，信息不一致的表现又不相同。本篇文章主要针对该现象进行简单的分析。

一、Xtrabackup 2.4.18 for MySQL 5.7.26

现象

1.使用 Xtrabackup 工具备份后，xtrabackup_binlog_info 文件记录的信息如下：

\# cat xtrabackup_binlog_info
mysql-bin.000003    86412752    55d3d9b9-4d49-11ea-932c-02000aba3fa6:1-595859

2.将该备份恢复至一个新实例并启动该实例，执行 show master status; 查看信息：

mysql> show master status\G
*************************** 1. row ***************************
             File: mysql-bin.000001
         Position: 154
     Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set: 55d3d9b9-4d49-11ea-932c-02000aba3fa6:1-326661
1 row in set (0.00 sec)

此时会发现使用备份恢复的实例显示已执行过的 GTID 是 1-326661，而备份文件显示的是 1-595859，这是否表示两者相差的 GTID:326662-595859 代表的事务丢失了？
通过对原实例（进行备份的实例）的 binlog 进行解析，来查询 GTID:326662-595859 这部分事务所生成的数据在新实例（通过备份恢复的实例）上是否存在。可以发现 GTID:326662-595859 这部分事务的数据都存在于新实例上，也就是说数据与 xtrabackup_binlog_info 文件记录的是一致的，只不过与 show master status 命令获取的信息的不一致。

原因分析

首先我们要清楚 Xtrabackup 2.4 的备份流程，大致如下：
1.start backup
2.copy ibdata1 / copy .ibd file
3.Excuted ftwrl
4.backup non-InnoDB tables and files
5.Writing xtrabackup_binlog_info
6.Executed FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS
7.Executed UNLOCK TABLES
8.Copying ib_buffer_pool
9.completed OK!
结合备份时的 general log 可知，Xtrabackup 在执行 ftwrl 并备份完所有非 InnoDB 表格的文件后通过 show master status 获取了 binlog position 和 GTID 的信息，将其记录到 xtrabackup_binlog