对于基于 GTID 的复制，恢复过程需要副本已接收或提交的事务的 GTID。可以使用 GTID 自动定位从源中检索丢失的事务，它会自动将源的事务与副本的事务进行比较并识别丢失的事务。

对于基于文件位置的复制，恢复过程需要一个准确的复制 SQL 线程（应用程序）位置，以显示在副本上应用的最后一个事务。基于该位置，复制 I/O 线程（接收方）从源的二进制日志中检索从该点开始应应用于副本的所有事务。

当使用基于 GTID 的复制时 ( gtid_mode=ON)，设置 MASTER_AUTO_POSITION=1，这会激活 GTID 自动定位以连接到源以自动识别和检索丢失的事务。此选项使用CHANGE MASTER TO语句设置。如果副本有多个复制通道，则需要为每个通道单独设置此选项。有关 GTID 自动定位如何工作的详细信息，请参阅 第 16.1.3.3 节，“GTID 自动定位”。当使用基于文件位置的复制时， MASTER_AUTO_POSITION=1不使用，而是使用二进制日志位置或中继日志位置来控制复制开始的位置。

Set sync_relay_log=1，它指示复制 I/O 线程在每个接收到的事务写入后将中继日志同步到磁盘。这意味着从源的二进制日志（在源元数据存储库中）读取的当前位置的副本记录永远不会领先于保存在中继日志中的事务记录。请注意，虽然此设置是最安全的，但由于涉及的磁盘写入次数，它也是最慢的。与sync_relay_log > 1或sync_relay_log=0（其中同步由操作系统处理），如果副本意外停止，则可能有尚未同步到磁盘的已提交事务。如果恢复副本基于它在上次同步到磁盘的中继日志中的信息，尝试再次检索和应用事务而不是跳过它们，则此类事务可能导致恢复过程失败。环境 sync_relay_log=1对于多线程副本尤为重要，如果无法使用中继日志中的信息填充事务序列中的间隙，则恢复过程将失败。对于单线程副本，如果应用程序元数据存储库中没有相关信息，恢复过程只需要使用中继日志。

Set innodb_flush_log_at_trx_commit=1，InnoDB 在提交每个事务之前将日志同步到磁盘。此设置是默认设置，可确保 InnoDB表和 InnoDB日志保存在磁盘上，因此不再需要中继日志中有关事务的信息。结合设置sync_relay_log=1，这个设置进一步保证了 InnoDB表和 InnoDB日志的内容在任何时候都与中继日志的内容一致，这样清除中继日志文件就不会在副本的交易历史中造成无法填补的空白。意外停止事件。

Set relay_log_info_repository = TABLE，将复制SQL线程位置存储在InnoDB表中 mysql.slave_relay_log_info，并与事务提交一起更新，以确保记录始终准确。此设置不是 MySQL 5.7 中的默认设置。如果使用默认 FILE设置，则信息存储在数据目录中的一个文件中，该文件在应用事务后更新。这会产生与源失去同步的风险，具体取决于副本在处理事务的哪个阶段停止，甚至损坏文件本身。使用设置 relay_log_info_repository = FILE，无法保证恢复。

Set relay_log_recovery = ON，它在服务器启动后立即启用自动中继日志恢复。此全局变量默认为 OFF并且在运行时是只读的，但您可以在副本意外停止后使用副本启动ON时的 选项将其设置为。--relay-log-recovery请注意，此设置会忽略现有的中继日志文件，以防它们损坏或不一致。中继日志恢复进程启动一个新的中继日志文件，并从记录在应用程序元数据存储库中的复制 SQL 线程位置开始从源获取事务。副本的正常清除机制会随着时间的推移删除以前的中继日志文件。