MGR是MySQL Group Replication的縮寫，即MySQL組複製。以往，技術DBA一般是利用MySQL的主從複製或半同步複製來提供高可用解決方案，但存在複製延遲、資料一致性、新節點選擇、事務無法及時確認等缺陷，因此，MySQL推出了全新的高可用解決方案 -- 組複製（MGR）。

**深入淺出MGR專欄**

為幫助技術小夥伴詳細瞭解MGR的功能特性及實操方法，近期，萬里資料庫旗下的開源技術社群——GreatSQL社群推出了深入淺出MGR的系列乾貨教程，目前已連載至第10期，後期將持續更新，歡迎技術小夥伴們多多學習、關注、提升MGR實操技能。

接下來，我們著重看看最新的第10期乾貨內容——選主演算法、多版本相容性及滾動升級。

**目錄**
- 選主演算法
- 多版本相容性
- MGR 5.7滾動升級至8.0
- 小結
- 參考資料、文件
- 免責宣告

本文介紹MGR的選主演算法，以及當MGR叢集中有多個不同版本混搭時，如何才能正常執行，有什麼注意事項。

**選主演算法**

MGR執行在單主模式時，當發生主節點切換，就需要進行選主工作。多主模式下，所有節點都是主節點，就不需要選主了。

MGR的選主工作是自動的，每個節點都會參與。選主時會檢查當前最新的組檢視，對潛在的新主節點（各個備選節點）進行排序，最後選出最合適的那個作為新的主節點。

不同的MySQL版本選主演算法略有不同，各節點選主時會根據當前的MySQL版本選主演算法而決定，因此當MGR叢集中有多個版本並存時，則此時MGR會做出調整，以便各個不同版本的節點都能就選主達成演算法一致。

通常而言，選主演算法的各個因素優先順序順序如下：

根據MySQL版本號排序，低版本的優先順序更高（因為要向下相容）。如果是MySQL 8.0.17及以上版本，則優先根據補丁版本號排序（例如17、18、20）。如果是8.0.16及以下版本，則優先根據主版本號排序（例如5.7、8.0）。

版本號相同的各節點則根據各節點的權重值排序，權重越高優先順序也越高。節點的權重值可通過設定 group_replication_member_weight選項來調整。這個選項是MySQL 8.0版本引入的，如果是5.7版本則不支援。

當版本號和節點權重值都一樣時，再根據 server_uuid（或者說是 MEMBER_ID）排序（注意，不是 server_id），排在前面的優先順序越高。MySQL Server在啟動時，會生成一個隨機的UUID值，其值記錄在檔案 datadir/auto.cnf 檔案中，實際上可以在例項啟動前，通過修改這個UUID值來改變 server_uuid 的值，只要符合UUID資料格式即可。因此，相當於是可以認為調整 server_uuid 以調整選主時節點的排序優先順序。

從上面可知，當有MySQL 8.0和5.7的節點混搭執行MGR叢集時，執行5.7版本的節點會優先被選中，其次再根據 group_replication_member_weight 選擇權重搞的節點，最後再根據 server_uuid 排序。

因此，執行MGR叢集時最好各節點版本號相同，選主規則就簡單多了。

在MySQL 8.0中，通過查詢 performance_schema.replication_group_members 表的MEMBER_ROLE 即可知道哪個是主節點：

可以看到，即便是執行MySQL 8.0版本的節點的 server_uuid 排序在前面，但在自動選主時，也不會被選中作為主節點。此外，執行MySQL 5.7版本的節點是無法加入主節點執行MySQL 8.0的MGR叢集的，會報告類似下面的錯誤：

[ERROR] Plugin group_replication reported: 'Member version is incompatible with the group'

提示版本不相容。

**多版本相容性**

正常地，為了MGR的相容性及效能，所有節點的MySQL版本最好保持一致。尤其是在多主模式下，各節點都提供寫入服務，如果相容性方面存在問題，則可能會導致MGR叢集異常或寫入異常。為了避免這種情況發生，新加入節點時，會和其他節點進行版本相容性檢查。

目前MGR支援3個通訊協議版本號：5.7.14、8.0.16、8.0.27，這幾個版本的主要變化有：

從5.7.14開始，支援訊息壓縮。

從8.0.16開始，支援訊息分片。

從8.0.27開始，支援在單主模式下，設定唯一的leader節點。

MGR叢集中，各節點間的通訊協議版本號必須一致，這樣才能保證即使是MySQL版本號不一致，但MGR通訊依然不受影響。新加入節點的通訊協議版本號必須高於當前叢集中使用的通訊協議版本。節點加入時會檢查協議版本，並向其廣播當前叢集中使用的協議版本，如果可以相容，則允許加入，否則會將其踢出。

當兩個節點同時加入時，只有當兩個節點的通訊協議版本和叢集相容時，才能同時加入成功。和當前叢集不同協議版本的節點需要單獨加入才行，例如：

一個使用8.0.16版本的例項可以成功加入使用通訊協議版本5.7.24的叢集。

一個5.7.24例項無法加入使用8.0.16的叢集。

兩個8.0.16例項無法同時加入使用5.7.24的叢集。

兩個8.0.16例項可以同時加入使用8.0.16的叢集。

如果有需要，還可以線上修改通訊協議版本號，使用

group_replication_set_communication_protocol() 這個UDF即可（MySQL 8.0以上支援），例如：

```cpp
mysql> select version();
+-----------+
| version() |
+-----------+
| 8.0.25-15 |   select group_replication_get_communication_protocol();
+------------------------------------------------+
| group_replication_get_communication_protocol() |
+------------------------------------------------+
| 8.0.16                                         |   select group_replication_set_communication_protocol('5.7.14');
+-----------------------------------------------------------------------------------+
| group_replication_set_communication_protocol('5.7.14')                            |   select group_replication_set_communication_protocol('8.0.25');
+-----------------------------------------------------------------------------------+
| group_replication_set_communication_protocol('8.0.25')                            |
+-----------------------------------------------------------------------------------+
| The operation group_replication_set_communication_protocol completed successfully |   select group_replication_get_communication_protocol();
+------------------------------------------------+
| group_replication_get_communication_protocol() |
+------------------------------------------------+
| 8.0.16                                         |   select group_replication_set_communication_protocol('8.0.27');
ERROR 1123 (HY000): Can't initialize function 'group_replication_set_communication_protocol'; 8.0.27 is not between 5.7.14 and 8.0.25
```

其實說這麼多版本相容性的話題，還不如一個簡單的原則：讓所有節點的版本號都一致。這樣構建MGR叢集更簡單，節點間通訊也不會被複雜化。

**MGR 5.7滾動升級至8.0**

MGR 5.7叢集滾動升級至8.0可以參考這篇文章：MySQL MGR從5.7滾動升級至8.0，簡言之，可以分為以下幾步：

在現有MGR 5.7叢集中，新增MySQL 8.0的Secondary節點。

一比一下線一個MySQL 5.7的Secondary節點。

如此往復，直到剩下最後一個MySQL 5.7的Primary節點。

再次上線一個MySQL 8.0的Secondary節點。

停止最後一個MySQL 5.7的Primary節點，這是會切換主節點，並且選擇其中一個MySQL 8.0節點作為新的Primary節點，這就完成升級了。

在這裡實操演示大概的過程。

在MGR 5.7的叢集中，增加一個MySQL 8.0的Secondary節點：

```
現在，利用MySQL Shell刪除一箇舊節點：

```cpp
c.removeInstance('127.0.0.1:4308');
The instance will be removed from the InnoDB cluster. Depending on the instance
being the Seed or not, the Metadata session might become invalid. If so, please
start a new session to the Metadata Storage R/W instance.

Instance '127.0.0.1:4308' is attempting to leave the cluster...
WARNING: On instance '127.0.0.1:4308' configuration cannot be persisted since MySQL version 5.7.36 does not support the SET PERSIST command (MySQL version >= 8.0.11 required). Please set the 'group_replication_start_on_boot' variable to 'OFF' in the server configuration file, otherwise it might rejoin the cluster upon restart.
WARNING: Instance '127.0.0.1:4306' cannot persist configuration since MySQL version 5.7.36 does not support the SET PERSIST command (MySQL version >= 8.0.11 required). Please use the dba.configureLocalInstance() command locally to persist the changes.

The instance '127.0.0.1:4308' was successfully removed from the cluster.

```
之後再檢視節點狀態：

如此往復，直到只剩最後一個5.7節點：

關閉最後一個5.7節點，會自動切換主節點：

```cpp
MySQL  127.0.0.1:4306 ssl  JS > c.removeInstance('127.0.0.1:4306');
The instance will be removed from the InnoDB cluster. Depending on the instance
being the Seed or not, the Metadata session might become invalid. If so, please
start a new session to the Metadata Storage R/W instance.

Instance '127.0.0.1:4306' is attempting to leave the cluster...
WARNING: On instance '127.0.0.1:4306' configuration cannot be persisted since MySQL version 5.7.36 does not support the SET PERSIST command (MySQL version >= 8.0.11 required). Please set the 'group_replication_start_on_boot' variable to 'OFF' in the server configuration file, otherwise it might rejoin the cluster upon restart.

The instance '127.0.0.1:4306' was successfully removed from the cluster.
```

之後可以看到5.7節點全部下線了，只剩下8.0節點：

檢視切換過程：

```cpp
2022-01-20T22:19:10.753644+08:00 0 [Warning] [MY-011499] [Repl] Plugin group_replication reported: 'Members removed from the group: 127.0.0.1:4306'
2022-01-20T22:19:10.753648+08:00 0 [System] [MY-011500] [Repl] Plugin group_replication reported: 'Primary server with address 127.0.0.1:4306 left the group. Electing new Primary.'
2022-01-20T22:19:10.753705+08:00 0 [Note] [MY-011071] [Repl] Plugin group_replication reported: 'handle_leader_election_if_neede
d is activated,suggested_primary:'
2022-01-20T22:19:10.754747+08:00 0 [Note] [MY-013519] [Repl] Plugin group_replication reported: 'Elected primary member gtid_exe
cuted: 082b900b-79d5-11ec-8fe2-00155d064000:1-32, 36ab409a-79d6-11ec-9cd5-00155d064000:1-37'
2022-01-20T22:19:10.754790+08:00 0 [Note] [MY-013519] [Repl] Plugin group_replication reported: 'Elected primary member applier
channel received_transaction_set: 082b900b-79d5-11ec-8fe2-00155d064000:1-32, 36ab409a-79d6-11ec-9cd5-00155d064000:1-37'
2022-01-20T22:19:11.754969+08:00 0 [System] [MY-011507] [Repl] Plugin group_replication reported: 'A new primary with address ye
jr.run:3309 was elected. The new primary will execute all previous group transactions before allowing writes.'
2022-01-20T22:19:11.755803+08:00 92 [System] [MY-011566] [Repl] Plugin group_replication reported: 'Setting super_read_only=OFF.
'
2022-01-20T22:19:12.752517+08:00 0 [Note] [MY-011735] [Repl] Plugin group_replication reported: '[GCS] Failure reading from fd=5
3 n=0'
2022-01-20T22:19:12.755961+08:00 0 [System] [MY-011503] [Repl] Plugin group_replication reported: 'Group membership changed to y
ejr.run:3309, 127.0.0.1:3310, 127.0.0.1:3311 on view 16426721489193731:9.'
2022-01-20T22:19:12.756296+08:00 91 [System] [MY-011566] [Repl] Plugin group_replication reported: 'Setting super_read_only=OFF.
'
2022-01-20T22:19:12.756744+08:00 91 [System] [MY-011510] [Repl] Plugin group_replication reported: 'This server is working as pr
imary member.'
2022-01-20T22:19:12.756787+08:00 30 [Note] [MY-011485] [Repl] Plugin group_replication reported: 'Primary had applied all relay
logs, disabled conflict detection.'

```
這就完成滾動升級了。

**小結**

本文介紹了MGR叢集中是如何進行選主的，當有5.7、8.0版本混合時的相容性，以及如何把MGR 5.7滾動升級到8.0。最後多說一句，哪怕是不用MGR，8.0相對5.7還是有很多企業級特性，5.6、5.7也只能是過渡版本，最終還是強烈建議升級到8.0版本。

**參考資料、文件**

[MySQL 8.0 Reference Manual](https://dev.mysql.com/doc/refman/8.0/en/group-replication.html)

[資料庫核心開發 - 溫正湖](https://www.zhihu.com/column/c_206071340)

[Group Replication原理 - 宋利兵](https://mp.weixin.qq.com/s/LFJtdpISVi45qv9Wksv19Q)

**免責宣告**

因個人水平有限，專欄中難免存在錯漏之處，請勿直接複製文件中的命令、方法直接應用於線上生產環境。請讀者們務必先充分理解並在測試環境驗證通過後方可正式實施，避免造成生產環境的破壞或損害。

技術乾貨｜深入淺出MGR—詳解選主演算法、多版本相容性及滾動升級

相關文章