群組複寫使用 GTID (全域交易識別碼) 來精確追蹤每部伺服器實例上已認可的交易。所有群組成員都必須設定 gtid_mode=ON
和 enforce_gtid_consistency=ON
。來自用戶端的傳入交易會由接收它們的群組成員指派 GTID。由群組成員在來自群組外部來源伺服器的非同步複寫通道上接收的任何複寫交易,都會保留它們抵達群組成員時擁有的 GTID。
指派給來自用戶端的傳入交易的 GTID,會使用 group_replication_group_name
系統變數指定的群組名稱作為識別碼的 UUID 部分,而不是接收交易的個別群組成員的伺服器 UUID。因此,可以直接由群組接收的所有交易都可以被識別,並在 GTID 集中分組在一起,而且哪個成員最初接收它們並不重要。每個群組成員都有為其使用保留的一連串連續 GTID 區塊,當這些區塊用完時,它會保留更多區塊。group_replication_gtid_assignment_block_size
系統變數設定區塊的大小,預設值為每個區塊 100 萬個 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 不同。
對於群組複寫通道 group_replication_applier
和 group_replication_recovery
,會套用 GTID_ONLY=1
、REQUIRE_ROW_FORMAT = 1
和 SOURCE_AUTO_POSITION = 1
。這些設定會在建立群組複寫通道時,或在複寫群組中的成員伺服器升級時,自動在群組複寫通道上設定。這些選項通常是使用 CHANGE REPLICATION SOURCE TO
陳述式設定,但請注意,您無法停用群組複寫通道的這些選項。設定這些選項後,群組成員不會在這些通道的複寫中繼資料儲存庫中保留檔案名稱和檔案位置。GTID 自動定位和 GTID 自動跳過用於在必要時找到正確的接收者和應用程式位置。
如果加入的成員在其 GTID 集合中具有群組現有成員所沒有的交易,則不允許其完成分散式復原程序,並且無法加入群組。如果執行了遠端複製操作,這些交易將被刪除並遺失,因為加入成員上的資料目錄會被清除。如果從捐贈者的二進位日誌執行狀態傳輸,這些交易可能會與群組的交易衝突。
如果在群組複寫停止時,在執行個體上執行管理交易,則成員上可能會存在額外交易。為了避免以這種方式引入新交易,在發出管理語句之前,請務必將 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 節「複製遠端資料」。如果需要該交易,請在成員成功重新加入後重新執行。