MySQL Group Replication(MGR)是MySQL官方在5.7.17版本引進的一個數據庫高可用與高擴展的解決方案，以插件形式提供。MGR基于分布式paxos協議，實現組復制，保證數據一致性。內置故障檢測和自動選主功能，只要不是集群中的大多數節點都宕機，就可以繼續正常工作。提供單主模式與多主模式，多主模式支持多點寫入。MGR集群的搭建，參考文章MySQL MGR 集群搭建(單主模式&多主模式)。

相對于傳統的MySQL，MGR帶來的改進讓人激動人心，但是使用MGR也有一些前提條件與注意事項，下面基于 MySQL 8.0.11 版本進行簡單說明。

一、MGR使用限制

僅支持innodb存儲引擎

MGR集群中，只支持innodb存儲引擎，能夠創建非innodb引擎的表，但是無法寫入數據，向非innodb表寫數據直接報錯。

mysql> create table tb_myisam(id int, name varchar(50), primary key(id)) engine=myisam;

Query OK, 0 rows affected (0.05 sec)

mysql> insert into tb_myisam select 1, '1';

ERROR 3098 (HY000): The table does not comply with the requirements by an external plugin.

表必須有主鍵，或者非Null的唯一鍵

MGR集群中，只支持innodb引擎的表，并且該表必須有顯式的主鍵，或者非Null的唯一鍵，否則即使能夠創建表，也無法向表中寫入數據。

# 創建沒有主鍵的表，寫入數據失敗

mysql> create table tb_no_primary_key(name varchar(50));

Query OK, 0 rows affected (0.15 sec)

mysql> insert into tb_no_primary_key select '1';

ERROR 3098 (HY000): The table does not comply with the requirements by an external plugin.

# 創建Null唯一索引的表，寫入數據失敗

mysql> create table tb_null_unique_key(name varchar(50), unique key(name));

Query OK, 0 rows affected (0.09 sec)

mysql> insert into tb_null_unique_key select '1';

ERROR 3098 (HY000): The table does not comply with the requirements by an external plugin.

# 創建非Null唯一索引的表，寫入數據成功

mysql> create table tb_no_null_unique_key(name varchar(50) not null, unique key(name));

Query OK, 0 rows affected (0.04 sec)

mysql> insert into tb_no_null_unique_key select '1';

Query OK, 1 row affected (0.06 sec)

Records: 1 Duplicates: 0 Warnings: 0

網絡限制

MGR 組通信引擎目前僅支持IPv4網絡，并且對節點間的網絡性能要求較高，低延遲、高帶寬的網絡是部署MGR集群的基礎。

MGR忽略表鎖和命名鎖，在MGR中lock tables、unlock tables、get_lock、release_lock等這些表鎖和命名鎖將被忽略。

MGR多主模式中，默認不支持 SERIALIZABLE 隔離級別。

多主模式下，對同一個對象進行并發的有沖突的ddl和dml操作導致這種沖突在部分成員節點中無法檢測到，最終可能導致數據不一致。

多主模式下，不支持級聯約束的外鍵，可能造成有沖突的操作無法檢測。

不支持超大事務。

多主模式下可能導致死鎖，比如select ...for update在不同節點執行，由于多節點鎖無法共享，很容易導致死鎖。

不支持復制過濾，如果有節點設置了復制過濾，將影響節點間決議的達成。

MGR最多支持9個節點，大于9個節點，將拒絕新節點的加入。

二、節點配置要求

log_bin

log_slave_updates

binlog_format=ROW

gtid_mode=ON

master_info_repository=TABLE

relay_log_info_repository=TABLE

transaction_write_set_extraction=XXHASH64

并行復制

slave_parallel_type=LOGICAL_CLOCK

slave_preserve_commit_order=1

slave_parallel_workers=[N]

binlog_checksum=NONE

transaction_isolation=READ-COMMITTED #官方推薦在MGR中隔離級別設置為RC

三、MGR沖突檢測

MGR多主模式下，一個事務在執行時，并不會做前置的檢查，但是在提交階段，會和其他節點通信對該事務是否能夠提交達成一個決議。在多個節點同對相同記錄的修改，在提交時會進行沖突檢測，首先提交的事務將獲得優先權。例如對同一條記錄的修改，t1事務先于t2事務，那么t1事務在沖突檢測后獲得執行權，順利提交，而t2事務進行回滾。顯然這種多點寫入條件下，對于同一條記錄的并發修改，由于大量的回滾，導致性能很低，因此MySQL官方建議，這種對于同一條記錄的修改，應該放在同一個節點執行，這樣可以利用節點本地鎖來進行同步等待，減少事務回滾，提高性能。

四、MGR新節點加入過程

MGR中，新節點申請加入組，會在組中生成一個View_change事件，組內所有online節點將該事件寫入到binlog，同時，申請加入組的新節點也會記錄這個View_change事件，之后，該節點會進入下面兩個階段。

第一階段，新節點會從組內online的節點中選擇一個作為貢獻者(donor)，通過標準的異步復制通道，拉取貢獻者的binlog，并應用這些binlog。與此同時，新節點也會獲取當前組內正在交換的事務信息，并將其緩存到隊列中，當binlog應用完成，也就是應用到View_change事件處，異步復制通道關閉，進入第二階段。

第二階段，新節點處理緩存在隊列中的組內事務信息，當隊列中的事務信息處理完成，即緩存隊列長度為0時，新節點在組內狀態變為online。

在第一階段，遇到任何錯誤，新節點會自動從組內選擇另外一個online節點作為貢獻者，如果仍然遇到異常，會繼續選擇其他online節點，直到所有online節點枚舉完畢，如果這時仍然報錯，會sleep一段時間之后，再次重試，sleep時間和重試次數通過相應參數來控制。

第一階段，應用binlog的開始點由新節點的gtid_executed決定，結束點由View_change事件決定。MGR新節點加入組的第一階段，由于使用傳統的異步binlog數據同步，如果新加入的節點使用較早的備份，可能出現binlog接不上的情況，新節點一直處于RECOVERING狀態，在經過一定時間間隔和一定次數的重試后，恢復失敗，新節點從組中退出。另外一種情況，binlog能夠接上，但是binlog太多，導致應用binlog時間太長，同時第二階段緩存隊列也可能變得很大，整個恢復過程也將花費太長的時間。因些建議新節點加入組時，使用最近、最新的一次完整備份數據作為基礎。

下面附上View_change事件信息和binlog接不上的報錯信息。

View_change事件信息：

mysql> show binlog events;

+------------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+

| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |

+------------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+

| mysql-bin.000003 | 4 | Format_desc | 1 | 124 | Server ver: 8.0.11, Binlog ver: 4 |

| mysql-bin.000003 | 124 | Previous_gtids | 1 | 191 | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-18 |

| mysql-bin.000003 | 191 | Gtid | 1 | 269 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:19' |

| mysql-bin.000003 | 269 | Query | 1 | 331 | BEGIN |

| mysql-bin.000003 | 331 | View_change | 1 | 470 | view_id=15313080985527991:9 |

| mysql-bin.000003 | 470 | Query | 1 | 538 | COMMIT |

| mysql-bin.000003 | 538 | Gtid | 1 | 616 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:20' |

| mysql-bin.000003 | 616 | Query | 1 | 678 | BEGIN |

| mysql-bin.000003 | 678 | View_change | 1 | 817 | view_id=15313080985527991:11 |

| mysql-bin.000003 | 817 | Query | 1 | 885 | COMMIT |

+------------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+

10 rows in set (0.00 sec)

binlog接不上報錯信息：

image.png

本文簡單地介紹了MySQL MGR使用過程中應該注意的一些事項，由于接觸MGR時間不長，難免有些錯漏，歡迎留言討論，共同學習~

總結

以上是生活随笔為你收集整理的mysql mgr简介_MySQL Group Replication(MGR)使用简介与注意事项的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。