文件首頁
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


20.1.3.2 多主模式

在多主模式下 (group_replication_single_primary_mode=OFF),沒有成員具有特殊角色。任何與其他群組成員相容的成員,在加入群組時都會設定為讀寫模式,並且可以處理寫入交易,即使是同時發出的交易也是如此。

如果成員停止接受寫入交易,例如,發生意外的伺服器結束事件,連線至該成員的用戶端可以重新導向或故障轉移至任何其他處於讀寫模式的成員。群組複製本身不處理用戶端故障轉移,因此您需要使用中介軟體架構 (例如 MySQL Router 9.0)、Proxy、連線器或應用程式本身來安排此轉移。圖 20.5,「用戶端故障轉移」顯示如果成員離開群組,用戶端如何重新連線至替代群組成員。

圖 20.5 用戶端故障轉移

Five server instances, S1, S2, S3, S4, and S5, are deployed as an interconnected group. All of the servers are primaries. Write clients are communicating with servers S1 and S2, and a read client is communicating with server S4. Server S1 then fails, breaking communication with its write client. This client reconnects to server S3.

群組複製是一種最終一致性系統。這表示一旦傳入的流量減慢或停止,所有群組成員就會擁有相同的資料內容。在流量流動時,交易可能會在某些成員上比其他成員更早外部化,特別是如果某些成員的寫入輸送量比其他成員少,進而產生讀取過時資料的可能性。在多主模式中,較慢的成員也可能會累積過多的待認證和套用的交易,導致衝突和認證失敗的風險更高。若要限制這些問題,您可以啟用並調整群組複製的流量控制機制,以盡量減少快速成員和慢速成員之間的差異。如需流量控制的詳細資訊,請參閱第 20.7.2 節,「流量控制」

如果您想要群組中每個交易都保證交易一致性,可以使用 group_replication_consistency 系統變數來完成。您可以選擇適合您群組工作負載的設定,以及您對資料讀取和寫入的優先順序,並考量到增加一致性所需的同步處理對效能的影響。您也可以設定個別工作階段的系統變數,以保護特別對並行敏感的交易。如需交易一致性的詳細資訊,請參閱第 20.5.3 節,「交易一致性保證」

20.1.3.2.1 交易檢查

當群組部署在多主模式中時,會檢查交易以確保它們與模式相容。當群組複製部署在多主模式中時,會進行以下嚴格的一致性檢查

  • 如果交易在 SERIALIZABLE 隔離層級下執行,則當它與群組同步時,其認可會失敗。

  • 如果交易針對具有級聯條件約束的外鍵資料表執行,則當它與群組同步時,其認可會失敗。

這些檢查由 group_replication_enforce_update_everywhere_checks 系統變數控制。在多主模式中,系統變數通常應設定為 ON,但可以選擇透過將系統變數設定為 OFF 來停用檢查。在單主模式中部署時,系統變數必須設定為 OFF

20.1.3.2.2 資料定義陳述式

在多主模式的群組複製拓撲中,執行資料定義陳述式 (也稱為資料定義語言 (DDL)) 時,需要特別小心。

MySQL 9.0 支援原子資料定義語言 (DDL) 陳述式,其中完整的 DDL 陳述式會以單一原子交易認可或回復。DDL 陳述式,無論是否為原子,都會隱含地結束目前工作階段中任何作用中的交易,就像在執行陳述式之前執行了 COMMIT 一樣。這表示 DDL 陳述式無法在另一個交易中、在交易控制陳述式 (例如 START TRANSACTION ... COMMIT) 中執行,或是與同一個交易中的其他陳述式結合使用。

群組複製是以樂觀複製範例為基礎,其中陳述式會以樂觀方式執行,並在稍後必要時回復。每個伺服器都會在未先取得群組同意的情況下執行。因此,在多主模式中複製 DDL 陳述式時,需要更加小心。如果您對相同物件進行結構描述變更 (使用 DDL) 和對物件包含的資料進行變更 (使用 DML),則在結構描述作業尚未完成並在所有位置複製之前,這些變更必須透過相同的伺服器處理。如果作業中斷或僅部分完成,則未能這樣做可能會導致資料不一致。如果群組部署在單主模式中,則不會發生此問題,因為所有變更都是透過相同的伺服器 (主節點) 執行。

如需原子 DDL 支援的詳細資訊,請參閱第 15.1.1 節,「原子資料定義陳述式支援」

20.1.3.2.3 版本相容性

為了達到最佳的相容性和效能,群組中的所有成員應該執行相同版本的 MySQL 伺服器,因此也應使用相同版本的群組複製。在多主模式下,這一點更為重要,因為所有成員通常會以讀寫模式加入群組。如果群組包含執行多個 MySQL 伺服器版本的成員,則某些成員可能與其他成員不相容,因為他們支援的功能其他成員沒有,或者缺乏其他成員擁有的功能。為了防止這種情況,當新成員加入(包括已升級並重新啟動的前成員)時,該成員會對群組中的其他成員進行相容性檢查。

這些相容性檢查的一個結果在多主模式下尤其重要。如果加入的成員執行的 MySQL 伺服器版本高於現有群組成員執行的最低版本,則該成員會加入群組,但仍保持唯讀模式。(在單主模式下運行的群組中,新加入的成員在任何情況下預設都是唯讀的。)執行 MySQL 8.0.17 或更高版本的成員在檢查相容性時會考慮 MySQL 軟體的 major.minor.release 版本(因此也包含群組複製外掛程式的版本)。執行較早版本的成員只會考慮 major.minor 版本。

在以多主模式運行的群組中,如果成員使用不同的 MySQL 伺服器版本,群組複製會自動管理執行 MySQL 8.0.17 或更新版本的成員的讀寫和唯讀狀態。如果成員離開群組,則執行現在最低版本的成員會自動設定為讀寫模式。當您使用 group_replication_switch_to_multi_primary_mode() 函數將以單主模式運行的群組變更為以多主模式運行時,群組複製會自動將成員設定為正確的模式。如果成員執行的 MySQL 伺服器版本高於群組中存在的最低版本,則會自動將成員置於唯讀模式,而執行最低版本的成員則會置於讀寫模式。

有關群組中版本相容性的完整資訊,以及這如何影響群組在升級過程中的行為,請參閱 第 20.8.1 節「在群組中組合不同的成員版本」