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

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

一、MGR使用限制

僅支持innodb存儲引擎

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

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的唯一鍵，否則即使能夠創(chuàng)建表，也無法向表中寫入數(shù)據(jù)。

# 創(chuàng)建沒有主鍵的表，寫入數(shù)據(jù)失敗

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.

# 創(chuàng)建Null唯一索引的表，寫入數(shù)據(jù)失敗

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.

# 創(chuàng)建非Null唯一索引的表，寫入數(shù)據(jù)成功

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

網(wǎng)絡(luò)限制

MGR 組通信引擎目前僅支持IPv4網(wǎng)絡(luò)，并且對節(jié)點間的網(wǎng)絡(luò)性能要求較高，低延遲、高帶寬的網(wǎng)絡(luò)是部署MGR集群的基礎(chǔ)。

MGR忽略表鎖和命名鎖，在MGR中l(wèi)ock tables、unlock tables、get_lock、release_lock等這些表鎖和命名鎖將被忽略。

MGR多主模式中，默認(rèn)不支持 SERIALIZABLE 隔離級別。

多主模式下，對同一個對象進(jìn)行并發(fā)的有沖突的ddl和dml操作導(dǎo)致這種沖突在部分成員節(jié)點中無法檢測到，最終可能導(dǎo)致數(shù)據(jù)不一致。

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

不支持超大事務(wù)。

多主模式下可能導(dǎo)致死鎖，比如select ...for update在不同節(jié)點執(zhí)行，由于多節(jié)點鎖無法共享，很容易導(dǎo)致死鎖。

不支持復(fù)制過濾，如果有節(jié)點設(shè)置了復(fù)制過濾，將影響節(jié)點間決議的達(dá)成。

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

二、節(jié)點配置要求

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

并行復(fù)制

slave_parallel_type=LOGICAL_CLOCK

slave_preserve_commit_order=1

slave_parallel_workers=[N]

binlog_checksum=NONE

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

三、MGR沖突檢測

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

四、MGR新節(jié)點加入過程

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

第一階段，新節(jié)點會從組內(nèi)online的節(jié)點中選擇一個作為貢獻(xiàn)者(donor)，通過標(biāo)準(zhǔn)的異步復(fù)制通道，拉取貢獻(xiàn)者的binlog，并應(yīng)用這些binlog。與此同時，新節(jié)點也會獲取當(dāng)前組內(nèi)正在交換的事務(wù)信息，并將其緩存到隊列中，當(dāng)binlog應(yīng)用完成，也就是應(yīng)用到View_change事件處，異步復(fù)制通道關(guān)閉，進(jìn)入第二階段。

第二階段，新節(jié)點處理緩存在隊列中的組內(nèi)事務(wù)信息，當(dāng)隊列中的事務(wù)信息處理完成，即緩存隊列長度為0時，新節(jié)點在組內(nèi)狀態(tài)變?yōu)閛nline。

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

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

下面附上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使用過程中應(yīng)該注意的一些事項，由于接觸MGR時間不長，難免有些錯漏，歡迎留言討論，共同學(xué)習(xí)~

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。