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


20.1.3.2 多主模式

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

如果某個成員停止接受寫入交易,例如,在發生非預期的伺服器結束事件時,連線至該成員的用戶端可以重新導向或故障轉移至任何其他處於讀寫模式的成員。群組複製本身不處理用戶端故障轉移,因此您需要使用中介軟體架構(例如 MySQL Router 8.4)、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 8.4 支援原子資料定義語言 (DDL) 陳述式,其中完整的 DDL 陳述式會以單一原子交易的形式認可或回復。DDL 陳述式 (無論是否為原子) 都會隱含地結束目前工作階段中任何作用中的交易,就像您在執行陳述式之前已執行 COMMIT 一樣。這表示 DDL 陳述式無法在另一個交易內執行、無法在 START TRANSACTION ... COMMIT 等交易控制陳述式內執行,也無法在同一個交易內與其他陳述式組合執行。

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

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

20.1.3.2.3 版本相容性

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

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

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

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