对于 GTID 基础的复制，恢复过程需要 GTIDs 已经收到的或已经提交的交易。可以从源服务器使用 GTID 自动定位，自动将源服务器的交易与副本的交易进行比较，确定缺失的交易。

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

当使用基于GTID的复制时（gtid_mode=ON），设置SOURCE_AUTO_POSITION=1，激活连接到源的GTID自动定位，以自动识别和检索缺失的事务。该选项使用CHANGE REPLICATION SOURCE TO语句设置。如果副本有多个复制通道，您需要为每个通道设置该选项。关于GTID自动定位的详细信息，请见第19.1.3.3节，“GTID Auto-Positioning”。当使用基于文件位置的复制时，SOURCE_AUTO_POSITION=1不使用，而是使用二进制日志位置或中继日志位置来控制复制开始位置。

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

设置sync_relay_log=1，使复制接收线程在将每个事务写入relay log后将其同步到磁盘。这意味着从库的记录将永远不会超出源服务器的二进制日志（在applier元数据存储库中）中的当前位置记录。请注意，这个设置是最安全的，但也是最慢的，因为涉及到大量磁盘写入。使用sync_relay_log > 1或sync_relay_log=0（在操作系统中处理同步），在从库意外中断时可能会有未同步的事务，这些事务可能会导致恢复过程失败。如果恢复的从库，基于relay log中的信息，尝试重新应用事务，而不是跳过它们。设置sync_relay_log=1对多线程从库特别重要，因为恢复过程失败如果不能使用relay log中的信息填充事务序列的空缺。对于单线程从库，恢复过程只需要使用relay log，如果相关信息不可用在applier元数据存储库中。

设置innodb_flush_log_at_trx_commit=1,该设置将InnoDB日志同步到磁盘前每个事务提交。这是默认设置，确保InnoDB表和InnoDB日志在磁盘上保存，以避免在relay日志中记录事务的需求。与设置sync_relay_log=1组合使用，这样可以确保InnoDB表和InnoDB日志与relay日志的内容始终一致，以避免在事件中无法填充的gap在副本的交易历史中。

设置relay_log_info_repository = TABLE,该设置将replication SQL线程的位置存储在InnoDB表mysql.slave_relay_log_info中，并在事务提交时更新，以确保记录始终准确。这是默认设置；FILE已弃用。该系统变量本身也已弃用，因此忽略它并让它默认。使用FILE将信息存储在数据目录中的文件中，并在事务应用后更新。这将导致在处理事务时可能会丢失同步或文件本身的损坏。使用relay_log_info_repository = FILE，恢复是不可保证的。

设置relay_log_recovery = ON,该设置启用在服务器启动后立即启动relay日志恢复。这是全局变量，读取时为只读，但可以使用--relay-log-recovery选项在副本启动时启用。注意，这个设置忽略现有relay日志文件，如果它们是损坏或不一致的。relay日志恢复过程将启动新的relay日志文件，并从源开始获取事务，开始于applier元数据存储库中的replication SQL线程位置。之前的relay日志文件将在副本的正常清理机制中被删除。