實驗演示規劃:（3臺虛擬機器，MySQL版本為8.0.25）

• 192.168.168.101 master1（簡稱1節點）

• 192.168.168.102 slave2 （簡稱2節點）

• 192.168.168.103 slave3 （簡稱3節點）

在 MGR 中，單主模式是隻有一個主節點可以寫，其餘均為只讀節點，且只讀節點的 super read only為開啟狀態，即使 root使用者依然無法寫。多主模式則為全節點均可寫。

01單主切多主

MGR 單切多使用的命令為：

select group_replication_switch_to_multi_primary_mode();

首先我們觀察當前叢集的模式和各個節點的讀寫模式：

select * from performance_schema.replication_group_members;show variables like '%read_only%';

1節點：

2節點：

3節點：

可以看到，各個節點的讀寫模式是符合單主模式的。

接下來我們在任意節點執行切換語句，此處我們在節點 1 上執行。

select group_replication_switch_to_multi_primary_mode();

可以看到節點 1 因為一開始就是主節點，所以讀寫模式沒有發生變化，但是節點 2 和節點 3已經自動關閉了只讀模式，所有節點都變成可寫。

多主切單主

MRG多主切單主有兩條命令可以使用。

不指定主節點進行切換。

select group_replication_switch_to_single_primary_mode();

MGR中多主切單主，如果不指定主，切換時遵循以下的規則，前提無延遲情況下，按照優先順序先後順序：

1.先檢查叢集內是否存在低版本的MySQL，如果所有成員都是 8.0.17版本以上的，則按照補丁先後順序排列，如果有成員是 8.0.17 版本以下或者 5.7版本的，按發行版本的主要版本來排序，忽略補丁編號。

2.如果叢集有任意一個低版本的MySQL，且支援 group_replication_member_weight這個引數，則根據 group_replication_member_weight 這個權重引數來，group_replication_member_weight。

預設都是 50，權重越高優先順序越高。

3.如果叢集內有不支援 group_replication_member_weight 引數的MySQL，比如MySQL5.7，並且其中一個以上的成員具有最高的成員權重（或忽略了成員權重），則考慮的第三個因素是生成的伺服器 UUID 的詞典順序，由 server_uuid 系統變數指定。

伺服器 UUID最低的成員被選為主伺服器，這裡實際上就是查詢 performance_schema.replication_group_members最靠前的且是活著的MEMBER_ID。

在節點 1 上執行非指定單主的切換 SQL：

可以看到選取了 server_uuid靠前的節點1成為主節點。

接下來我們觀察各個節點的讀寫情況：

1節點：

2節點：

3節點：

可以看到此時節點 1 作為主節點已經關閉了read only，其他節點都已經打開了只讀。

03指定單主切換

因為隨機切有很大的不確定性，這裡還提供了指定主節點的切換命令：

select group_replication_set_as_primary("member_id");

這裡的 member_id 就是server_uuid，我們在節點 1 執行切換命令，選擇2節點的member_id。

切換後，可以看到節點1打開了只讀變成了從節點

節點2，關閉了只讀，成為主節點：

節點3，不變：

文章引用自資料和雲公眾號