您可以使用 CHANGE REPLICATION SOURCE TO 陳述式，告知副本變更為新的來源。副本不會檢查來源上的資料庫是否與副本上的資料庫相容；它只會開始讀取和執行來自新來源二進制日誌中指定座標的事件。在故障轉移的情況下，群組中的所有伺服器通常會執行來自相同二進制日誌檔案的相同事件，因此變更事件的來源不應影響資料庫的結構或完整性，前提是您在進行變更時謹慎小心。

副本應在啟用二進制日誌記錄的情況下執行（--log-bin 選項），這是預設值。如果您未使用 GTID 進行複製，則副本也應在 --log-replica-updates=OFF 的情況下執行（記錄副本更新是預設值）。這樣，副本就可以在不重新啟動副本 mysqld 的情況下，準備好成為來源。假設您具有 圖 19.4，「使用複製的冗餘，初始結構」 中所示的結構。

圖 19.4 使用複製的冗餘，初始結構

在此圖表中，Source 保留來源資料庫，Replica* 主機是副本，而 Web Client 機器正在發出資料庫讀取和寫入。僅發出讀取（通常會連線至副本）的 Web 用戶端不會顯示，因為它們在發生失敗時不需要切換至新的伺服器。如需讀取/寫入擴充複製結構的更詳細範例，請參閱 第 19.4.5 節，「使用複製進行擴充」。

每個 MySQL 複本（複本 1、複本 2 和 複本 3）都是啟用二進制日誌的複本，並使用 --log-replica-updates=OFF。由於當指定 --log-replica-updates=OFF 時，複本從來源接收的更新不會寫入二進制日誌，因此每個複本上的二進制日誌最初都是空的。如果由於某些原因 來源 變得不可用，您可以選擇其中一個複本成為新的來源。例如，如果您選擇 複本 1，則所有 Web 用戶端 都應重新導向至 複本 1，由它將更新寫入其二進制日誌。複本 2 和 複本 3 接著應從 複本 1 進行複寫。

以 --log-replica-updates=OFF 執行複本的原因是，為了防止在您使其中一個複本成為新來源時，複本收到兩次更新。如果 複本 1 啟用了 --log-replica-updates (預設設定)，它會將從 來源 收到的任何更新寫入自己的二進制日誌。這表示當 複本 2 將來源從 來源 變更為 複本 1 時，它可能會從 複本 1 收到它已從 來源 收到的更新。

請確保所有複本都已處理其轉送日誌中的所有語句。在每個複本上，執行 STOP REPLICA IO_THREAD，然後檢查 SHOW PROCESSLIST 的輸出，直到您看到 Has read all relay log。當所有複本都符合此條件時，可以將它們重新設定為新的設定。在升級為來源的複本 複本 1 上，執行 STOP REPLICA 和 RESET BINARY LOGS AND GTIDS。

在其他複本 複本 2 和 複本 3 上，使用 STOP REPLICA 和 CHANGE REPLICATION SOURCE TO SOURCE_HOST='Replica1'（其中 'Replica1' 代表 複本 1 的實際主機名稱）。若要使用 CHANGE REPLICATION SOURCE TO，請新增所有關於如何從 複本 2 或 複本 3 連線到 複本 1 的資訊 (可替換的 user、password、port)。當在此情境中執行語句時，不需要指定要讀取的 複本 1 二進制日誌檔案或日誌位置，因為預設值為第一個二進制日誌檔案和位置 4。最後，在 複本 2 和 複本 3 上執行 START REPLICA。

新的複寫設定就位後，您需要告知每個 Web 用戶端 將其語句導向 複本 1。從那一刻起，Web 用戶端 傳送至 複本 1 的所有更新都會寫入 複本 1 的二進制日誌中，其中接著包含自 來源 變得不可用以來傳送至 複本 1 的每個更新。

產生的伺服器結構顯示於圖 19.5 「來源失敗後使用複寫的備援」。

圖 19.5 來源失敗後使用複寫的備援

當 來源 再次可用時，您應使其成為 複本 1 的複本。若要執行此作業，請在 來源 上執行與先前在 複本 2 和 複本 3 上執行的相同的 CHANGE REPLICATION SOURCE TO 語句。來源 接著會成為 複本 1 的複本，並擷取它離線時錯過的 Web 用戶端 寫入。

若要使 來源 再次成為來源，請使用先前的程序，如同 複本 1 不可用且 來源 將成為新的來源一樣。在此程序期間，不要忘記在使 複本 1、複本 2 和 複本 3 成為 來源 的複本之前，先在 來源 上執行 RESET BINARY LOGS AND GTIDS。如果您未能執行此作業，複本可能會擷取 Web 用戶端 應用程式在 來源 變得不可用之前過時的寫入。

您應該注意，即使複本共用相同的來源，它們之間也沒有同步，因此某些複本可能會明顯領先於其他複本。這表示在某些情況下，先前範例中概述的程序可能無法如預期般運作。但在實務上，所有複本上的轉送日誌應該相對接近。

保持應用程式了解來源位置的一種方法是為來源主機建立動態 DNS 項目。使用 BIND，您可以使用 nsupdate 來動態更新 DNS。