为了使复制能够应对服务器的意外停止（有时称为崩溃安全），从属必须在停止之前恢复其状态。本节介绍复制期间从属服务器意外停止的影响，以及如何配置从属服务器以最大程度地恢复继续复制。
复制从属服务器意外停止后，重新启动后，从属服务器的SQL线程必须恢复已经执行了哪些事务。恢复所需的信息存储在从站的中继日志信息日志中。在较早的MySQL Server版本中，只能在应用事务后更新的数据目录中创建该日志作为文件。这有可能失去与主机同步的风险，这取决于从机停止在哪个处理阶段，甚至文件本身损坏。在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影响单线程复制从属恢复的因素+
注意
在恢复期间，中继日志将丢失。
下表显示了这些不同因素对多线程从站如何从意外停止中恢复的影响。
表17.2影响多线程复制从属恢复的因素
如下表所示，使用多线程从站时，以下配置可最有效地防止意外停止：
使用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，由于意外停止而重启后，所有复制通道都将通过中继日志恢复过程。将填充由于多线程从站的意外停止而在中继日志中发现的所有不一致。
