处理复制从属的意外中断

为了使复制能够应对服务器的意外停止（有时称为崩溃安全），从属必须在停止之前恢复其状态。本节介绍复制期间从属服务器意外停止的影响，以及如何配置从属服务器以最大程度地恢复继续复制。

从属服务器意外停止后，重新启动后，从属服务器的SQL线程必须恢复已执行的事务。恢复所需的信息存储在从站的中继日志信息日志中。从MySQL 8.0开始，默认情况下将此日志创建为一个InnoDB名为mysql.slave_relay_log_info（表的系统变量relay_log_info_repository设置为TABLE）的表。通过使用此事务性存储引擎，信息在重新启动后始终可恢复。

中继日志信息日志表的更新将与事务一起提交，这意味着即使在服务器意外停止的情况下，记录在该日志中的从属服务器的进度信息也始终与应用于数据库的信息保持一致。以前，此信息默认情况下存储在数据目录中的文件中，该文件在应用事务后已更新。这有可能失去与主机同步的风险，这取决于从机停止在哪个处理阶段，甚至文件本身损坏。该设置relay_log_info_repository = FILE现已弃用，并且在以后的版本中将被删除。有关从属日志的更多信息，请参见“复制中继和状态日志”。

当中继日志信息日志存储在mysql.slave_relay_log_info表中时，DML事务以及原子DDL一起自动进行以下三个更新：

• 在数据库上应用事务。
• 更新mysql.slave_relay_log_info表中的复制位置。
• 更新mysql.gtid_executed表中的GTID（在服务器上启用GTID并禁用二进制日志时）。

在所有其他情况下，包括不是完全原子的DDL语句和不支持原子DDL的豁免存储引擎，mysql.slave_relay_log_info如果服务器意外停止，则该表可能缺少与复制数据关联的更新。在这种情况下，恢复更新是手动过程。有关MySQL 8.0中对原子DDL的支持以及某些语句的复制所产生的行为的详细信息，请参见“原子数据定义语句支持”。

所选复制方法，从属服务器是单线程还是多线程，变量的设置（例如relay_log_recovery）以及是否MASTER_AUTO_POSITION使用了诸如的功能，都会影响复制从设备从意外停止中恢复的确切方式。

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

影响单线程复制从属恢复的因素

如下表所示，在使用单线程从属服务器时，以下配置可以最有效地防止意外停止：

• 使用GTID和时MASTER_AUTO_POSITION，设置relay_log_recovery=1。使用此配置，relay_log_info_repository和其他变量的设置不会影响恢复。请注意，为保证恢复，sync_binlog=1还必须在从属服务器上设置它（默认设置），以便在每次写入时将从属服务器的二进制日志同步到磁盘。否则，已提交的事务可能不会出现在从站的二进制日志中。

• 使用基于文件位置的复制时，请设置relay_log_recovery=1和relay_log_info_repository=TABLE。

  注意

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

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

影响多线程复制从属恢复的因素

如下表所示，使用多线程从站时，以下配置可最有效地防止意外停止：

• 使用GTID和时MASTER_AUTO_POSITION=ON，设置relay_log_recovery=1。使用此配置，relay_log_info_repository和其他变量的设置不会影响恢复。从MySQL 8.0.18起，当MASTER_AUTO_POSITION设置为时，多线程从属会自动跳过中继日志恢复ON，因此的设置relay_log_recovery没有区别。

• 当使用文件位置基于阵列的复制，组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，在意外停止后下次启动从属服务器时，将中继日志作为恢复的一部分进行处理。此过程完成后，将删除中继日志。

使用上面推荐的基于文件位置的复制配置来意外中断多线程复制从属服务器可能会导致中继日志具有意外中断导致的事务不一致（事务顺序中的间隙）。请参见“复制和事务不一致”。如果中继日志恢复过程遇到此类事务不一致，则会将其填充，并且恢复过程将自动继续。

当您使用多源复制和时relay_log_recovery=1，由于意外停止而重启后，所有复制通道都将通过中继日志恢复过程。将填充由于多线程从站的意外停止而在中继日志中发现的所有不一致。