最近遇到较多咨询5.7和8.0恢复gitd的问题，这里简单描述一下，仅供参考和理解。
操作上的不同
5.7：备份恢复后的gtid不完整，严重滞后于恢复的数据，需要使用备份文件xtrabackup_binlog_info中的gtid进行重置。 8.0:备份恢复后的gtid是完整的，直接使用即可，不需要使用xtrabackup_binlog_info中的gtid进行重置。
具体原因
5.7:这是因为备份中不包含最后一个binlog文件，而gtid启动初始化完全来自持久化的gtid_executed表，而这个表并不是实时的，在5.7中为切换binlog更新，因此丢失的GTID比较多，因此依赖xtrabackup_binlog_info中的gtid。 8.0:某些版本xtrabackup_binlog_info中的gtid可能出现丢失，这是由于BUG https://bugs.mysql.com/bug.php?id=102175导致的，大概意思就是提交的时候通过performance_schema.log_status获取gtid信息的时候，由于加锁的范围小了导致获取的gtid滞后于binlog postition，而xtrabackup_binlog_info中的gtid就来自performance_schema.log_status。8.0的gtid_executed本身为准实时更新，且恢复后会使用gtid_executed表和undo中的gtid进行初始化GITD，且xtrabackup本生也恢复了最后一个binlog，因此恢复后的gtid是完整的。
关于FTWRL的使用
8.0:使用xtrabackup备份，如果只有innodb表可能不需要FTWRL这个锁，如果包含myisam表 则需要FTWRL锁。
参考
对于https://bugs.mysql.com/bug.php?id=102175和8.0新的备份锁的问题参考以往文章
https://www.jianshu.com/p/9007883b58b8
对于clone线程参考以往文章
https://www.jianshu.com/p/0e75c59bed28
对于8.0的GTID初始化可以参考，温正湖:从MySQL 8.0故障恢复看InnoDB及Binlog角色变化
https://zhuanlan.zhihu.com/p/141403577
也可以参考《MySQL实战》相关部分
原文作者：MySQL学习；如有侵权，请联系管理员删除。
请登录后发表评论
登录
全部评论
