文件首頁
MySQL 9.0 參考手冊
相關文件 下載本手冊
PDF (US Ltr) - 40.0Mb
PDF (A4) - 40.1Mb
Man Pages (TGZ) - 258.2Kb
Man Pages (Zip) - 365.3Kb
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 集合,以及效能架構 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 已由第一個通道新增至 gtid_executed 集合中。如果通道上的篩選相同,則沒有問題,因為交易的所有版本都包含相同的資料,因此結果相同。但是,如果通道上的篩選不同,則資料庫可能會變得不一致,且複寫可能會停止。