17.3.2 处理副本服务器的意外停止

MySQL 8.0 参考手册 / 第十七章复制 / 17.4 复制解决方案 / 17.3.2 处理副本服务器的意外停止

17.3.2 处理副本服务器的意外停止

为了使复制能够对服务器的意外停止（有时被描述为崩溃安全）具有弹性，副本必须能够在停止之前恢复其状态。本节介绍复制过程中副本意外停止的影响，以及如何配置副本以获得最佳恢复机会以继续复制。

在副本意外停止后，副本的 SQL 线程重新启动时必须恢复已经执行的事务。恢复所需的信息存储在副本的应用程序元数据存储库中。在较旧的 MySQL 服务器版本中，此日志只能创建为数据目录中的文件，该文件在应用事务后更新。这存在与源失去同步的风险，具体取决于副本在处理事务的哪个阶段停止，甚至文件本身损坏。在 MySQL 5.6 中，您可以改用InnoDB用于存储应用程序元数据存储库的表。通过使用这个事务性存储引擎，信息总是可以在重启时恢复。作为一个表，对应用程序元数据存储库的更新与事务一起提交，这意味着记录在该存储库中的副本进度信息始终与已应用到数据库的内容一致，即使在服务器意外停机的情况下也是如此。

要配置 MySQL 5.6 以将应用程序元数据存储库存储为InnoDB表，请将系统变量设置 relay_log_info_repository为 TABLE. 服务器然后将恢复复制 SQL 线程所需的信息存储在 mysql.slave_relay_log_info表中。有关复制元数据存储库的更多信息，请参阅第 17.2.2 节，“中继日志和复制元数据存储库”。

副本如何从意外停止中恢复取决于所选择的复制方法、副本是单线程还是多线程、变量的设置（例如 relay_log_recovery）以及是否MASTER_AUTO_POSITION正在使用等功能。

下表显示了这些不同因素对单线程副本如何从意外停止中恢复的影响。

表 17.1 影响单线程副本恢复的因素

GTID	MASTER_AUTO_POSITION	`relay_log_recovery`	`relay_log_info_repository`	崩溃类型	保证恢复	中继日志影响
离开	不相干	1个	桌子	服务器	是的	丢失的
离开	不相干	1个	任何	操作系统	不	丢失的
离开	不相干	0	桌子	服务器	是的	遗迹
离开	不相干	0	桌子	操作系统	不	遗迹
上	上	1个	不相干	不相干	是的	丢失的
上	离开	0	桌子	服务器	是的	遗迹
上	离开	0	任何	操作系统	不	遗迹

如表所示，当使用单线程副本时，以下配置对意外停止最具弹性：

使用 GTID 和MASTER_AUTO_POSITION时，设置relay_log_recovery=1. 使用此配置， relay_log_info_repository和其他变量的设置不会影响恢复。请注意，为了保证恢复， sync_binlog=1还必须在副本上设置，以便副本的二进制日志在每次写入时同步到磁盘。否则，提交的事务可能不会出现在副本的二进制日志中。
使用基于文件位置的复制时，设置 relay_log_recovery=1和 relay_log_info_repository=TABLE.

笔记

在恢复期间中继日志丢失。

下表显示了这些不同因素对多线程副本如何从意外停止中恢复的影响。

表 17.2 影响多线程副本恢复的因素

GTID	`sync_relay_log`	`MASTER_AUTO_POSITION`	`relay_log_recovery`	`relay_log_info_repository`	崩溃类型	保证恢复	中继日志影响
离开	1个	不相干	1个	桌子	任何	是的	丢失的
离开	>1	不相干	1个	桌子	服务器	是的	丢失的
离开	>1	不相干	1个	任何	操作系统	不	丢失的
离开	1个	不相干	0	桌子	服务器	是的	遗迹
离开	1个	不相干	0	桌子	操作系统	不	遗迹
上	任何	上	1个	任何	任何	是的	丢失的
上	1个	离开	0	桌子	服务器	是的	遗迹
上	1个	离开	0	任何	操作系统	不	遗迹

如表所示，当使用多线程副本时，以下配置对意外停止最具弹性：

使用 GTID 和MASTER_AUTO_POSITION时，设置relay_log_recovery=1. 使用此配置， relay_log_info_repository和其他变量的设置不会影响恢复。
使用基于文件位置的复制时，设置 relay_log_recovery=1、 sync_relay_log=1和 relay_log_info_repository=TABLE。

笔记

在恢复期间中继日志丢失。

重要的是要注意的影响 sync_relay_log=1，这需要在每个事务中写入中继日志。尽管此设置对意外停止最有弹性，最多丢失一个未写入的事务，但它也有可能大大增加存储负载。如果没有 sync_relay_log=1，意外停止的影响取决于操作系统如何处理中继日志。另请注意，当 relay_log_recovery=0下一次副本在意外停止后启动时，中继日志将作为恢复的一部分进行处理。此过程完成后，中继日志将被删除。

使用上面推荐的基于文件位置的复制配置的多线程副本意外停止可能会导致中继日志中出现由意外停止引起的事务不一致（事务序列中的间隙）。请参阅复制和事务不一致。在 MySQL 5.7.13 及更高版本中，如果中继日志恢复过程遇到此类事务不一致，它们将被填充并且恢复过程会自动继续。在 MySQL 5.7.13 之前的 MySQL 版本中，此过程不是自动的，需要使用启动服务器 relay_log_recovery=0，使用启动副本 START SLAVE UNTIL SQL_AFTER_MTS_GAPS以修复任何事务不一致，然后使用重新启动副本 relay_log_recovery=1.

当您使用多源复制 relay_log_recovery=1时，由于意外停止而重新启动后，所有复制通道都会经过中继日志恢复过程。由于多线程副本的意外停止而在中继日志中发现的任何不一致都会被填充。