37｜备库服务器异常重启，备库损坏了该如何修复？

1. 备库异常重启后，存储位点信息的方式对数据一致性和恢复过程至关重要，建议将参数master_info_repository和relay_log_info_repository都设置为table，将位点存储到innodb表中。 2. 在备库异常重启后，使用GTID Auto Position可以简化恢复过程，可以手动执行reset replica、change replication source命令进行修复。 3. MTS恢复逻辑是备库重启时进行的重要步骤，包括从slave_relay_log_info和slave_worker_info读取位点信息，统计事务数，以及根据位图recovery_groups跳过已提交的事务。 4. 在备库异常重启后，GTID的持久化是保障数据复制正常进行的关键，MySQL会将GTID持久化到mysql.gtid_executed表中，确保备库重启后能够初始化gtid_executed变量。 5. 备库异常重启后，使用GTID Auto Position或者手动执行reset replica、change replication source命令进行修复，可以解决Relay Log损坏的问题。 6. 备库异常重启后，如果没有开启GTID但使用了多线程复制，存在的风险是无法准确确定哪些事务已经提交，解决方法需要考虑如何确定已提交的事务。 7. 备库异常重启后，使用单线程复制时，relay_log_recovery设置为ON，备库重启时可以找到正确位点复制数据，但需要注意积压的Relay Log和主库的Binlog的一致性。 8. 备库异常重启后，多线程复制的恢复过程更加复杂，需要考虑到各个worker线程提交的事务和GAQ队列的管理，以及GTID的使用对恢复过程的影响。 9. 在备库异常重启后，建议使用GTID Auto Position来简化恢复过程，确保数据复制正常进行。 10. 备库异常重启后，保证relay log不损坏的方法可以是开启GTID Auto Position，避免影响备库恢复。