MySQL mysqldump备份之--set-gtid-purged=OFF参数影响

背景描述：在生产环境中，我们经常会遇到这样的情况，在mysql高可用架构或主从架构的数据库集群中进行逻辑备份（通过mysqldump工具备份的数据）还原的时候，会出现主从数据不一致，主从同步异常的情况。

根因分析：通过分析不难发现，主从同步异常的原因是进行数据还原的时候，主库没有记录binlog，导致从库无法复制新增的数据。（主从同步原理可参考文章：https://www.starcto.com/mysql/112.html）进一步排查MySQL主库不难发现，主库是开启了binlog记录的，如下图：

mysql> show variables like "log_bin";
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin       | ON    |
+---------------+-------+
1 row in set (0.00 sec)

GTID是为了加强数据库的主备一致性、故障恢复和容错能力，所以开启GTID的数据库GTID号具有全局唯一性。接下来我们补充两个场景：

场景1：高可架构，开启GTID备份

（1）主从复制：

通过mysqldump备份的时候，即使不是MySQL全库(所有库)备份，也会备份整个数据库所有的GTID号。特别是mysqldump备份整个数据库用来做从库，实现基于GTID主从复制的场景来说，开启GTID更是必须的，这是因为从库是基于MASTER_AUTO_POSITION=1自动获取并应用GTID的，因此如果在主库导出的备份文件中没有GTID，那么从库无法自动获取并应用GTID，就无法建立起主从关系。

（2）备份恢复丢失数据场景

在高可用架构中，如果在主库上进行数据备份恢复，如果没有开启GTID就会导致主库恢复的数据不记录binlog文件，那么基于binlog复制的从库就会与主库数据不一致，就会导致主从同步异常。一般这种情况，只能重做从库进行恢复。

场景2：基于A库的备份恢复到B库，建议关闭GTID备份

如果基于A库的备份（即使是部分备份）开启了GTID，就会导致备份中包含A库的所有GTID号码，那么用于在B库恢复时，会连带A库所有GTID一并导入，这样就会导致B库出现很多多余GTID号码，并且会有一定概率出现GTID冲突问题，导致B库主从同步异常。所以这种场景，建议关闭GTID进行备份。

官网介绍：https://dev.mysql.com/doc/refman/5.7/en/mysqldump.html#option_mysqldump_set-gtid-purged

https://dev.mysql.com/doc/refman/5.7/en/mysqldump.html#option_mysqldump_master-data

1、不带--set-gtid-purged=OFF参数备份

既然主库开启了binlog记录功能，但导入数据的时候，又没有binlog记录，那问题肯定是出在了备份文件上，于是我们就查看了备份文件。发现了下面截图的一条记录，即不记录binlog。此时用的备份命令：mysqldump --all-databases --master-data=2 --single-transaction --quick -R --events -uroot -h$IP -P3306 -p$password > backup1.sql

2、带--set-gtid-purged=OFF参数备份

将备份命令调整为：mysqldump --all-databases --master-data=2 --single-transaction --set-gtid-purged=OFF --quick -R --events -uroot -h$IP -P3306 -p$password  > backup2.sql

由上图可见，mysqldump备份时，加上--set-gtid-purged=OFF参数后，会去掉逻辑备份中，不记录binlog的设置。