文件首頁
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.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 或任何更高的一致性層級,會在新的主伺服器上暫停新交易,直到套用待辦事項為止。(這是預設值。)

如需交易一致性的詳細資訊,請參閱 第 20.5.3 節,「交易一致性保證」。如果群組未使用流量控制和交易一致性保證,則最好等待新的主伺服器套用其與複製相關的轉送日誌,再將用戶端應用程式重新路由至該伺服器。

20.1.3.1.1 主伺服器選舉演算法

自動主要成員選舉流程包含每個成員檢視群組的新視圖、對潛在的新主要成員進行排序,並選擇最符合條件的成員。每個成員根據其 MySQL 伺服器版本中的主要選舉演算法,在本地做出自己的決定。由於所有成員都必須達成相同的決定,如果其他群組成員執行的是較舊版本的 MySQL 伺服器,成員會調整其主要選舉演算法,以便與群組中 MySQL 伺服器版本最低的成員具有相同的行為。

成員在選出主要成員時會依序考量以下因素:

  1. 首先考量的因素是哪個或哪些成員執行的是最低的 MySQL 伺服器版本。如果所有群組成員都執行 MySQL 8.0.17 或更高版本,則會先依據其版本的修補程式版本對成員進行排序。(如果有任何成員執行的是 MySQL 8.0.16 或更早版本—不建議在有成員執行 MySQL 9.0 的情況下使用—則會先依據其版本的主要版本對這些成員進行排序,而忽略修補程式版本。)

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

    group_replication_member_weight 系統變數指定一個 0 到 100 範圍內的數字。所有成員的預設權重都是 50,因此設定低於此值的權重會降低其排序,設定高於此值的權重則會增加其排序。您可以使用此權重功能來優先使用較佳的硬體,或在主要成員的排程維護期間確保容錯移轉至特定成員。

  3. 如果有超過一個成員執行的是最低的 MySQL 伺服器版本,而且這些成員中有超過一個成員具有最高的成員權重(或成員權重被忽略),則第三個考量的因素是每個成員產生的伺服器 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   |
+-------------------------+-------------+