957      阿裏雲  技術社區[雲棲]

如何優雅的添加MGR 節點

引言

MySQL Group Replication（簡稱MGR）是MySQL官方於2016年12月份推出的一個全新的高可用與高擴展的解決方案。MGR提供了高可用,高擴展、高可靠的MySQL集群服務。MGR是MySQL數據庫未來發展的一個重要方向。

場景描述

• ip地址規劃

一個已經運行很久的MGR集群，以single-master模式運行（單主模式），binlog過期策略為7天。

• 參數設置

• 需求描述 因為不可抗力的因素 mgr-node3.up.com 節點永久性的down 並且無法恢複，或者mgr-node3.up.com 宕機超過時間7day， 或需要快速添加節點。那麼改如何快速添加或擴容呢？

猜想

1.如果這個問題發送在Percona XtraDB Cluster（pxc）或者Mariadb Galera Cluster解決方案是通過SST(全量)或者IST（增量）來實現，那麼MGR是否SST或者IST的方案呢？

2.假設MGR也是通過SST或者IST來的解決方案入 MGR是否使用MySQLdump 或者rsync來獲得一份全量？

3.假設是通過MySQLdump來實現傳遞增量。是否可以用xtrabackup來替換呢？

根據上述的猜想和假設來求證，如何優雅的添加MGR節點。

驗證

猜想一 在MySQL官方文檔中沒有找到關於SST或IST的描述,既然官方文檔沒有寫那麼在實驗環境中是否能模擬出來。

-實驗
在mgr-node1.up.com主節點創建一張表

"root@localhost:mysql3306.sock  [aa]>show create table aa;
+-------+-------------------------------------------------------------------------------------------------------------------------------------------+
| Table | Create Table                                                                                                                              |
+-------+-------------------------------------------------------------------------------------------------------------------------------------------+
| aa    | CREATE TABLE `aa` (
  `id` int(11) NOT NULL,
  `name` varchar(10) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 |
+-------+-------------------------------------------------------------------------------------------------------------------------------------------+

"root@localhost:mysql3306.sock  [aa]>select * from aa;
+----+------+
| id | name |
+----+------+
|  1 | a    |
|  2 | a    |
|  3 | a    |
|  4 | a    |
|  5 | a    |
+----+------+
5 rows in set (0.00 sec)

加入新的節點mgr-node4.up.com並初始化，開啟現有環境所有節點的general_log觀察general的輸出

mgr-node1.up.com 節點

2017-11-16T15:38:52.818216Z    32 Connect   slave@mgr-node4.up.com on  using TCP/IP
2017-11-16T15:38:52.829195Z    32 Query SELECT UNIX_TIMESTAMP()
2017-11-16T15:38:52.829836Z    32 Query SELECT @@GLOBAL.SERVER_ID
2017-11-16T15:38:52.835000Z    32 Query SET @master_heartbeat_period= 30000001024
2017-11-16T15:38:52.842449Z    32 Query SET @master_binlog_checksum= @@global.binlog_checksum
2017-11-16T15:38:52.843032Z    32 Query SELECT @master_binlog_checksum
2017-11-16T15:38:52.843355Z    32 Query SELECT @@GLOBAL.GTID_MODE
2017-11-16T15:38:52.843529Z    32 Query SELECT @@GLOBAL.SERVER_UUID
2017-11-16T15:38:52.843726Z    32 Query SET @slave_uuid= '5d03ede3-cae1-11e7-9319-000c299354d5'
2017-11-16T15:38:52.844093Z    32 Binlog Dump GTID  Log: '' Pos: 4 GTIDs: ''
2017-11-16T15:39:52.972984Z    33 Connect   slave@mgr-node4.up.com on  using TCP/IP

從general_log中找到了蛛絲馬跡,目前版本的MGR，不支持SST或IST。實現的方式是根據GTID的方式來實現的。

同時在general_log中也發現，目前版本的MGR也不支持MySQLdump或者rsync方式來給新加入的節點傳遞全量。如果binlog被清空的話 則顯示為空 新的節點無法加入集群但

"root@localhost:mysql3306.sock [aa]>start group_replication;
提示成功

正確姿勢

1.首先需要手動在MGR集群中獲得一致性備份。

2.初始化新節點，並應用備份。
注意如下操作 否則無法正常添加到集群

"root@localhost:mysql3306.sock  [aa]>reset master;
Query OK, 0 rows affected (0.00 sec)

"root@localhost:mysql3306.sock  [aa]>SET @@GLOBAL.GTID_PURGED='3db33b36-0e51-409f-a61d-c99756e90155:1-14,
    '> ecf5373e-cad7-11e7-b854-000c293dbc8e:1'
    -> ;
Query OK, 0 rows affected (0.00 sec)

3.安裝官方文檔正常初始化集群

步驟略

4.驗證

"root@localhost:mysql3306.sock  [aa]>start group_replication;
Query OK, 0 rows affected (3.16 sec)

"root@localhost:mysql3306.sock  [aa]>select * from aa;
+----+------+
| id | name |
+----+------+
|  1 | a    |
|  2 | a    |
|  3 | a    |
|  4 | a    |
+----+------+

總結

1.如果需要添加一個節點

添加節點 需要自己手動在MGR集群中獲得一致性備份，MGR集群不存在SST和IST概念,而是完全通過GTID和binlog來實現“追數據”的一個操作

2.節點宕機

如果MGR集群中某個節點宕機,如果宕機節點會詢問存活集群，是否能補全binlog 如果能補齊，那麼就會正常傳輸，進行追數據 。如果宕機節點需要的日誌不存在了，則該節點無法正常加入集群環境中。

對於MGR一個建議

在宕機節點加入MGR集群中，如果發現需要的binlog日誌不存在，則無法啟動集群start group_replication

最後更新：2017-11-17 02:03:59

  上一篇：  阿裏雲EDAS E2 2.15.0 版本發布說明

  下一篇：  spring boot 搭建的一個企業級快速開發腳手架