Mysql 8配置MGR單主多從集羣

一、MGR介紹

1、官方文檔

2、MGR介紹

MySQL Group Replication（下簡稱：MGR）是MySQL官方推出的一種基於Paxos協議的狀態機複製的高可用與高擴展的解決方案。在MGR出現之前，用戶常見的MySQL高可用方式，無論怎麼變化架構，本質就是Master-Slave架構。MySQL 5.7版本開始支持無損半同步複製（lossless semi-sync replication），從而進一步提升數據複製的強一致性。暫時只支持mysql5.7和mysql8.0版本。

MGR有以下優點

高一致性：基於原生複製及paxos協議的組複製技術。
高容錯性：有自動檢測機制，當出現宕機後,會自動剔除問題節點，其他節點可以正常使用(類似zk集羣)，當不同節點產生資源爭用衝突時,會按照先到先得處理，並且內置了自動化腦裂防護機制。
高擴展性：可隨時在線新增和移除節點，會自動同步所有節點上狀態，直到新節點和其他節點保持一致，自動維護新的組信息。
高靈活性：直接插件形式安裝(5.7.17後自帶.so插件),有單主模式和多主模式，單主模式下，只有主庫可以讀寫,其他從庫會加上super_read_only狀態,只能讀取不可寫入，出現故障會自動選主。

MGR基礎結構要求，見官方文檔Group Replication Requirements

引擎必須爲innodb，因爲需事務支持在commit時對各節點進行衝突檢查
每個表必須有主鍵，在進行事務衝突檢測時需要利用主鍵值對比
必須開啓binlog且爲row格式
開啓GTID，且主從狀態信息存於表中（–master-info-repository=TABLE 、–relay-log-info-repository=TABLE），–log-slave-updates打開
一致性檢測設置–transaction-write-set-extraction=XXHASH64

MGR使用限制，見官方文檔18.9.2 Group Replication Limitations

RP和普通複製binlog校驗不能共存，需設置–binlog-checksum=none
不支持gap lock(間隙鎖)，隔離級別需設置爲read_committed
不支持對錶進行鎖操作（lock /unlock table）,不會發送到其他節點執行 ,影響需要對錶進行加鎖操作的情況，列入mysqldump全表備份恢復操作
不支持serializable(序列化)隔離級別
DDL語句不支持原子性，不能檢測衝突，執行後需自行校驗是否一致
不支持外鍵：多主不支持，單主模式不存在此問題
最多支持9個節點：超過9臺server無法加入組

3、MGR與其他複製的對比介紹，見官方文檔

MySQL異步複製
master事務的提交不需要經過slave的確認，slave是否接收到master的binlog，master並不關心。slave接收到master binlog後先寫relay log，最後異步地去執行relay log中的sql應用到自身。由於master的提交不需要確保slave relay log是否被正確接受，當slave接受master binlog失敗或者relay log應用失敗，master無法感知。假設master發生宕機並且binlog還沒來得及被slave接收，而切換程序將slave提升爲新的master，就會出現數據不一致的情況！另外，在高併發的情況下，傳統的主從複製，從節點可能會與主產生較大的延遲，原理如下圖

MySQL半同步複製
基於傳統異步存在的缺陷，mysql在5.5版本推出半同步複製。可以說半同步複製是傳統異步複製的改進，在master事務的commit之前，必須確保一個slave收到relay log並且響應給master以後，才能進行事務的commit。但是slave對於relay log的應用仍然是異步進行的，原理如下圖

MySQL組複製（MGR）
基於傳統異步複製和半同步複製的缺陷——數據的一致性問題無法保證，MySQL官方在5.7.17版本正式推出組複製（MySQL Group Replication，簡稱MGR）。

由若干個節點共同組成一個複製組，一個事務的提交，必須經過組內大多數節點（N / 2 + 1）決議並通過，才能得以提交。如下圖所示，由3個節點組成一個複製組，Consensus層爲一致性協議層，在事務提交過程中，發生組間通訊，由2個節點決議(certify)通過這個事務，事務才能夠最終得以提交併響應。

引入組複製，主要是爲了解決傳統異步複製和半同步複製可能產生數據不一致的問題。組複製依靠分佈式一致性協議(Paxos協議的變體)，實現了分佈式下數據的最終一致性，提供了真正的數據高可用方案。一個複製組由若干個節點(數據庫實例)組成，組內各個節點維護各自的數據副本(Share Nothing)，通過一致性協議實現原子消息和全局有序消息，來實現組內實例數據的一致。原理如下圖

二、MGR搭建，見18.2 Getting Started

1、環境準備

IP	主機名	數據庫	端口	server-id	操作系統	備註
192.168.50.5	server-1	mysql-8.0.17	3306	5	ubuntu 16.04 server	master
192.168.50.6	server-2	mysql-8.0.17	3306	6	ubuntu 16.04 server	slave
192.168.50.7	server-3	mysql-8.0.17	3306	7	ubuntu 16.04 server	slave

在3臺服務器的/etc/hosts中加入以下配置

192.168.50.5 server-1
192.168.50.6 server-2
192.168.50.7 server-3

2、安裝MYSQL

安裝方法見搭建Linux項目環境（四）-安裝MYSQL

3、安裝MGR插件

三臺服務器都要裝

# 登錄mysql
mysql -uroot -p

# 安裝插件
install PLUGIN group_replication SONAME 'group_replication.so';

# 查看group replication插件
show plugins;

安裝完後如下圖所示

4、配置複製環境，見官方文檔18.2.1.2 Configuring an Instance for Group Replication

4.1、配置192.168.50.5（server-1）

打開/etc/mysql/my.cnf，添加以下配置

[mysqld]
# Group Replication
server-id=5
slow_query_log=1
log_queries_not_using_indexes=1
slow_query_log_file=/var/log/mysql/slow-query.log
log-bin=/var/log/mysql/mgr-bin
relay-log=/var/log/mysql/mgr-relay
character_set_server=utf8mb4

# MGR使用樂觀鎖，所以官網建議隔離級別是RC，減少鎖粒度
transaction_isolation=READ-COMMITTED
gtid_mode=on
enforce_gtid_consistency=1 # 強制GTID一致性
binlog_format=row

# 因爲集羣會在故障恢復時互相檢查binlog的數據,所以需要記錄下集羣內其他服務器發過來已經執行過的binlog,按GTID來區分是否執行過.
log-slave-updates=1

# binlog校驗規則，5.6之後的高版本是CRC32，低版本都是NONE，但是MGR要求使用NONE
binlog_checksum=NONE

# 基於安全的考慮，MGR集羣要求複製模式要改成slave記錄記錄到表中，不然就報錯
master_info_repository=TABLE
relay_log_info_repository=TABLE

# 記錄事務的算法,官網建議設置該參數使用 XXHASH64 算法
transaction_write_set_extraction = XXHASH64

# 加載group_replication插件
plugin_load_add='group_replication.so'

# 相當於此GROUP的名字，是UUID值，可以使用select uuid()生成
group_replication_group_name = '558edd3c-02ec-11ea-9bb3-080027e39bd2'

# 是否隨服務器啓動而自動啓動組複製，不建議直接啓動，怕故障恢復時有擾亂數據準確性的特殊情況
group_replication_start_on_boot = OFF

# 本地MGR的IP地址和端口，host:port,是MGR的端口,不是數據庫的端口
group_replication_local_address = 'server-1:33061'

# 需要接受本MGR實例控制的服務器IP地址和端口，是MGR的端口，不是數據庫的端口
group_replication_group_seeds = 'server-1:33061,server-2:33061,server-3:33061'

# 開啓引導模式，添加組成員，用於第一次搭建MGR或重建MGR的時候使用，只需要在集羣內的其中一臺開啓
group_replication_bootstrap_group = OFF

重啓mysql，命令service mysql restart

建立複製賬號並啓動group replication

# 登錄mysql
mysql -uroot -p

# 關閉日誌記錄
set SQL_LOG_BIN=0;

# 創建用戶（網段192.168.50的可以訪問）
CREATE USER 'mgr_repl'@'192.168.50.%' IDENTIFIED WITH sha256_password BY '123456';

# 授權
GRANT REPLICATION SLAVE ON *.* TO 'mgr_repl'@'192.168.50.%';

# 刷新權限
flush privileges;

# 開啓日誌
set SQL_LOG_BIN=1;

# 構建group replication集羣
change master to master_user='mgr_repl',master_password='123456' for channel 'group_replication_recovery';

# 設置group_replication_bootstrap_group爲ON是爲了標示以後加入集羣的服務器以這臺服務器爲基準，以後加入的就不需要設置
set global group_replication_bootstrap_group=ON;

# 作爲首個節點啓動MGR集羣
start group_replication;

# 關閉group_replication_bootstrap_group
set global group_replication_bootstrap_group=OFF;

# 查看mgr的狀態，查詢表performance_schema.replication_group_members
select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 4c668095-dd20-11e9-95ba-080027e39bd2 | server-1    |        3306 | ONLINE       | PRIMARY     | 8.0.17         |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

# group相關參數查看
show variables like 'group%';

4.2、配置192.168.50.6（server-2）

複製server-1的配置文件/etc/mysql/my.cnf，修改server_id，loose-group_replication_local_address即可，如下

[mysqld]
# Group Replication
server-id=6
slow_query_log=1
log_queries_not_using_indexes=1
slow_query_log_file=/var/log/mysql/slow-query.log
log-bin=/var/log/mysql/mgr-bin
relay-log=/var/log/mysql/mgr-relay
character_set_server=utf8mb4

# MGR使用樂觀鎖，所以官網建議隔離級別是RC，減少鎖粒度
transaction_isolation=READ-COMMITTED
gtid_mode=on
enforce_gtid_consistency=1 # 強制GTID一致性
binlog_format=row

# 因爲集羣會在故障恢復時互相檢查binlog的數據,所以需要記錄下集羣內其他服務器發過來已經執行過的binlog,按GTID來區分是否執行過.
log-slave-updates=1

# binlog校驗規則，5.6之後的高版本是CRC32，低版本都是NONE，但是MGR要求使用NONE
binlog_checksum=NONE

# 基於安全的考慮，MGR集羣要求複製模式要改成slave記錄記錄到表中，不然就報錯
master_info_repository=TABLE
relay_log_info_repository=TABLE

# 記錄事務的算法,官網建議設置該參數使用 XXHASH64 算法
transaction_write_set_extraction = XXHASH64

# 啓動時加載group_replication插件
plugin_load_add='group_replication.so'

# 相當於此GROUP的名字，是UUID值，可以使用select uuid()生成
group_replication_group_name = '558edd3c-02ec-11ea-9bb3-080027e39bd2'

# 是否隨服務器啓動而自動啓動組複製，不建議直接啓動，怕故障恢復時有擾亂數據準確性的特殊情況
group_replication_start_on_boot = OFF

# 本地MGR的IP地址和端口，host:port,是MGR的端口,不是數據庫的端口
group_replication_local_address = 'server-2:33061'

# 需要接受本MGR實例控制的服務器IP地址和端口，是MGR的端口，不是數據庫的端口
group_replication_group_seeds = 'server-1:33061,server-2:33061,server-3:33061'

# 開啓引導模式，添加組成員，用於第一次搭建MGR或重建MGR的時候使用，只需要在集羣內的其中一臺開啓
group_replication_bootstrap_group = OFF

重啓mysql，命令service mysql restart

建立複製賬號並啓動group replication

# 登錄mysql
mysql -uroot -p

# 關閉日誌記錄
set SQL_LOG_BIN=0;

# 創建用戶（網段192.168.50的可以訪問）
CREATE USER 'mgr_repl'@'192.168.50.%' IDENTIFIED WITH sha256_password BY '123456';

# 授權
GRANT REPLICATION SLAVE ON *.* TO 'mgr_repl'@'192.168.50.%';

# 刷新權限
flush privileges;

# 開啓日誌
set SQL_LOG_BIN=1;

# 構建group replication集羣
change master to master_user='mgr_repl',master_password='123456' for channel 'group_replication_recovery';

# 加入MGR集羣
start group_replication;

# 查看mgr的狀態，查詢表performance_schema.replication_group_members，發現已加入MGR羣
select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 4c668095-dd20-11e9-95ba-080027e39bc3 | server-2    |        3306 | RECOVERING   | SECONDARY   | 8.0.17         |
| group_replication_applier | 4c668095-dd20-11e9-95ba-080027e39bd2 | server-1    |        3306 | ONLINE       | PRIMARY     | 8.0.17         |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

節點長時間處於RECOVERING狀態，見下面第6.1節，有解決方法

4.3、配置192.168.50.7（server-3）

複製server-1的配置文件/etc/mysql/my.cnf，修改server_id，loose-group_replication_local_address即可，如下

[mysqld]
# Group Replication
server-id=7
slow_query_log=1
log_queries_not_using_indexes=1
slow_query_log_file=/var/log/mysql/slow-query.log
log-bin=/var/log/mysql/mgr-bin
relay-log=/var/log/mysql/mgr-relay
character_set_server=utf8mb4

# MGR使用樂觀鎖，所以官網建議隔離級別是RC，減少鎖粒度
transaction_isolation=READ-COMMITTED
gtid_mode=on
enforce_gtid_consistency=1 # 強制GTID一致性
binlog_format=row

# 因爲集羣會在故障恢復時互相檢查binlog的數據,所以需要記錄下集羣內其他服務器發過來已經執行過的binlog,按GTID來區分是否執行過.
log-slave-updates=1

# binlog校驗規則，5.6之後的高版本是CRC32，低版本都是NONE，但是MGR要求使用NONE
binlog_checksum=NONE

# 基於安全的考慮，MGR集羣要求複製模式要改成slave記錄記錄到表中，不然就報錯
master_info_repository=TABLE
relay_log_info_repository=TABLE

# 記錄事務的算法,官網建議設置該參數使用 XXHASH64 算法
transaction_write_set_extraction = XXHASH64

# 啓動時加載group_replication插件
plugin_load_add='group_replication.so'

# 相當於此GROUP的名字，是UUID值，可以使用select uuid()生成
group_replication_group_name = '558edd3c-02ec-11ea-9bb3-080027e39bd2'

# 是否隨服務器啓動而自動啓動組複製，不建議直接啓動，怕故障恢復時有擾亂數據準確性的特殊情況
group_replication_start_on_boot = OFF

# 本地MGR的IP地址和端口，host:port,是MGR的端口,不是數據庫的端口
group_replication_local_address = 'server-3:33061'

# 需要接受本MGR實例控制的服務器IP地址和端口，是MGR的端口，不是數據庫的端口
group_replication_group_seeds = 'server-1:33061,server-2:33061,server-3:33061'

# 開啓引導模式，添加組成員，用於第一次搭建MGR或重建MGR的時候使用，只需要在集羣內的其中一臺開啓
group_replication_bootstrap_group = OFF

重啓mysql，命令service mysql restart

建立複製賬號並啓動group replication

# 登錄mysql
mysql -uroot -p

# 關閉日誌記錄
set SQL_LOG_BIN=0;

# 創建用戶（網段192.168.50的可以訪問）
CREATE USER 'mgr_repl'@'192.168.50.%' IDENTIFIED WITH sha256_password BY '123456';

# 授權
GRANT REPLICATION SLAVE ON *.* TO 'mgr_repl'@'192.168.50.%';

# 刷新權限
flush privileges;

# 開啓日誌
set SQL_LOG_BIN=1;

# 構建group replication集羣
change master to master_user='mgr_repl',master_password='123456' for channel 'group_replication_recovery';

# 加入MGR集羣
start group_replication;

# 查看mgr的狀態，查詢表performance_schema.replication_group_members，發現已加入MGR羣
mysql> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 4c668095-dd20-11e9-95ba-080027e39bc3 | server-2    |        3306 | ONLINE       | SECONDARY   | 8.0.17         |
| group_replication_applier | 4c668095-dd20-11e9-95ba-080027e39bd2 | server-1    |        3306 | ONLINE       | PRIMARY     | 8.0.17         |
| group_replication_applier | c90e9166-de11-11e9-9ee0-080027d8da86 | server-3    |        3306 | ONLINE       | SECONDARY   | 8.0.17         |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

5、測試

在server-1（192.168.50.5）上執行以下sql

# 測試server-1上的mysql
create database repl;
use repl;
create table test (id int primary key, name varchar(20));  #注意創建主鍵
insert into test values (1,'測試');

# 查看binlog
SHOW BINLOG EVENTS;

查看server-1的結果

mysql> select * from test;
+----+--------+
| id | name   |
+----+--------+
|  1 | 測試   |
+----+--------+

查看server-2的結果

# repl數據庫已同步過來了
mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mybatis            |
| mysql              |
| performance_schema |
| repl               |
| sys                |
+--------------------+
mysql> use repl;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed

-- 數據也同步過來了
mysql> select * from test;
+----+--------+
| id | name   |
+----+--------+
|  1 | 測試   |
+----+--------+

查看server-3的結果

# repl數據庫已同步過來了
mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mybatis            |
| mysql              |
| performance_schema |
| repl               |
| sys                |
+--------------------+
mysql> use repl;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed

-- 數據也同步過來了
mysql> select * from test;
+----+--------+
| id | name   |
+----+--------+
|  1 | 測試   |
+----+--------+

因爲是單主模式，server-1爲主（PRIMARY），支持讀寫，server-2和server-3爲從（SECONDARY），只支持讀，如果執行寫會失敗，如下

在server-2和server-3中執行insert into test values (2,'寫入測試');，都會報以下錯誤

mysql> insert into test values (2,'寫入測試');
ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement

在server-1執行則成功

mysql> insert into test values (2,'寫入測試');
Query OK, 1 row affected (0.11 sec)

6、常見的錯誤

`6.1 節點長期處於RECOVERING狀態的解決方法`

查看日誌，發現是用戶密碼加密插件問題Authentication plugin 'caching_sha2_password' reported error: Authentication requires secure connection.，也就是創建複製用戶時，密碼默認是mysql 8的加密方式

2019-11-09T14:59:18.932184Z 28 [ERROR] [MY-011583] [Repl] Plugin group_replication reported: 'For details please check performance_schema.replication_connection_status table and error log messages of Slave I/O for channel group_replication_recovery.'
2019-11-09T15:00:19.061955Z 28 [System] [MY-010597] [Repl] 'CHANGE MASTER TO FOR CHANNEL 'group_replication_recovery' executed'. Previous state master_host='server-1', master_port= 3306, master_log_file='', master_log_pos= 4, master_bind=''. New state master_host='server-1', master_port= 3306, master_log_file='', master_log_pos= 4, master_bind=''.
2019-11-09T15:00:19.144499Z 37 [Warning] [MY-010897] [Repl] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.
2019-11-09T15:00:19.154364Z 37 [ERROR] [MY-010584] [Repl] Slave I/O for channel 'group_replication_recovery': error connecting to master 'mgr_repl@server-1:3306' - retry-time: 60 retries: 1 message: Authentication plugin 'caching_sha2_password' reported error: Authentication requires secure connection. Error_code: MY-002061
2019-11-09T15:00:19.196600Z 28 [ERROR] [MY-011582] [Repl] Plugin group_replication reported: 'There was an error when connecting to the donor server. Please check that group_replication_recovery channel credentials and all MEMBER_HOST column values of performance_schema.replication_group_members table are correct and DNS resolvable.'
2019-11-09T15:00:19.196632Z 28 [ERROR] [MY-011583] [Repl] Plugin group_replication reported: 'For details please check performance_schema.replication_connection_status table and error log messages of Slave I/O for channel group_replication_recovery.'

解決方法，更改密碼加密方式

SET SQL_LOG_BIN=0;
alter USER 'mgr_repl'@'192.168.50.%' IDENTIFIED WITH sha256_password BY '123456';
GRANT REPLICATION SLAVE ON *.* TO 'mgr_repl'@'192.168.50.%';
SET SQL_LOG_BIN=1;

再啓動MGR就可以正常了

select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 4c668095-dd20-11e9-95ba-080027e39bc3 | server-2    |        3306 | ONLINE       | SECONDARY   | 8.0.17         |
| group_replication_applier | 4c668095-dd20-11e9-95ba-080027e39bd2 | server-1    |        3306 | ONLINE       | PRIMARY     | 8.0.17         |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

7、管理維護

7.1 單主切換到多主

# MGR切換模式需要重新啓動組複製，因此需要在所有節點上先關閉組複製，
# 設置 group_replication_single_primary_mode=OFF 等參數，再啓動組複製。
# 停止組複製(在所有MGR節點上執行)：
stop group_replication;

# 單主模式關閉
set global group_replication_single_primary_mode=OFF;

# 如果是單主模式,因爲不存在多主同時操作的可能,這個強制檢查是可以關閉,因爲已經不存在這樣的操作,多主是必須要開的,不開的話數據就可能出現錯亂了
set global group_replication_enforce_update_everywhere_checks=ON;

# 隨便選擇某個MGR節點執行 (比如這裏選擇在server-1節點):
set global group_replication_recovery_get_public_key=1;
SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;

# 然後在其他的MGR節點執行 (這裏指server-2和server-3節點上執行):
set global group_replication_recovery_get_public_key=1;
START GROUP_REPLICATION;

# 查看MGR組信息 (在任意一個MGR節點上都可以查看)
SELECT * FROM performance_schema.replication_group_members;

7.2 多主切換回單主

# 停止組複製(在所有MGR節點上執行)：
stop group_replication;

# 如果是單主模式,因爲不存在多主同時操作的可能,這個強制檢查是可以關閉,因爲已經不存在這樣的操作,多主是必須要開的,不開的話數據就可能出現錯亂了
set global group_replication_enforce_update_everywhere_checks=OFF;

# 打開單主模式
set global group_replication_single_primary_mode=ON;

# 選擇一個節點作爲主節點, 在主節點上執行 (這裏選擇server-1節點作爲主節點)
SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;
 
# 在其他剩餘的節點, 也就是從庫節點上執行 (這裏從庫節點指的就是server-2和server-3):
START GROUP_REPLICATION;

# 查看MGR組信息 (在任意一個MGR節點上都可以查看)
SELECT * FROM performance_schema.replication_group_members;

7.3 常用命令及語句

# 查一下GTID，是否爲之前設的那個group的uuid（558edd3c-02ec-11ea-9bb3-080027e39bd2）
mysql> show master status;
+----------------+----------+--------------+------------------+------------------------------------------+
| File           | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                        |
+----------------+----------+--------------+------------------+------------------------------------------+
| mgr-bin.000004 |     2208 |              |                  | 558edd3c-02ec-11ea-9bb3-080027e39bd2:1-9 |
+----------------+----------+--------------+------------------+------------------------------------------+

# 查看group內所有成員的節點信息
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 4c668095-dd20-11e9-95ba-080027e39bc3 | server-2    |        3306 | ONLINE       | SECONDARY   | 8.0.17         |
| group_replication_applier | 4c668095-dd20-11e9-95ba-080027e39bd2 | server-1    |        3306 | ONLINE       | PRIMARY     | 8.0.17         |
| group_replication_applier | c90e9166-de11-11e9-9ee0-080027d8da86 | server-3    |        3306 | ONLINE       | SECONDARY   | 8.0.17         |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

# 查看GROUP中的同步情況,當前複製狀態
mysql> select * from performance_schema.replication_group_member_stats\G;
*************************** 1. row ***************************
                              CHANNEL_NAME: group_replication_applier
                                   VIEW_ID: 15733926047947018:3
                                 MEMBER_ID: 4c668095-dd20-11e9-95ba-080027e39bc3
               COUNT_TRANSACTIONS_IN_QUEUE: 0
                COUNT_TRANSACTIONS_CHECKED: 4
                  COUNT_CONFLICTS_DETECTED: 0
        COUNT_TRANSACTIONS_ROWS_VALIDATING: 1
        TRANSACTIONS_COMMITTED_ALL_MEMBERS: 558edd3c-02ec-11ea-9bb3-080027e39bd2:1-9
            LAST_CONFLICT_FREE_TRANSACTION: 558edd3c-02ec-11ea-9bb3-080027e39bd2:9
COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 0
         COUNT_TRANSACTIONS_REMOTE_APPLIED: 5
         COUNT_TRANSACTIONS_LOCAL_PROPOSED: 0
         COUNT_TRANSACTIONS_LOCAL_ROLLBACK: 0
*************************** 2. row ***************************
                              CHANNEL_NAME: group_replication_applier
                                   VIEW_ID: 15733926047947018:3
                                 MEMBER_ID: 4c668095-dd20-11e9-95ba-080027e39bd2
               COUNT_TRANSACTIONS_IN_QUEUE: 0
                COUNT_TRANSACTIONS_CHECKED: 4
                  COUNT_CONFLICTS_DETECTED: 0
        COUNT_TRANSACTIONS_ROWS_VALIDATING: 1
        TRANSACTIONS_COMMITTED_ALL_MEMBERS: 558edd3c-02ec-11ea-9bb3-080027e39bd2:1-9
            LAST_CONFLICT_FREE_TRANSACTION: 558edd3c-02ec-11ea-9bb3-080027e39bd2:9
COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 0
         COUNT_TRANSACTIONS_REMOTE_APPLIED: 2
         COUNT_TRANSACTIONS_LOCAL_PROPOSED: 4
         COUNT_TRANSACTIONS_LOCAL_ROLLBACK: 0
*************************** 3. row ***************************
                              CHANNEL_NAME: group_replication_applier
                                   VIEW_ID: 15733926047947018:3
                                 MEMBER_ID: c90e9166-de11-11e9-9ee0-080027d8da86
               COUNT_TRANSACTIONS_IN_QUEUE: 0
                COUNT_TRANSACTIONS_CHECKED: 4
                  COUNT_CONFLICTS_DETECTED: 0
        COUNT_TRANSACTIONS_ROWS_VALIDATING: 1
        TRANSACTIONS_COMMITTED_ALL_MEMBERS: 558edd3c-02ec-11ea-9bb3-080027e39bd2:1-9
            LAST_CONFLICT_FREE_TRANSACTION: 558edd3c-02ec-11ea-9bb3-080027e39bd2:9
COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 0
         COUNT_TRANSACTIONS_REMOTE_APPLIED: 4
         COUNT_TRANSACTIONS_LOCAL_PROPOSED: 0
         COUNT_TRANSACTIONS_LOCAL_ROLLBACK: 0

# 當前server中各個通道的使用情況
mysql> select * from performance_schema.replication_connection_status\G;
*************************** 1. row ***************************
                                      CHANNEL_NAME: group_replication_applier
                                        GROUP_NAME: 558edd3c-02ec-11ea-9bb3-080027e39bd2
                                       SOURCE_UUID: 558edd3c-02ec-11ea-9bb3-080027e39bd2
                                         THREAD_ID: NULL
                                     SERVICE_STATE: ON
                         COUNT_RECEIVED_HEARTBEATS: 0
                          LAST_HEARTBEAT_TIMESTAMP: 0000-00-00 00:00:00.000000
                          RECEIVED_TRANSACTION_SET: 558edd3c-02ec-11ea-9bb3-080027e39bd2:1-9
                                 LAST_ERROR_NUMBER: 0
                                LAST_ERROR_MESSAGE: 
                              LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000
                           LAST_QUEUED_TRANSACTION: 558edd3c-02ec-11ea-9bb3-080027e39bd2:5
 LAST_QUEUED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
LAST_QUEUED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
     LAST_QUEUED_TRANSACTION_START_QUEUE_TIMESTAMP: 2019-11-10 21:35:36.917108
       LAST_QUEUED_TRANSACTION_END_QUEUE_TIMESTAMP: 2019-11-10 21:35:36.917146
                              QUEUEING_TRANSACTION: 
    QUEUEING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
   QUEUEING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
        QUEUEING_TRANSACTION_START_QUEUE_TIMESTAMP: 0000-00-00 00:00:00.000000

# 當前server中各個通道是否啓用,on是啓用
mysql> select * from performance_schema.replication_applier_status;
+---------------------------+---------------+-----------------+----------------------------+
| CHANNEL_NAME              | SERVICE_STATE | REMAINING_DELAY | COUNT_TRANSACTIONS_RETRIES |
+---------------------------+---------------+-----------------+----------------------------+
| group_replication_applier | ON            |            NULL |                          0 |
+---------------------------+---------------+-----------------+----------------------------+

8、故障注意事項

# 單主模式，恢復MGR-node1節點, 恢復後, 需要手動激活下該節點的組複製功能
# 如果節點發生故障, 在恢復後需要重新加入到MGR集羣裏, 正確的做法是:
STOP GROUP_REPLICATION;
START GROUP_REPLICATION;

# 如果某個節點掛了, 則其他的節點繼續進行同步。當故障節點恢復後, 只需要手動激活下該節點的組複製功能, 即可正常加入到MGR組複製集羣內並自動同步其他節點數據。
START GROUP_REPLICATION;

# 如果是i/o複製出現異常，確定數據無誤後
# 查找主庫的gtid情況
mysql> show global variables like '%gtid%';
+----------------------------------------------+------------------------------------------+
| Variable_name                                | Value                                    |
+----------------------------------------------+------------------------------------------+
| binlog_gtid_simple_recovery                  | ON                                       |
| enforce_gtid_consistency                     | ON                                       |
| group_replication_gtid_assignment_block_size | 1000000                                  |
| gtid_executed                                | 558edd3c-02ec-11ea-9bb3-080027e39bd2:1-9 |
| gtid_executed_compression_period             | 1000                                     |
| gtid_mode                                    | ON                                       |
| gtid_owned                                   |                                          |
| gtid_purged                                  |                                          |
| session_track_gtids                          | OFF                                      |
+----------------------------------------------+------------------------------------------+

# 在有故障的從庫中操作
stop GROUP_REPLICATION;
reset master;
set global gtid_purged='58f6e65e-9309-11e9-9d88-525400184a0a:1-946055:1000003';
START GROUP_REPLICATION;

# 添加白名單網段，一定要注意: 先關閉 Group Replication
stop group_replication;
set global group_replication_ip_whitelist="127.0.0.1/32,172.16.60.0/24,172.16.50.0/24,172.16.51.0/24";
start group_replication;
show variables like "group_replication_ip_whitelist";

Mysql 8配置MGR單主多從集羣

一、MGR介紹

1、官方文檔

2、MGR介紹

3、MGR與其他複製的對比介紹，見官方文檔

二、MGR搭建，見18.2 Getting Started

1、環境準備

2、安裝MYSQL

3、安裝MGR插件

4、配置複製環境，見官方文檔18.2.1.2 Configuring an Instance for Group Replication

4.1、配置192.168.50.5（server-1）

4.2、配置192.168.50.6（server-2）

4.3、配置192.168.50.7（server-3）

5、測試

因爲是單主模式，server-1爲主（PRIMARY），支持讀寫，server-2和server-3爲從（SECONDARY），只支持讀，如果執行寫會失敗，如下

6、常見的錯誤

`6.1 節點長期處於RECOVERING狀態的解決方法`

7、管理維護

7.1 單主切換到多主

7.2 多主切換回單主

7.3 常用命令及語句

8、故障注意事項

Mysql主從複製（一）原理介紹

Mysql主從複製（三）主主複製配置

IntelliJ IDEA入門（二）配置文件目錄更改

Mysql主從複製slave啓動報Slave failed to initialize relay log info structure from the repository

mysql主從複製報The slave I/O thread stops because master and slave have equal MySQL server UUIDs

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結