MySQL8.0.16新特性:The Communication Protocol In Group Replication

Paddy_Duck發表於2019-05-18

MGR優雅升級到MySQL8.0.16

  傳統的升級手段之一,5.7 MGR叢集與8.0 MGR叢集進行資料傳輸,程式切換新叢集后測試是否正常,如果不正常,要麼將新叢集的新增資料同步回舊叢集,要麼就捨棄掉這部分資料,一般看來這種回滾都是繁瑣的,繁瑣的操作一般都會相應的增加風險。

 

  8.0.16的釋出也帶來一個新的功能-MGR通訊協議的支援,可以讓我們更輕鬆地切換到8.0,或者輕鬆地再切換回5.7。那麼什麼是MGR通訊協議呢? 

MGR通訊協議(The Communication Protocol In Group Replication)

  從MySQL 8.0.16中,MGR有一個通訊協議的概念。可以直接管理MGR通訊協議版本,並將其設定為適應你希望MGR成員支援的哪個MySQL伺服器版本。
 
  從而實現同一個MGR可用組中可以由不同MySQL伺服器版本的成員組成。
 
  是的你沒有看錯,也就是說:
 
成員1:8.0.16
​成員2:8.0.16
​成員3:5.7.22
​他們可以組成一個MGR叢集了。

  同時確保向後相容性。MySQL 5.7.14的版本允許壓縮訊息,而MySQL 8.0.16的版本也允許訊息碎片化。
 
  同一個組中的所有成員必須使用相同的通訊協議版本,以便MGR成員雖然各自處於不同的MySQL版本,但他們之間只能傳送所有MGR成員都能理解的訊息。
 
  如果組的通訊協議版本小於或等於X,則版本X的MySQL伺服器只能在複製組中加入並達到ONLINE狀態。當新成員加入複製組時,它會檢查通告的通訊協議版本。
 
  該小組的現有成員。 如果加入成員支援該版本,則它加入該組並使用該組已宣佈的通訊協議,即使該成員支援其他通訊功能。 如果加入成員不支援通訊協議版本,則將其從組中驅逐出去。

 

  如果兩個成員嘗試加入相同的MGR叢集,則只有兩個成員的通訊協議版本已與該MGR已有成員的通訊協議版本相容時,它們才能加入。 來自該組的具有不同通訊協議版本的成員必須單獨加入。 

     例如:

1個MySQL Server 8.0.16例項可以成功加入使用通訊協議版本為5.7.22的組。
1個MySQL Server 5.7.22例項無法加入使用通訊協議版本為8.0.16的組。
2個MySQL Server 8.0.16例項無法同時加入使用通訊協議版本為5.7.22的組。
2個MySQL Server 8.0.16例項可以同時加入使用通訊協議版本8.0.16的組

 

兩個核心UDF (User Defined Function)

1.    group_replication_get_communication_protocol

  用於獲取該MGR成員中最早的MySQL版本的通訊協議
 
SELECT group_replication_get_communication_protocol();

 

 2.    group_replication_set_communication_protocol

 
  需要更改MGR的通訊協議版本以便早期版本的成員可以加入,需要具有GROUP_REPLICATION_ADMIN 許可權哦

SELECT group_replication_set_communication_protocol("5.7.22");

  

  如果後續將MGR的成員都升級成同一版本(原叢集中最新的版本),通訊協議是不會自動升級相容的,需要繼續執行group_replication_set_communication_protocol函式來指定:


SELECT group_replication_set_communication_pruseotocol("8.0.16");

  

DEMO

 

環境:


叢集的節點:
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
希望加入叢集的節點:
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 |
+-----------------------------+----------+--------------+------------------+-------------------------------------------------------------------+

 

  新節點(192.168.4.35 3816)MySQL 8.0.16

change master + install plugin 請自行完成
​
-- 如果通過還原已同步了GTID,忽略此步驟,這裡為了簡單測試,顧新節點沒有同步原叢集資料。
​
reset master;
​
set global gtid_purge = '2c7b4762-5963-5789-acdd-047677b98a9d:1-32876403:33576383-33576398'
 
-- 設定MGR相關引數
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 ​ -- 嘗試執行UDF:group_replication_get_communication_protocol: SELECT group_replication_get_communication_protocol(); +------------------------------------------------+ | group_replication_get_communication_protocol() | +------------------------------------------------+ | 5.7.14 | +------------------------------------------------+ ​ -- MySQL 8.0.16 加入由全部節點均為5.7.25版本,自動將通訊協議降成了5.7.14,以便相互通訊相容。 ​ -- 同時也說明 MySQL的通訊協議版本可能和MySQL例項版本有可能不是一致的哦(這點還需要論證下,不敢打包票) ​ -- 注意:如果出現以下錯誤,原因是執行UDF,必須要在叢集成員均為Online對的狀態下才可執行
-- ERROR
1123 (HY000): Can't initialize function 'group_replication_get_communication_protocol'; A member is joining the group, wait for it to be ONLINE.'
-- 檢視叢集節點狀態: [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 | +---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

 搭建完成,均手工測試,資料可正常同步及讀取。測試資料就不在這裡介紹,可自行玩耍。

 

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

 

參考文件:

 

https://dev.mysql.com/doc/refman/8.0/en/group-replication-communication-protocol.html



相關文章