对于基于 GTID 的复制，恢复过程需要副本已经收到或提交的事务的 GTID。可以使用 GTID 自动定位来检索遗漏的事务，该方法自动比较源的事务与副本的事务，以确定遗漏的事务。

对于基于文件位置的复制，恢复过程需要副本的精确复制 SQL 线程（应用程序）位置，显示最后一个应用于副本的交易。基于该位置，复制 I/O 线程（接收器）从源的二进制日志中检索所有应该应用于副本的交易。

当使用基于GTID的复制（gtid_mode=ON）时，设置 SOURCE_AUTO_POSITION=1，激活GTID自动定位，以自动识别和检索缺失的事务。这项选项使用 CHANGE REPLICATION SOURCE TO 语句设置。如果副本有多个复制通道，需要为每个通道单独设置该选项。有关GTID自动定位的工作原理，请参见 第19.1.3.3节，“GTID自动定位”。当使用基于文件位置的复制时，不使用 SOURCE_AUTO_POSITION=1，而是使用二进制日志位置或中继日志位置来控制复制的起点。

当使用基于GTID的复制（gtid_mode=ON）时，设置 GTID_ONLY=1，使副本仅使用GTID在恢复过程中，并停止在复制元数据存储库中持久化二进制日志和中继日志文件名和文件位置。这项选项使用 CHANGE REPLICATION SOURCE TO 语句设置。如果副本有多个复制通道，需要为每个通道单独设置该选项。使用 GTID_ONLY=1，在恢复过程中，文件位置信息将被忽略，并使用GTID自动跳过已经提供的事务，而不是确定正确的文件位置。这项策略更高效，前提是使用默认设置的 relay_log_purge，这意味着只需要检查一个中继日志文件。

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

设置 innodb_flush_log_at_trx_commit=1，将 InnoDB 日志同步到磁盘之前每个事务提交。这项设置，作为默认设置，确保 InnoDB 表和 InnoDB 日志被保存到磁盘上，以便不再需要中继日志中的信息来记录事务。与 sync_relay_log=1 结合使用，这项设置进一步确保 InnoDB 表和 InnoDB 日志的内容始终与中继日志的内容保持一致，以便在副本意外停止的情况下，purge中继日志文件不会导致事务历史记录中的间隙无法填充。

设置 relay_log_info_repository = TABLE，它将复制SQL线程位置存储在 InnoDB 表 mysql.slave_relay_log_info 中，并在事务提交时更新，以确保记录始终准确。这是默认设置；FILE 已弃用。该系统变量本身也已弃用，因此请省略它并允许它采用默认值。如果使用 FILE，信息将存储在数据目录中的文件中，该文件将在事务应用后更新。这会在复制源停止时创建同步风险，或者文件本身可能会损坏。使用 relay_log_info_repository = FILE，恢复不能保证。

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