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锁。