文件首頁
MySQL 8.4 參考手冊
相關文件 下載本手冊
PDF (美式信紙) - 39.9Mb
PDF (A4) - 40.0Mb
Man Pages (TGZ) - 258.5Kb
Man Pages (Zip) - 365.5Kb
Info (Gzip) - 4.0Mb
Info (Zip) - 4.0Mb


19.1.3.3 GTID 自動定位

GTID 取代先前需要用來判斷在來源與副本之間啟動、停止或恢復資料流動位置的檔案偏移配對。當使用 GTID 時,副本需要與來源同步的所有資訊都是直接從複製資料流取得的。

若要使用基於 GTID 的複製啟動副本,您需要在 CHANGE REPLICATION SOURCE TO 陳述式中啟用 SOURCE_AUTO_POSITION 選項。替代的 SOURCE_LOG_FILESOURCE_LOG_POS 選項會指定日誌檔案的名稱以及檔案內的起始位置,但是當使用 GTID 時,副本不需要此非本地資料。如需使用基於 GTID 的複製配置與啟動來源和副本的完整說明,請參閱第 19.1.3.4 節「使用 GTID 設定複製」

SOURCE_AUTO_POSITION 選項預設為停用。如果副本上啟用多來源複製,您需要為每個適用的複製通道設定此選項。再次停用 SOURCE_AUTO_POSITION 選項會導致副本還原為基於檔案的複製;這表示當 GTID_ONLY=ON 時,某些位置可能會標示為無效,在這種情況下,當停用 SOURCE_AUTO_POSITION 時,您也必須指定 SOURCE_LOG_FILESOURCE_LOG_POS

當副本啟用 GTID (設定 GTID_MODE=ONON_PERMISSIVEOFF_PERMISSIVE) 且啟用 SOURCE_AUTO_POSITION 選項時,會啟用自動定位以連接到來源。來源必須設定 GTID_MODE=ON 才能成功連線。在初始交握時,副本會傳送一個 GTID 集合,其中包含它已接收、提交或兩者皆有的交易。此 GTID 集合等於 gtid_executed 系統變數 (@@GLOBAL.gtid_executed) 中 GTID 的集合,以及 Performance Schema replication_connection_status 資料表中記錄的已接收交易的 GTID 集合 (執行語句 SELECT RECEIVED_TRANSACTION_SET FROM PERFORMANCE_SCHEMA.replication_connection_status 的結果)。

來源會回傳在其二進制日誌中記錄的所有交易,這些交易的 GTID 不包含在副本傳送的 GTID 集合中。為此,來源會先從最新的二進制日誌檔案開始,檢查每個二進制日誌檔案標頭中的 Previous_gtids_log_event,以識別開始使用的適當二進制日誌檔案。當來源找到第一個 Previous_gtids_log_event,其中不包含副本遺失的任何交易時,它會從該二進制日誌檔案開始。此方法非常有效率,只有當副本落後來源大量的二進制日誌檔案時,才會花費大量的時間。然後,來源會讀取該二進制日誌檔案和後續檔案中直到目前檔案的交易,並傳送副本遺失的 GTID 的交易,跳過副本傳送的 GTID 集合中的交易。副本收到第一個遺失交易的時間取決於它在二進制日誌檔案中的偏移量。此交換確保來源僅傳送副本尚未接收或提交的 GTID 的交易。如果副本從多個來源接收交易,例如在菱形拓撲中,自動跳過功能可確保交易不會被應用兩次。

如果任何應由來源傳送的交易已從來源的二進制日誌中清除,或以其他方式新增至 gtid_purged 系統變數中的 GTID 集合,來源會傳送錯誤 ER_SOURCE_HAS_PURGED_REQUIRED_GTIDS 給副本,且複寫不會啟動。遺失的已清除交易的 GTID 會被識別並列在來源的錯誤日誌中,在警告訊息 ER_FOUND_MISSING_GTIDS 中。副本無法從此錯誤中自動恢復,因為趕上來源所需的交易歷史記錄部分已遭清除。嘗試在未啟用 SOURCE_AUTO_POSITION 選項的情況下重新連線只會導致副本遺失已清除的交易。從這種情況恢復的正確方法是讓副本從另一個來源複寫 ER_FOUND_MISSING_GTIDS 訊息中列出的遺失交易,或者讓新的副本取代該副本,該副本是從較新的備份建立的。請考慮修改來源上的二進制日誌過期期限 (binlog_expire_logs_seconds),以確保此情況不再發生。

如果在交易交換期間發現副本已接收或提交 GTID 中具有來源 UUID 的交易,但來源本身沒有這些交易的記錄,則來源會傳送錯誤 ER_REPLICA_HAS_MORE_GTIDS_THAN_SOURCE 給副本,且複寫不會啟動。如果未設定 sync_binlog=1 的來源發生電源故障或作業系統崩潰,且遺失尚未同步到二進制日誌檔案的已提交交易,但副本已接收這些交易,則可能發生這種情況。如果任何用戶端在來源重新啟動後在來源上提交交易,來源和副本可能會發散,這可能導致來源和副本對不同的交易使用相同的 GTID。從這種情況恢復的正確方法是手動檢查來源和副本是否發散。如果現在對不同的交易使用相同的 GTID,您需要根據需要對個別交易執行手動衝突解決,或者從複寫拓撲中移除來源或副本。如果問題僅是來源遺失交易,您可以改為讓來源變成副本,使其趕上複寫拓撲中的其他伺服器,然後在需要時再次使其成為來源。

對於菱形拓撲中的多來源副本 (其中副本從兩個或多個來源複寫,而這些來源又從共同來源複寫),當使用基於 GTID 的複寫時,請確保多來源副本上所有通道上的任何複寫篩選器或其他通道組態都相同。使用基於 GTID 的複寫時,篩選器僅應用於交易資料,並且不會篩選掉 GTID。這樣做是為了使副本的 GTID 集合與來源保持一致,這表示可以使用 GTID 自動定位,而無需每次都重新獲取已篩選出的交易。在下游副本是多來源並且從菱形拓撲中的多個來源接收到同一交易的情況下,下游副本現在具有多個版本的交易,結果取決於哪個通道先應用該交易。第二個嘗試的通道會使用 GTID 自動跳過來跳過該交易,因為該交易的 GTID 已被第一個通道新增至 gtid_executed 集合。如果通道上的篩選相同,則不會有問題,因為所有版本的交易都包含相同的資料,因此結果相同。但是,如果通道上的篩選不同,則資料庫可能會變得不一致,並且複寫可能會掛起。