文件首頁
MySQL 9.0 參考手冊
相關文件 下載本手冊
PDF (美國信紙) - 40.0Mb
PDF (A4) - 40.1Mb
Man Pages (TGZ) - 258.2Kb
Man Pages (Zip) - 365.3Kb
Info (Gzip) - 4.0Mb
Info (Zip) - 4.0Mb


MySQL 9.0 參考手冊  /  ...  /  GTID 和群組複製

20.4.1 GTID 和群組複製

群組複製使用 GTID (全域交易識別碼) 來追蹤每個伺服器執行個體上已提交的交易。所有群組成員都必須設定 gtid_mode=ONenforce_gtid_consistency=ON。來自用戶端的傳入交易會由接收它們的群組成員指派 GTID。在群組成員上,從群組外部的來源伺服器透過非同步複製通道接收的任何複寫交易,都會保留它們抵達群組成員時所擁有的 GTID。

指派給來自用戶端的傳入交易的 GTID 會使用 group_replication_group_name 系統變數指定的群組名稱作為識別碼的 UUID 部分,而不是接收交易之個別群組成員的伺服器 UUID。因此,可以直接由群組接收的所有交易都可以識別,並在 GTID 集中分組在一起,並且哪個成員最初接收它們都無關緊要。每個群組成員都有為其使用保留的一連串 GTID 區塊,當這些 GTID 用完時,它會保留更多 GTID。group_replication_gtid_assignment_block_size 系統變數設定區塊的大小,預設值為每個區塊 1 百萬個 GTID。

檢視變更事件 (View_change_log_event) 是在有新成員加入時由群組本身產生,當它們記錄在二進位記錄檔中時,會被給予 GTID。依預設,這些事件的 GTID 也會使用 group_replication_group_name 系統變數指定的群組名稱作為識別碼的 UUID 部分。您可以設定群組複製系統變數 group_replication_view_change_uuid,以便在檢視變更事件的 GTID 中使用替代的 UUID,讓它們很容易與群組從用戶端接收的交易區分開來。如果您的設定允許在群組之間進行容錯移轉,並且您需要識別並捨棄備份群組特有的交易,這會很有用。替代的 UUID 必須與成員的伺服器 UUID 不同。它也必須與使用 CHANGE REPLICATION SOURCE TO 語法的 ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS 選項套用至匿名交易的 GTID 中的任何 UUID 不同。

GTID_ONLY=1REQUIRE_ROW_FORMAT = 1SOURCE_AUTO_POSITION = 1 會套用至群組複製通道 group_replication_appliergroup_replication_recovery。當建立這些通道時,或當複寫群組中的成員伺服器升級時,會在群組複製通道上自動進行設定。這些選項通常使用 CHANGE REPLICATION SOURCE TO 語法來設定,但請注意,您無法為群組複製通道停用它們。設定這些選項後,群組成員不會在這些通道的複寫中繼資料存放庫中保存檔案名稱和檔案位置。GTID 自動定位和 GTID 自動略過用於在必要時找到正確的接收器和應用程式位置。

額外交易

如果加入的成員在其 GTID 集中有群組現有成員中不存在的交易,則不允許它完成分散式復原程序,而且無法加入群組。如果執行遠端複製作業,這些交易將會被刪除並遺失,因為加入成員上的資料目錄會被清除。如果執行來自捐贈者二進位記錄檔的狀態傳輸,這些交易可能會與群組的交易衝突。

如果當 Group Replication 停止時,在執行個體上執行了管理交易,則成員上可能會出現額外的交易。為了避免以這種方式引入新的交易,在發出管理語句之前,請務必將 sql_log_bin 系統變數的值設為 OFF,之後再設回 ON

SET SQL_LOG_BIN=0;
<administrator action>
SET SQL_LOG_BIN=1;

將此系統變數設定為 OFF 表示從該點開始到您將其設定回 ON 為止所發生的交易不會寫入二進制日誌,也不會被指派 GTID。

如果加入的成員上存在額外的交易,請檢查受影響伺服器的二進制日誌,以查看額外的交易實際包含的內容。調和加入成員的資料和 GTID 集合與目前群組中成員的最安全方法是使用 MySQL 的複製功能,將群組中伺服器的內容傳輸到受影響的伺服器。有關執行此操作的說明,請參閱 第 7.6.7.3 節「複製遠端資料」。如果需要該交易,請在成員成功重新加入後重新執行。