經過近期的努力，支援仲裁（投票）節點特性的 GreatSQL 8.0.25-16今天正式釋出啦，可以用接近兩臺伺服器的成本構建MGR（節省伺服器資源），此外還支援快速單主模式以及改進選主策略等特性，該版本里也修復了眾多MGR關鍵bug。用MGR，選GreatSQL，更放心~

## GreatSQL 8.0.25-16 新版本亮點

1.新增特性
1.1 新增仲裁節點（投票節點）角色
1.2 新增快速單主模式
1.3 新增MGR網路開銷閾值
1.4 自定義選主模式
2.穩定性提升
3.其他調整
4.bug修復
5.GreatSQL VS MySQL社群版
6.GreatSQL Release Notes

## 1 新增特性

### 1.1 新增仲裁節點（投票節點）角色

該節點僅參與MGR投票仲裁，不存放實際資料，也無需執行DML操作，因此可以用一般配置級別的伺服器，在保證MGR可靠性的同時還能降低伺服器成本。

**新增引數**

group-----_replication_arbitrator用於設定仲裁節點。

若想新增一個仲裁節點，只需在 my.cnf 配置檔案中新增如下配置：

group_replication_arbitrator = true

當叢集中只剩下 Arbitrator 節點時，則會自動退出。

可以看到，MEMBER_ROLE 這列顯示為 ARBITRATOR，表示該節點是一個仲裁節點。

再看壓測期間各節點負載資料，先看 Primary 節點：

```c
$ top
...
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
20198 mysql     20   0   11.9g   3.4g  23440 S 207.6 21.6  21:33.48 mysqld

$ vmstat -S m 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  3      0   5637    152   6385    0    0     0 56311 53024 53892 36 17 43  3  0
 0  3      0   5633    152   6389    0    0     0 46053 51900 52435 35 17 44  4  0
 6  0      0   5628    152   6393    0    0     0 47024 52026 52388 36 17 44  3  0
 7  1      0   5623    152   6397    0    0     0 51673 52165 53113 36 17 43  3  0
 3  1      0   5621    152   6401    0    0     0 44231 52164 52875 35 17 45  3  0
 3  4      0   5616    152   6404    0    0     0 49278 52854 53139 37 17 43  3  0
 4  0      0   5613    152   6408    0    0     0 49738 52848 53361 37 17 43  3  0
```

在其中一個 Secondary 節點上：

```c
$ top
...
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
26824 mysql     20   0   11.6g   3.0g  22880 S 175.7 19.4  19:27.34 mysqld

$ vmstat -S m 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0      0   2089    128  10757    0    0     0 53671 31463 46803 30 11 55  4  0
 3  0      0   2082    128  10765    0    0     0 52737 31475 45862 30 11 55  4  0
 2  0      0   2073    128  10772    0    0     0 52121 31035 45820 29 12 55  4  0
 3  0      0   2065    128  10781    0    0     0 51469 31081 44831 30 12 55  4  0
 1  0      0   2057    128  10788    0    0     0 53071 31442 45664 30 11 55  4  0
 3  0      0   2049    128  10795    0    0     0 51357 29848 43391 30 12 54  4  0
 0  0      0   2041    128  10803    0    0     0 52404 30545 45020 29 12 56  4  0
 3  0      0   2034    128  10811    0    0     0 51355 31483 45582 32 12 53  3  0
```

在 Arbitrator 節點上：

```c
$ top
...
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
16997 mysql     20   0   11.2g   2.5g  22184 S  29.6 16.4   3:47.84 mysqld

$ vmstat -S m 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0   6145    141   7095    0    0     0    44 17767 16010  4  4 93  0  0
 1  0      0   6146    141   7095    0    0     0     0 17020 16189  4  4 93  0  0
 0  0      0   6144    141   7095    0    0     0     0 16958 15365  3  4 93  0  0
 0  0      0   6145    141   7095    0    0     0     0 15942 14969  3  3 93  0  0
 1  0      0   6146    141   7095    0    0     0     0 17698 16320  4  4 92  0  0
```

可以看到負載明顯小了很多，這就可以在一個伺服器上跑多個仲裁節點角色。

注意： 在有仲裁節點的情況下，將單主切換成多主模式時，需要把投票節點先關閉再進行切換，否則可能會導致切換失敗，並且仲裁節點報錯退出MGR。

###   1.2 新增快速單主模式

GreatSQL中增加一個新的工作模式：單主快速模式，在這個模式下，不再採用MySQL MGR原有的認證資料庫方式。新增選項

group_replication_single_primary_fast_mode 用於設定是否啟用，以及具體採用哪種模式。

快速單主模式特別適合在跨機房部署，壓力測試以及記憶體要求不高等多種場景。這種模式弱於傳統的非同步複製，但強於半同步複製，且沒有MGR預設的認證資料庫可能消耗較大記憶體的問題。

提醒，啟用快速單主模式時，不支援採用多主模式；所有節點都得設定必須相同，否則無法啟動。

選項

group_replication_single_primary_fast_mode 可選值有：0、1、2，不同值分別表示如下：

0，表示不採取快速單主模式，這是預設值。

1，表示採用快速單主模式，支援並行回放。**強烈建議設定為1，即啟用快速單主模式。

2，表示採用快速單主模式，但不支援並行回放，加速relay log落盤，且讓從庫消耗更少的資源。
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/aaba71d78f58455d838ed577a76ce1dc.png)

### 1.3 新增MGR網路開銷閾值

新增相應選項

group_replication_request_time_threshold。

在MGR結構中，一個事務的開銷包含網路層以及本地資源（例如CPU、磁碟I/O等）開銷。當事務響應較慢想要分析效能瓶頸時，可以先確定是網路層的開銷還是本地效能瓶頸導致的。通過設定選項

group_replication_request_time_threshold 即可記錄超過閾值的事件，便於進一步分析。輸出的內容記錄在error log中，例如：

```c
2022-03-04T09:45:34.602093+08:00 128 [Note] Plugin group_replication reported: 'MGR request time:30808us, server id:3306879, thread_id:17368'
```

表示當時這個事務在MGR層的網路開銷耗時30808微秒（30.808毫秒），再去檢視那個時段的網路監控，分析網路延遲較大的原因。

選項

group_replication_request_time_threshold 單位是毫秒，預設值是0，最小值0，最大值100000。如果MGR跑在區域網環境，則建議設定為50 ~ 100毫秒區間，如果是執行在跨公網環境，則建議設定為1 ~ 10秒左右。另外，當該值設定為1 ~ 9之間時，會自動調整為10（毫秒）且不會提示warning，如果設定為0則表示禁用。
![圖片](https://img-blog.csdnimg.cn/e2eecad57dff47bab2d6b36d45727934.png)

### 1.4 自定義選主模式

完善自動選主機制，增加基於最新GTID判斷來選主，避免自動選擇沒有最新GTID的節點作為新主。

預設地，MGR根據以下規則選主：

當有MySQL 5.7和MySQL 8.0不同版本的節點混合部署時，只會選擇執行5.7的節點作為主節點。此外，在 <= MySQL 8.0.16 版本時，以主版本號進行排序，也就是說 5.7 排在 8.0 前面。在 > MySQL 8.0.17版本中，則是以補丁版本號排序，也就是 8.0.17 排在 8.0.25 前面。

當所有節點版本號一致時，則根據節點權重值（選項

group_replication_member_weight 定義權重值，這個選項5.7版本沒有，8.0開始新增）排序，權重值高的節點排在前面。

根據節點 server_uuid 排序。

在一些情況下，在MGR所有節點都發生意外要重新拉起時，不會檢查各節點事務應用狀態，而錯誤選擇新的主節點，這時可能會導致丟失一些事務資料。或者當原來的主節點crash需要重新投票選擇新的主節點時，可能也會選擇一個權重值較高，但沒有最新事務的節點，也會存在丟失一部分事務資料的風險。

在GreatSQL中，新增選項

group_replication_primary_election_mode 用於自定義選主策略，可選值有以下幾個：

WEIGHT_ONLY，還是按照上述傳統模式自動選主，這是預設值。

GTID_FIRST，優先判斷各節點事務應用狀態，自動選擇擁有最新事務的節點作為新的主節點。推薦設定為該模式

WEIGHT_FIRST，傳統模式優先，如果沒有合適的結果再判斷各節點事務狀態。

提醒，所有節點都的設定必須相同，否則無法啟動。
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/9fb2adc99b7e4c8494fb92f7a25a3405.png)

## 2 穩定性提升

優化了加入節點時可能導致效能劇烈抖動的問題。

優化手工選主機制，解決了長事務造成無法選主的問題。

完善MGR中的外來鍵約束機制，降低或避免從節點報錯退出MGR的風險。

## 3 其他調整

**選項**

group_replication_flow_control_replay_lag_behind 預設值由60秒調整為600秒，以適應更多業務場景。該選項用於控制MGR主從節點複製延遲閾值，當MGR主從節點因為大事務等原因延遲超過閾值時，就會觸發流控機制。

**新增選項**

group_replication_communication_flp_timeout（單位：秒）。當多數派節點超過該閾值為收到某節點傳送的訊息時，會將該節點判定為可疑節點。在網路條件較差的環境中，可以適當調大該閾值，以避免頻繁抖動。

## 4 bug修復

修復了InnoDB並行查詢crash的問題（issue#I4J1IH）。

修復了在啟用dns或hostname的情況下，bind意外失敗問題。

修復了協程排程不合理的問題，該問題可能會造成在大事務時系統錯誤判斷為網路錯誤。

修復了新加入節點在追paxos資料時，由於write超時導致連線提前關閉的問題。

修復了recovering節點被中途停止導致的資料異常問題。

修復了同時多個異常導致的檢視問題。

修復了在某些場景下同時新增節點失敗的問題。

修復了在特殊場景下組檢視異常的問題。

修復了rejoin過程中，member_stats相關查詢導致崩潰的問題。

修復了在before模式下，可能導致assert失敗的問題。

修復了stop group_replication時可能長時間等待的問題。

修復了將傳統主從環境下產生的binlog匯入MGR可能引起死迴圈的問題。

修復了因為大事務記憶體分配失敗導致的崩潰問題。

## 5 GreatSQL VS MySQL社群版
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/fbdd3ac56ca44216a2a3b2647984b291.png)

## 6 GreatSQL Release Notes

Changes in MySQL 8.0.25-15 (2022-8-26)

Changes in MySQL 5.7.36-39 (2022-4-7)

Enjoy GreatSQL :)

新版本 | GreatSQL 8.0.25-16正式釋出，這些新增特性不容錯過~

相關文章