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


20.1.3.1 單一主節點模式

在單一主節點模式下 (group_replication_single_primary_mode=ON),群組會有一個設定為讀寫模式的單一主伺服器。群組中的所有其他成員都會設定為唯讀模式 (使用 super_read_only=ON)。主節點通常是第一個引導群組的伺服器。所有其他加入群組的伺服器都會了解主伺服器,並自動設定為唯讀模式。

在單一主節點模式下,群組複製會強制只有單一伺服器寫入群組,因此與多主節點模式相比,一致性檢查可以較不嚴格,而且不需要特別處理 DDL 陳述式。選項 group_replication_enforce_update_everywhere_checks 會啟用或停用群組的嚴格一致性檢查。當以單一主節點模式部署,或將群組變更為單一主節點模式時,此系統變數必須設定為 OFF

指定為主伺服器的成員可以透過下列方式變更

  • 如果現有的主節點離開群組 (無論是自願或意外),系統會自動選出新的主節點。

  • 您可以使用 group_replication_set_as_primary() 函數,將特定成員指定為新的主節點。

  • 如果您使用 group_replication_switch_to_single_primary_mode() 函數,將在多主節點模式下執行的群組變更為在單一主節點模式下執行,系統會自動選出新的主節點,或者您可以透過使用函數指定新的主節點。

當系統自動選出或手動指定新的主伺服器時,它會自動設定為讀寫,而其他群組成員則會保持為次要節點,因此為唯讀。圖 20.4,「新的主節點選取」顯示此流程。

圖 20.4:新的主節點選取

Five server instances, S1, S2, S3, S4, and S5, are deployed as an interconnected group. Server S1 is the primary. Write clients are communicating with server S1, and a read client is communicating with server S4. Server S1 then fails, breaking communication with the write clients. Server S2 then takes over as the new primary, and the write clients now communicate with server S2.

當選出或指定新的主節點時,它可能會有在舊主節點上已套用但尚未在此伺服器上套用的變更待辦事項。在這種情況下,直到新的主節點趕上舊主節點之前,讀寫交易可能會導致衝突而被復原,而唯讀交易可能會導致過時的讀取。如果啟用並正確調整,群組複製的流量控制機制會最小化快速和慢速成員之間的差異,以減少這種情況發生的機率。如需流量控制的詳細資訊,請參閱第 20.7.2 節,「流量控制」。您也可以使用 group_replication_consistency 系統變數,設定群組的交易一致性層級以防止此問題。將其設定為 BEFORE_ON_PRIMARY_FAILOVER 或任何更高的一致性層級,會在新的選出主節點上保留新交易,直到套用完待辦事項為止。(在 MySQL 8.4 中,這是預設值。)

如需交易一致性的詳細資訊,請參閱第 20.5.3 節,「交易一致性保證」。如果群組未使用流量控制和交易一致性保證,最好等待新的主節點套用其複寫相關的轉發記錄,然後再將用戶端應用程式重新路由至該節點。

20.1.3.1.1 主節點選取演算法

自動主成員選取流程包含每個成員檢視群組的新檢視、排序潛在的新主成員,並選擇最符合資格的成員。每個成員都會在本機做出自己的決定,並遵循其 MySQL 伺服器版本中的主節點選取演算法。由於所有成員都必須達成相同的決定,因此如果其他群組成員正在執行較低的 MySQL 伺服器版本,成員會調整其主節點選取演算法,使其行為與群組中最低 MySQL 伺服器版本的成員相同。

成員在選取主節點時依序考量的因素如下

  1. 考量的第一個因素是哪個或哪些成員正在執行最低的 MySQL 伺服器版本。如果所有群組成員都執行 MySQL 8.0.17 或更高版本,則會先依其版本的修補程式版本排序成員。(如果任何成員執行的是 MySQL 8.0.16 或更早版本 (不建議搭配執行 MySQL 8.4 的成員使用),則會先依其版本的主要版本排序這些成員,並忽略修補程式版本。)

  2. 如果有多個成員執行最低的 MySQL 伺服器版本,則考量的第二個因素是每個成員的成員權重,如成員上的 group_replication_member_weight 系統變數所指定。

    系統變數 group_replication_member_weight 指定一個 0 到 100 範圍的數字。所有成員預設的權重為 50,因此將權重設定低於此值會降低其排序,而將權重設定高於此值會提高其排序。您可以使用此加權功能來優先使用較好的硬體,或確保在主要成員進行排定的維護期間故障轉移至特定成員。

  3. 如果有一個以上的成員正在執行最低的 MySQL Server 版本,且這些成員中有多個具有最高的成員權重 (或成員權重被忽略),則會考量第三個因素,即每個成員產生之伺服器 UUID 的詞彙順序,如系統變數 server_uuid 所指定。具有最低伺服器 UUID 的成員會被選為主要成員。這個因素作為一個有保證且可預測的決勝因素,以便在無法由任何重要因素決定時,所有群組成員都能達成相同的決策。

20.1.3.1.2 尋找主要成員

若要找出以單一主要模式部署時,目前哪一個伺服器是主要成員,請使用 performance_schema.replication_group_members 表格中的 MEMBER_ROLE 欄位。例如

mysql> SELECT MEMBER_HOST, MEMBER_ROLE FROM performance_schema.replication_group_members;
+-------------------------+-------------+
| MEMBER_HOST             | MEMBER_ROLE |
+-------------------------+-------------+
| remote1.example.com     | PRIMARY     |
| remote2.example.com     | SECONDARY   |
| remote3.example.com     | SECONDARY   |
+-------------------------+-------------+