mysqldump备份（gtid使用说明）

 

mysql备份：

backup_dir='/data/backup/mysql'
database_name='dbname'
bak_save_days=7
dd=`date +%Y-%m-%d-%H-%M-%S`

if [ ! -d $backup_dir ];then
  mkdir -p $backup_dir
fi

mysqldump --defaults-extra-file=/etc/mypass.txt --flush-logs --single-transaction --set-gtid-purged=OFF $database_name | gzip > $backup_dir/$database_name-$dd.sql.gz

mysqldump --defaults-extra-file=/etc/my_pass.txt --flush-logs --single-transaction  $database_name | gzip > $backup_dir/$database_name-$dd.gtid.sql.gz

#删除7天前的备份
find ${backup_dir} -maxdepth 1 -type f -name "*.sql.gz" -mtime +${bak_save_days} -exec rm -rf {} \;

 

mysqldump 不使用`--set-gtid-purged=OFF`，默认为--set-gtid-purged=ON，那么就会导出整个数据库的GTID号码，应用场景：将主库的数据备份出来还原到从库

使用`--set-gtid-purged=OFF`，不产生gtid，将备份的数据库全新还原到其他DB，自动重新生成新的gtid

###################################################################################

 

mysqldump 默认启用--set-gtid-purged=on（或其等效选项 --set-gtid-purged=TRUE 或 --set-gtid-purged=AUTO）

 

mysqldump需要开启 --set-gtid-purged=on 的场景：

1、当备份文件用于创建新的从库或恢复一个已存在的从库时
原因：
该参数使备份文件中包含 SET @@GLOBAL.GTID_PURGED = '...' 语句。该语句记录了备份时刻源库上已存在于 gtid_purged 中的所有 GTID 集合（即已执行过但已被清除 binlog 的事务）

从库在导入此备份后，会在其 gtid_purged 和 gtid_executed 中设置相同的集合。这样，从库在连接到主库并设置 MASTER_AUTO_POSITION=1 时，才能准确地告知主库自己已经执行过哪些事务，主库才能发送后续缺失的事务进行复制。

如果备份文件用于建立从库但缺少此 GTID 集合信息（即关闭了该参数），从库可能会尝试重新执行主库上已经执行过的事务，导致复制错误（如 GTID 冲突）。

2、需要确保备份包含完整的 GTID 事务历史链（即使不是用于搭建从库）‌：

如果你需要确保未来的恢复操作能够精确地恢复到某个 GTID 点，或者需要维护备份中包含的事务历史完整性（例如在复杂的恢复、克隆或审计场景中），开启此参数可以保证备份文件中包含必要的 GTID 元信息 (gtid_purged)。
这种情况下，恢复后的实例知道哪些 GTID 已经执行过，避免与后续可能应用的 binlog 发生冲突。

 

mysqldump需要关闭 --set-gtid-purged=off 的场景：
将备份文件恢复到非复制环境的独立实例‌，不应使用 --set-gtid-purged=on

例如，将备份恢复到一个新的、不与任何主库建立复制的测试库或开发库。此时备份文件中的 SET @@GLOBAL.GTID_PURGED 语句可能导致恢复失败