MySQL冷备的gtid竟然还能不一致

IT行业相对于一般传统行业，发展更新速度更快，一旦停止了学习，很快就会被行业所淘汰。所以我们需要踏踏实实的不断学习，精进自己的技术，尤其是初学者。今天golang学习网给大家整理了《MySQL冷备的gtid竟然还能不一致》，聊聊MySQL，我们一起来看看吧！

本文的测试环境为mysql5.7.30

冷备
起因：自己私下做某个测试时，因为源库数据量小，而且图方便，所以打算用冷备的方式构建从库，但这里留下的一个坑是：之前的从库有数据。先描述下现象：

（1）如果停止源库mysql后，只复制data目录（不包含binlog）到从库，则从库的show master status和mysql.gtid_executed的gtid会是两库的并集，和源库不一样。
（2）如果复制data目录和log目录（包含binlog），则从库的show master status的gtid值和源库一样。

源库的gtid（在备份等操作过程中没有数据写入）

从库原有的数据（在备份等操作过程中没有数据写入）

关掉从库的mysql服务，删掉data目录，用源库的data目录替换后起库。发现3c60f36b-46ab-11ec-b485-08002704f055（源库的server_uuid）的gtid和源库保持一致，baf76130-9458-11ec-84f7-080027e4e8a5（从库的server_uuid）的gtid还是从库原来的。数据上保持和主库一致，比主库多的数据没了

从以上的测试实际上可以大致猜测和binlog有关系，在官网中查找相关信息验证：gtid_executed计算为最新二进制日志文件中Previous_gtids_log_event中的GTID、该二进制日志文件中事务的GTID以及存储在mysql.gtid_executed表中的GTID的并集。此GTID集包含服务器上已使用（或显式添加到gtid_purged）的所有GTID，无论它们当前是否位于服务器上的二进制日志文件中。它不包括服务器上当前正在处理的事务的GTID(@@GLOBAL.gtid_owned)（https://dev.mysql.com/doc/ref...）

在服务器意外停止的情况下，当前二进制日志文件中的GTID集不会保存在 mysql.gtid_executed表中。这些GTID在恢复期间从二进制日志文件添加到表中。例外情况是，如果在重新启动服务器时未启用二进制日志记录。在这种情况下，服务器无法访问二进制日志文件来恢复GTID，因此无法启动复制（https://dev.mysql.com/doc/ref...）
下面看看其他备份恢复的方法是否有什么坑。

mysqldump
如果使用mysqldump备份恢复，默认--set-gtid-purged是on，即在备份的结果集里会有SET @@GLOBAL.GTID_PURGED语句，但是该从库的该变量不是空，所以恢复时会报错@@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty，即gtid的设置失败。

Xtrabackup
这个实际上也是之前碰到的问题，和这次主题相关就一块放进来。
从库利用源库的备份恢复完成，但是一段时间后复制报主键冲突错误（只有主库可写）。查看备份日志，发现该gtid对应的事件已经复制过来了，按理说不应该再执行一遍

cat xtrabackup_binlog_info 
mysql-bin.000949        1011856733      7fad1986-f472-11e9-9e4f-40eedd74dfea:1-13113,
9b46f7b8-f472-11e9-9694-d0efc1ea2bf9:1-2151443844

但是从库show slave status的状态如下，Executed_Gtid_Set比xtrabackup_binlog_info小

Retrieved_Gtid_Set: 9b46f7b8-f472-11e9-9694-d0efc1ea2bf9:2150986487-2151940664
 Executed_Gtid_Set: 7fad1986-f472-11e9-9e4f-40eedd74dfea:1-13113,
9b46f7b8-f472-11e9-9694-d0efc1ea2bf9:1-2150986486

怀疑是恢复过程有问题，重新执行然后查看从库的Executed_Gtid_Set还是比xtrabackup_binlog_info中小，而且查报主键错误的sql，发现这条数据已经存在。检查备份恢复的apply log和copy的日志，均无异常，排除恢复问题。所以怀疑恢复时的Executed_Gtid_Set是否不是正确的，或者说不是最新的？

网上搜索得到的相关说法：mysql.gtid_executed表使用innodb存储引擎，mysql.gtid_executed表中的数据并不是实时更新的，并且对其所有的写入不会记录binlog，也就是不会存在于redo log中。因此xtrabackup备份所得到的mysql.gtid_executed，就是copy gtid_executed.ibd时刻mysql.gtid_executed表中已有的数据。此数据与当时show master status的返回值极可能不一致（没满足写入时机），并且后续拷贝到xtrabackup_logfile文件也不会包含mysql.gtid_executed相关信息，因此apply-log不会影响mysql.gtid_executed表中的数据。如果还原实例的../logs/目录下存在binlog，在启动数据库服务时，它们会被计算到gtids_in_binlog，然后结合mysql.gtid_executed表初始化@@global.gtid_executed

官网的进一步佐证：https://dev.mysql.com/doc/ref...

解决方法，先执行reset master;然后set @@global.gtid_purged=xtrabackup_binlog_info中的gtid

总结
（1）冷备时需要把binlog一块备份然后覆盖掉从库的相关数据；
（2）在原本有数据的从库进行mysqldump恢复时需要先reset master；
（3）xtrabackup恢复时需要根据xtrabackup_binlog_info设置@@global.gtid_purged。

文中关于mysql的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《MySQL冷备的gtid竟然还能不一致》文章吧，也可关注golang学习网公众号了解相关技术文章。