xtrabackup 备份的两个'坑'

最近遇到较多咨询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