MySQL :: MySQL 8.4 參考手冊 :: 19.4.8 容錯移轉期間切換來源

版本 8.4

8.0 日語

MySQL 8.4 參考手冊 / ... / 容錯移轉期間切換來源

19.4.8 容錯移轉期間切換來源

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

副本應該在啟用二進位記錄 (預設為 --log-bin 選項) 的情況下執行。如果您沒有使用 GTID 進行複製，則副本也應該在 --log-replica-updates=OFF 的情況下執行 (預設為記錄副本更新)。這樣，副本就準備好成為來源，而無需重新啟動副本 mysqld。假設您有圖 19.4，「使用複製進行冗餘，初始結構」中所示的結構。

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

Two web clients direct both database reads and database writes to a single MySQL source server. The MySQL source server replicates to Replica 1, Replica 2, and Replica 3.

在此圖表中，來源保存來源資料庫，副本* 主機是副本，而 Web 用戶端機器正在發出資料庫讀取和寫入。僅發出讀取的 Web 用戶端 (通常會連線到副本) 未顯示，因為它們在發生故障時不需要切換到新的伺服器。如需讀寫擴展複製結構的更詳細範例，請參閱章節 19.4.5，「使用複製進行擴展」。

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

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

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

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

新的複寫設定就緒後，您需要告訴每個 Web Client 將其語句導向至 Replica 1。從那時起，Web Client 傳送至 Replica 1 的所有更新都會寫入 Replica 1 的二進制日誌，其中包含自 Source 變得不可用以來傳送至 Replica 1 的所有更新。

產生的伺服器結構顯示在圖 19.5，「使用複寫實現冗餘，來源故障後」。

圖 19.5 使用複寫實現冗餘，來源故障後

The MySQL source server has failed, and is no longer connected into the replication topology. The two web clients now direct both database reads and database writes to Replica 1, which is the new source. Replica 1 replicates to Replica 2 and Replica 3.

當 Source 再次可用時，您應該使其成為 Replica 1 的複本。若要執行此操作，請在 Source 上發出與先前在 Replica 2 和 Replica 3 上發出的相同 CHANGE REPLICATION SOURCE TO 語句。Source 接著會成為 Replica 1 的複本，並擷取它在離線期間錯過的 Web Client 寫入。

若要再次將 Source 設定為來源，請使用先前的程序，如同 Replica 1 不可用且 Source 將成為新來源一樣。在此程序中，不要忘記在將 Replica 1、Replica 2 和 Replica 3 設定為 Source 的複本之前，在 Source 上執行 RESET BINARY LOGS AND GTIDS。如果您沒有執行此操作，複本可能會從 Web Client 應用程式中擷取過時的寫入，這些寫入的日期早於 Source 變得不可用的時間點。

您應該知道複本之間沒有同步，即使它們共用相同的來源也是如此，因此某些複本可能會明顯超前其他複本。這表示在某些情況下，先前範例中概述的程序可能無法如預期般運作。不過，實際上，所有複本上的傳輸日誌應該相對接近。

讓應用程式隨時掌握來源位置的一種方法是為來源主機設定動態 DNS 項目。使用 BIND，您可以使用 nsupdate 來動態更新 DNS。