對於基於 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，這會指示複製接收器線程在每次接收到的交易寫入中繼日誌後，將中繼日誌同步到磁碟。這表示副本從來源的二進位日誌讀取的目前位置記錄（在應用程式元資料儲存庫中）永遠不會領先於儲存在中繼日誌中的交易記錄。請注意，雖然此設定最安全，但由於涉及的磁碟寫入次數，它也是最慢的。使用 sync_relay_log > 1 或 sync_relay_log=0（其中同步由作業系統處理），如果副本發生意外停止，則可能會有已提交但尚未同步到磁碟的交易。如果恢復副本根據中繼日誌中最後同步到磁碟的資訊，嘗試再次檢索並應用這些交易，而不是跳過它們，則此類交易可能會導致恢復過程失敗。設定 sync_relay_log=1 對於多線程副本尤其重要，如果無法使用中繼日誌中的資訊填補交易順序中的間隙，則恢復過程會失敗。對於單線程副本，如果相關資訊在應用程式元資料儲存庫中不可用，則恢復過程只需要使用中繼日誌。

設定 innodb_flush_log_at_trx_commit=1，這會在每次提交交易之前，將 InnoDB 日誌同步到磁碟。此設定是預設設定，可確保將 InnoDB 表格和 InnoDB 日誌儲存在磁碟上，因此不再需要中繼日誌中關於交易的資訊。結合設定 sync_relay_log=1，此設定進一步確保 InnoDB 表格的內容和 InnoDB 日誌與中繼日誌的內容始終保持一致，以便在發生意外停止時，清除中繼日誌檔案不會導致副本的交易歷史記錄中出現無法填補的間隙。

設定 relay_log_info_repository = TABLE，這會將複製 SQL 線程位置儲存在 InnoDB 表格 mysql.slave_relay_log_info 中，並與交易提交一起更新，以確保記錄始終準確。此設定為預設值；FILE 已棄用。系統變數本身也已棄用，因此請省略它並允許它採用預設值。如果使用 FILE，則資訊會儲存在資料目錄中的檔案中，該檔案會在應用交易後更新。這會產生與來源失去同步的風險，具體取決於副本在處理交易的哪個階段停止，甚至檔案本身也可能損毀。使用 relay_log_info_repository = FILE，無法保證恢復。

設定 relay_log_recovery = ON，這會在伺服器啟動後立即啟用自動中繼日誌恢復。此全域變數預設為 OFF，並且在執行時間為唯讀，但您可以使用 --relay-log-recovery 選項在副本意外停止後於副本啟動時將其設定為 ON。請注意，此設定會忽略現有的中繼日誌檔案，以防它們損毀或不一致。中繼日誌恢復過程會啟動一個新的中繼日誌檔案，並從來源檢索從應用程式元資料儲存庫中記錄的複製 SQL 線程位置開始的交易。先前的中繼日誌檔案會隨著時間推移，由副本的正常清除機制移除。