MGR優(yōu)雅升級到MySQL8.0.16

傳統(tǒng)的升級手段之一，5.7 MGR集群與8.0 MGR集群進(jìn)行數(shù)據(jù)傳輸，程序切換新集群后測試是否正常，如果不正常，要么將新集群的新增數(shù)據(jù)同步回舊集群，要么就舍棄掉這部分?jǐn)?shù)據(jù)，一般看來這種回滾都是繁瑣的，繁瑣的操作一般都會相應(yīng)的增加風(fēng)險。

8.0.16的發(fā)布也帶來一個新的功能-MGR通信協(xié)議的支持，可以讓我們更輕松地切換到8.0，或者輕松地再切換回5.7。那么什么是MGR通信協(xié)議呢？

MGR通信協(xié)議(The Communication Protocol In Group Replication)

從MySQL 8.0.16中，MGR有一個通信協(xié)議的概念。可以直接管理MGR通信協(xié)議版本，并將其設(shè)置為適應(yīng)你希望MGR成員支持的哪個MySQL服務(wù)器版本。

從而實現(xiàn)同一個MGR可用組中可以由不同MySQL服務(wù)器版本的成員組成。

是的你沒有看錯，也就是說：

成員1：8.0.16

​成員2：8.0.16

​成員3：5.7.22

​他們可以組成一個MGR集群了。

同時確保向后兼容性。MySQL 5.7.14的版本允許壓縮消息，而MySQL 8.0.16的版本也允許消息碎片化。

同一個組中的所有成員必須使用相同的通信協(xié)議版本，以便MGR成員雖然各自處于不同的MySQL版本，但他們之間只能發(fā)送所有MGR成員都能理解的消息。

如果組的通信協(xié)議版本小于或等于X，則版本X的MySQL服務(wù)器只能在復(fù)制組中加入并達(dá)到ONLINE狀態(tài)。當(dāng)新成員加入復(fù)制組時，它會檢查通告的通信協(xié)議版本。

該小組的現(xiàn)有成員。 如果加入成員支持該版本，則它加入該組并使用該組已宣布的通信協(xié)議，即使該成員支持其他通信功能。 如果加入成員不支持通信協(xié)議版本，則將其從組中驅(qū)逐出去。

如果兩個成員嘗試加入相同的MGR集群，則只有兩個成員的通信協(xié)議版本已與該MGR已有成員的通信協(xié)議版本兼容時，它們才能加入。 來自該組的具有不同通信協(xié)議版本的成員必須單獨加入。

例如：

1個MySQL Server 8.0.16實例可以成功加入使用通信協(xié)議版本為5.7.22的組。
1個MySQL Server 5.7.22實例無法加入使用通信協(xié)議版本為8.0.16的組。
2個MySQL Server 8.0.16實例無法同時加入使用通信協(xié)議版本為5.7.22的組。
2個MySQL Server 8.0.16實例可以同時加入使用通信協(xié)議版本8.0.16的組

兩個核心UDF (User Defined Function)

1. group_replication_get_communication_protocol

用于獲取該MGR成員中最早的MySQL版本的通信協(xié)議

SELECT group_replication_get_communication_protocol(); 

2. group_replication_set_communication_protocol

需要更改MGR的通信協(xié)議版本以便早期版本的成員可以加入，需要具有GROUP_REPLICATION_ADMIN 權(quán)限哦

SELECT group_replication_set_communication_protocol("5.7.22"); 

如果后續(xù)將MGR的成員都升級成同一版本（原集群中***的版本），通信協(xié)議是不會自動升級兼容的，需要繼續(xù)執(zhí)行g(shù)roup_replication_set_communication_protocol函數(shù)來指定：

SELECT group_replication_set_communication_pruseotocol("8.0.16"); 

DEMO

環(huán)境：

集群的節(jié)點： 
192.168.4.35:3309 - Primary Node - MySQL 5.7.25  
192.168.4.34:3309 - Seconds Node - MySQL 5.7.25 
192.168.4.36:3309 - Seconds Node - MySQL 5.7.25 
希望加入集群的節(jié)點： 
192.168.4.35:3816 - MySQL 8.0.16 

開始測試

Primary Node (192.168.4.35 3309)：

show master status; 
+-----------------------------+----------+--------------+------------------+-------------------------------------------------------------------+ 
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | 
+-----------------------------+----------+--------------+------------------+-------------------------------------------------------------------+ 
| 0040353309-mysql-bin.000037 | 4090993 | | | 2c7b4762-5963-5789-acdd-047677b98a9d:1-32876403:33576383-33576398 | 
+-----------------------------+----------+--------------+------------------+-------------------------------------------------------------------+ 

新節(jié)點（192.168.4.35 3816）MySQL 8.0.16

change master + install plugin 請自行完成 ​ 
-- 如果通過還原已同步了GTID，忽略此步驟，這里為了簡單測試，顧新節(jié)點沒有同步原集群數(shù)據(jù)。 ​ 
reset master; ​ 
set global gtid_purge = '2c7b4762-5963-5789-acdd-047677b98a9d:1-32876403:33576383-33576398'   
-- 設(shè)置MGR相關(guān)參數(shù) 
set global binlog_checksum = NONE; ​ 
set global group_replication_group_name = '2c7b4762-5963-5789-acdd-047677b98a9d'; ​ 
set global group_replication_local_address = '192.168.4.35:23816'; ​ 
set global group_replication_group_seeds = "192.168.4.35:23309"; ​ 
set global group_replication_bootstrap_group = off; ​ 
set global group_replication_single_primary_mode = 0; ​ 
set global group_replication_enforce_update_everywhere_checks = 0; ​ 
set global group_replication_unreachable_majority_timeout = 120; ​ 
set global group_replication_enforce_update_everywhere_checks = 1; 
-- 啟動集群 ​ 
start group_replication ​ 
-- 嘗試執(zhí)行UDF：group_replication_get_communication_protocol： ​ 
SELECT group_replication_get_communication_protocol(); 
+------------------------------------------------+ 
| group_replication_get_communication_protocol() | 
+------------------------------------------------+ 
| 5.7.14 | 
+------------------------------------------------+ ​ 
-- MySQL 8.0.16 加入由全部節(jié)點均為5.7.25版本，自動將通訊協(xié)議降成了5.7.14，以便相互通訊兼容。 ​ 
-- 同時也說明 MySQL的通信協(xié)議版本可能和MySQL實例版本有可能不是一致的哦（這點還需要論證下，不敢打包票） ​ 
-- 注意：如果出現(xiàn)以下錯誤，原因是執(zhí)行UDF，必須要在集群成員均為Online對的狀態(tài)下才可執(zhí)行 
-- ERROR 1123 (HY000): Can't initialize function 'group_replication_get_communication_protocol'; A member is joining the group, wait for it to be ONLINE.' 
-- 查看集群節(jié)點狀態(tài)： 
[performance_schema]> select * from replication_group_members; 
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+ 
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | 
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+ 
| group_replication_applier | 6990a8f4-777c-11e9-a906-20040fecc760 | node004035 | 3816 | ONLINE | SECONDARY | 8.0.16 | 
| group_replication_applier | cc11c7de-446a-11e9-ae80-20040fecc760 | node004035 | 3309 | ONLINE | SECONDARY | 5.7.25 | 
| group_replication_applier | cc830e26-446a-11e9-be34-20040fed73f8 | node004036 | 3309 | ONLINE | SECONDARY | 5.7.25 | 
| group_replication_applier | cc88974a-446a-11e9-9e99-20040fed8fd8 | node004034 | 3309 | ONLINE | PRIMARY | 5.7.25 | 
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+ 

搭建完成，均手工測試，數(shù)據(jù)可正常同步及讀取。測試數(shù)據(jù)就不在這里介紹，可自行玩耍。

總的來說，這個特性對于已5.7 MGR為主的公司，但又想體驗8.0的一些特性是個非常好的利器。架構(gòu)支持了不同的MySQL版本，玩法就可以多種多樣了。