MySQL+MGR 單主模式和多主模式的集羣環境 - 部署手冊 (Centos7.5)

 

MySQL Group Replication(簡稱MGR)是MySQL官方於2016年12月推出的一個全新的高可用與高擴展的解決方案。MGR是MySQL官方在5.7.17版本引進的一個數據庫高可用與高擴展的解決方案,以插件形式提供,實現了分佈式下數據的最終一致性, 它是MySQL5.7版本出現的新特性,它提供了高可用、高擴展、高可靠的MySQL集羣服務。MySQL組複製分單主模式和多主模式,mysql 的複製技術僅解決了數據同步的問題,若是 master 宕機,意味着數據庫管理員須要介入,應用系統可能須要修改數據庫鏈接地址或者重啓才能實現。(這裏也可使用數據庫中間件產品來避免應用系統數據庫鏈接的問題,例如 mycat 和 atlas 等產品)。組複製在數據庫層面上作到了,只要集羣中大多數主機可用,則服務可用,也就是說3臺服務器的集羣,容許其中1臺宕機。html

注意:  組中server可在獨立物理機運行,也可在同一臺機器,同一機器採用多實例,也就是邏輯認爲是獨立機器; 組內每臺主機,都須要先安裝組複製插件.不然會致使啓動失敗.node

1.  MGR組複製的特色
高一致性基於分佈式paxos協議實現組複製,保證數據一致性;
高容錯性:自動檢測機制,只要不是大多數節點都宕機就能夠繼續工做,內置防腦裂保護機制;
高擴展性:節點的增長與移除會自動更新組成員信息,新節點加入後,自動從其餘節點同步增量數據,直到與其餘節點數據一致;
高靈活性:提供單主模式和多主模式,單主模式在主庫宕機後可以自動選主,全部寫入都在主節點進行,多主模式支持多節點寫入。mysql

2.  MGR與傳統複製的區別和大幅改進
2.1 傳統複製 (即異步複製)
主-從複製:有一個主和不等數量的從。主節點執行的事務會異步發送給從節點,在從節點從新執行。便是在主節點執行和提交事務,而後把他們異步的發送到從節點,行復制的從新執行主節點的SQL語句,這是一個 shared-nothing 的系統,默認狀況下全部 server 成員都有一個完整的數據副本。
linux

2.2 半同步複製
它在協議中添加了一個同步步驟。 這意味着主節點在提交時須要等待從節點確認它已經接收到事務。只有這樣,主節點才能繼續提交操做。 半同步相對異步來講, Master會確認Slave是否接到數據,更加安全。算法

2.3 並行複製
並行複製:複製->廣播->正式複製. 並行複製的介紹可在https://www.cnblogs.com/kevingrace/p/5569652.html 文中有介紹sql

2.4 組複製 (MGR)數據庫

MGR組複製原理
組複製是一種可用於實現容錯系統的技術。 複製組是一個經過消息傳遞相互交互的 server 集羣。通訊層提供了原子消息(atomic message)和徹底有序信息交互等保障機制實現了基於複製協議的多主更新 複製組由多個 server成員構成,而且組中的每一個 server 成員能夠獨立地執行事務。但全部讀寫(RW)事務只有在衝突檢測成功後纔會提交。只讀(RO)事務不須要在衝突檢測,能夠當即提交。句話說,對於任何 RW 事務,提交操做並非由始發 server 單向決定的,而是由組來決定是否提交。準確地說,在始發 server 上,當事務準備好提交時,該 server 會廣播寫入值(已改變的行)和對應的寫入集(已更新的行的惟一標識符)。而後會爲該事務創建一個全局的順序。最終,這意味着全部 server 成員以相同的順序接收同一組事務。所以,全部 server 成員以相同的順序應用相同的更改,以確保組內一致。bootstrap

MySQL組複製協議工做流程:vim

須要注意:MGR組複製是一種 share-nothing 複製方案,其中每一個 server 成員都有本身的完整數據副本。安全

MGR實現了基於複製協議的多主更新
->  複製組由多個 server成員構成,而且組中的每一個 server 成員能夠獨立地執行事務。但全部讀寫(RW)事務只有在衝突檢測成功後纔會提交。只讀(RO)事務不須要在衝突檢測,能夠當即提交。
->  換句話說,對於任何 RW 事務,提交操做並非由始發 server 單向決定的,而是由組來決定是否提交。準確地說,在始發 server 上,當事務準備好提交時,該 server 會廣播寫入值(已改變的行)和對應的寫入集(已更新的行的惟一標識符)。而後會爲該事務創建一個全局的順序。最終,這意味着全部 server 成員以相同的順序接收同一組事務。所以,全部 server 成員以相同的順序應用相同的更改,以確保組內一致。
->  組複製使您可以根據在一組 server 中複製系統的狀態來建立具備冗餘的容錯系統。所以,只要它不是所有或多數 server 發生故障,即便有一些 server 故障,系統仍然可用,最多隻是性能和可伸縮性下降,但它仍然可用。server 故障是孤立而且獨立的。它們由組成員服務來監控,組成員服務依賴於分佈式故障檢測系統,其可以在任何 server 自願地或因爲意外中止而離開組時發出信號。
->  他們是由一個分佈式恢復程序來確保當有 server 加入組時,它們會自動更新組信息到最新。而且多主更新確保了即便在單個服務器故障的狀況下也不會阻止更新,沒必要進行 server故障轉移。所以,MySQL 組複製保證數據庫服務持續可用。
->  值得注意的一點是,儘管數據庫服務可用,但當有一個 server 崩潰時,鏈接到它的客戶端必須定向或故障轉移到不一樣的 server。這不是組複製要解決的問題。鏈接器,負載均衡器,路由器或其餘形式的中間件更適合處理這個問題。

總之,MGR組複製提供了高可用性,高彈性,可靠的 MySQL 服務。

MGR故障檢測
故障檢測是提供關於哪些 server 可能已死的信息(猜想)的分佈式服務。 某個 server 無響應時觸發猜想,組中其他成員進行協調決定以排除給定成員。若是某個 server 與組的其他成員隔離,則它會懷疑全部其餘 server 都失敗了。因爲沒法與組達成協議(由於它沒法確保仲裁成員數),其懷疑不會產生後果。當服務器以此方式與組隔離時,它沒法執行任何本地事務。 在線 server 列表一般稱爲視圖,新成員server的加入離開,不管是自願仍是被迫的離開,該組都會動態地從新規劃其配置,並觸發視圖更新

MGR的限制
- 存儲引擎必須爲Innodb,即僅支持InnoDB表,而且每張表必定要有一個主鍵,用於作write set的衝突檢測;
- 每一個表必須提供主鍵;
- 只支持ipv4,網絡需求較高;
- 必須打開GTID特性,二進制日誌格式必須設置爲ROW,用於選主與write set;
- COMMIT可能會致使失敗,相似於快照事務隔離級別的失敗場景;
- 目前一個MGR集羣組最多支持9個節點;
- 不支持外鍵於save point特性,沒法作全局間的約束檢測與部分部分回滾;
- 二進制日誌binlog不支持Replication event checksums;
- 多主模式(也就是多寫模式) 不支持SERIALIZABLE事務隔離級別;
- 多主模式不能徹底支持級聯外鍵約束;
- 多主模式不支持在不一樣節點上對同一個數據庫對象併發執行DDL(在不一樣節點上對同一行併發進行RW事務,後發起的事務會失敗);

MGR組複製優點
-  彈性複製(高擴展性):server動態添加移除
-  高可用分片(高擴展性):分片實現寫擴展,每一個分片是一個複製組。
-  替代主從複製(高擴展性):整組寫入,避免單點爭用。
-  自動化系統:自動化部署Mysql複製到已有複製協議的自動化系統。
-  故障檢測與容錯:自動檢測,若服務faild,組內成員大多數達成認爲該服務已不正常,則自動隔離。
-  組內成員會構成一個視圖,組內成員主動加入或離開(主動或被動),都會更新組配置,更新視圖。成員自願離開,先更新組配置,而後採用大多數成員(不包含主動脫離的成員)意見是否確認該成員離開更新視圖。若是是故障要排除,則需大多數服務確認(包括故障成員意見),而後纔會更新組配置和視圖。   
-  最大容許即時故障數:f=(n-1)/2,多數正常則正常

3.  組複製兩種運行模式
->  單主模式下, 組複製具備自動選主功能,每次只有一個 server成員接受更新。單寫模式group內只有一臺節點可寫可讀,其餘節點只能夠讀。對於group的部署,須要先跑起primary節點(即那個可寫可讀的節點,read_only = 0)而後再跑起其餘的節點,並把這些節點一一加進group。其餘的節點就會自動同步primary節點上面的變化,而後將本身設置爲只讀模式(read_only = 1)。當primary節點意外宕機或者下線,在知足大多數節點存活的狀況下,group內部發起選舉,選出下一個可用的讀節點,提高爲primary節點。primary選舉根據group內剩下存活節點的UUID按字典序升序來選擇,即剩餘存活的節點按UUID字典序排列,而後選擇排在最前的節點做爲新的primary節點。
-> 多主模式下, 全部的 server 成員均可以同時接受更新。group內的全部機器都是primary節點,同時能夠進行讀寫操做,而且數據是最終一致的。

按照個人理解來講:
單主模式:比多主模式多一個選舉程序,第一次引導開啓集羣的爲主,後加入的爲追隨者(也能夠叫從機Slave),只有住的有讀寫權限,別的追隨者在加入組的時候自動把權限禁了。若是主的掛了,其餘服務器會根據UUID和一個值(相似權重)進行從新選主。每次選主都會從新把權限禁一遍。

多主模式:全部服務器加入組時,讀寫權限所有放開,你們均可以讀寫,可是隻能更改不一樣行的數據,若是後加入集羣的服務器改了一行數據,那前面的服務器就不能再對這行數據進行改動了,若是改動則報事務回滾取消改動,然後加入的能夠改前面加入集羣改過的數據。

4. 下面分別記錄下 MGR 基於單主模式和多主模式的集羣環境部署過程
4.1 準備環境

三臺服務器
172.16.60.211     MGR-node1    server_id=1
172.16.60.212     MGR-node2    server_id=2
172.16.60.213     MGR-node3    server_id=3

[root@MGR-node1 ~]# cat /etc/redhat-release
CentOS Linux release 7.5.1804 (Core)
   
爲了方便實驗,關閉全部節點的防火牆
[root@MGR-node1 ~]# systemctl stop firewalld
[root@MGR-node1 ~]# firewall-cmd --state
not running
   
[root@MGR-node1 ~]# cat /etc/sysconfig/selinux |grep "SELINUX=disabled"
SELINUX=disabled
[root@MGR-node1 ~]# setenforce 0            
setenforce: SELinux is disabled
[root@MGR-node1 ~]# getenforce              
Disabled
 
特別要注意一個關鍵點: 必須保證各個mysql節點的主機名不一致,而且能經過主機名找到各成員!
則必需要在每一個節點的/etc/hosts裏面作主機名綁定,不然後續將節點加入group組會失敗!報錯RECOVERING!!
[root@MGR-node1 ~]# cat /etc/hosts
........
172.16.60.211    MGR-node1
172.16.60.212    MGR-node2
172.16.60.213    MGR-node3

4.2  在三個節點上安裝Mysql5.7

在三個mysql節點機上使用yum方式安裝Mysql5.7,參考:https://www.cnblogs.com/kevingrace/p/8340690.html
   
安裝MySQL yum資源庫
[root@MGR-node1 ~]# yum localinstall https://dev.mysql.com/get/mysql57-community-release-el7-8.noarch.rpm
   
安裝MySQL 5.7
[root@MGR-node1 ~]# yum install -y mysql-community-server
   
啓動MySQL服務器和MySQL的自動啓動
[root@MGR-node1 ~]# systemctl start mysqld.service
[root@MGR-node1 ~]# systemctl enable mysqld.service
   
設置登陸密碼
因爲MySQL從5.7開始不容許首次安裝後使用空密碼進行登陸!爲了增強安全性,系統會隨機生成一個密碼以供管理員首次登陸使用,
這個密碼記錄在/var/log/mysqld.log文件中,使用下面的命令能夠查看此密碼:
[root@MGR-node1 ~]# cat /var/log/mysqld.log|grep 'A temporary password'
2019-01-11T05:53:17.824073Z 1 [Note] A temporary password is generated for root@localhost: TaN.k:*Qw2xs
   
使用上面查看的密碼TaN.k:*Qw2xs 登陸mysql,並重置密碼爲123456
[root@MGR-node1 ~]# mysql -p                 #輸入默認的密碼:TaN.k:*Qw2xs
.............
mysql> set global validate_password_policy=0;
Query OK, 0 rows affected (0.00 sec)
   
mysql> set global validate_password_length=1;
Query OK, 0 rows affected (0.00 sec)
   
mysql> set password=password("123456");
Query OK, 0 rows affected, 1 warning (0.00 sec)
   
mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)
   
查看mysql版本
[root@MGR-node1 ~]# mysql -p123456
........
mysql> select version();
+-----------+
| version() |
+-----------+
| 5.7.24    |
+-----------+
1 row in set (0.00 sec)
  
=====================================================================
舒適提示
mysql5.7經過上面默認安裝後,執行語句可能會報錯:
ERROR 1819 (HY000): Your password does not satisfy the current policy requirements
  
這個報錯與Mysql 密碼安全策略validate_password_policy的值有關,validate_password_policy能夠取0、一、2三個值:
解決辦法:
set global validate_password_policy=0;
set global validate_password_length=1;

4.3  安裝和配置MGR信息

1) 配置全部節點的組複製信息

MGR-node01節點
[root@MGR-node1 ~]# cp /etc/my.cnf /etc/my.cnf.bak
[root@MGR-node1 ~]# >/etc/my.cnf
[root@MGR-node1 ~]# vim /etc/my.cnf
[mysqld]
datadir = /var/lib/mysql
socket = /var/lib/mysql/mysql.sock
        
symbolic-links = 0
        
log-error = /var/log/mysqld.log
pid-file = /var/run/mysqld/mysqld.pid

#複製框架
server_id=1
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_checksum=NONE

log_bin=binlog
log_slave_updates=ON
binlog_format=ROW
master_info_repository=TABLE
relay_log_info_repository=TABLE

#組複製設置
#server必須爲每一個事務收集寫集合,並使用XXHASH64哈希算法將其編碼爲散列
transaction_write_set_extraction=XXHASH64
#告知插件加入或建立組命名,UUID 
loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
#server啓動時不自啓組複製,爲了不每次啓動自動引導具備相同名稱的第二個組,因此設置爲OFF。
loose-group_replication_start_on_boot=off
#告訴插件使用IP地址,端口24901用於接收組中其餘成員轉入鏈接
loose-group_replication_local_address="172.16.60.211:24901"
#啓動組server,種子server,加入組應該鏈接這些的ip和端口;其餘server要加入組得由組成員贊成
loose-group_replication_group_seeds="172.16.60.211:24901,172.16.60.212:24901,172.16.60.213:24901"
loose-group_replication_bootstrap_group=off
report_host=172.16.60.211
report_port=3306

如上配置完成後, 將MGR-node1節點的/etc/my.cnf文件拷貝到其餘兩個節點
[root@MGR-node1 ~]# rsync -e "ssh -p22" -avpgolr /etc/my.cnf root@172.16.60.212:/etc/
[root@MGR-node1 ~]# rsync -e "ssh -p22" -avpgolr /etc/my.cnf root@172.16.60.213:/etc/

3個MGR節點除了server_id、loose-group_replication_local_address、report_host 三個參數不同外,其餘保持一致。
因此待拷貝完成後, 分別修改MGR-node2和MGR-node3節點/etc/my.cnf文件的server_id、loose-group_replication_local_address、report_host 三個參數

2) 配置完成後, 要一次啓動數據庫,安裝MGR插件,設置複製帳號(全部MGR節點都要執行)
[root@MGR-node1 ~]# systemctl restart mysqld
[root@MGR-node1 ~]# mysql -p123456
.............
mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';
Query OK, 0 rows affected (0.13 sec)

mysql> SET SQL_LOG_BIN=0;
Query OK, 0 rows affected (0.00 sec)

mysql> CREATE USER repl@'%' IDENTIFIED BY 'repl';
Query OK, 0 rows affected (0.00 sec)

mysql> GRANT REPLICATION SLAVE ON *.* TO repl@'%';
Query OK, 0 rows affected (0.00 sec)

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

mysql> SET SQL_LOG_BIN=1;
Query OK, 0 rows affected (0.00 sec)

mysql> CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='repl' FOR CHANNEL 'group_replication_recovery';
Query OK, 0 rows affected, 2 warnings (0.21 sec)

4.4  啓動MGR單主模式

1) 啓動MGR,在主庫(172.16.60.11)節點上上執行
[root@MGR-node1 ~]# mysql -p123456
...............
mysql> SET GLOBAL group_replication_bootstrap_group=ON;
Query OK, 0 rows affected (0.00 sec)
 
mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (2.31 sec)
 
mysql> SET GLOBAL group_replication_bootstrap_group=OFF;
Query OK, 0 rows affected (0.00 sec)
 
查看MGR組信息
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| group_replication_applier | 8769f936-3e51-11e9-acaa-005056ac6820 | 172.16.60.211 |        3306 | ONLINE       |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
1 row in set (0.01 sec)
 
2) 在其餘節點加入MGR集羣,在從庫(172.16.60.212,172.16.60.213)上執行
[root@MGR-node2 ~]#  mysql -p123456
................
mysql> START GROUP_REPLICATION;
ERROR 3092 (HY000): The server is not configured properly to be an active member of the group. Please see more details on error log.
 
查看日誌:
[root@MGR-node2 ~]# tail -2000 /var/log/mysqld.log
.....................
.....................
2019-03-04T09:11:30.683714Z 0 [ERROR] Plugin group_replication reported: 'This member has more executed transactions than those present in the group. Local transactions: 87135ebb-3e51-11e9-8931-005056880888:1-2 > Group transactions: 851d03bb-3e51-11e9-8f8d-00505688047c:1-2,
8769f936-3e51-11e9-acaa-005056ac6820:1-2,
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-4'
2019-03-04T09:11:30.683817Z 0 [Warning] Plugin group_replication reported: 'The member contains transactions not present in the group. It is only allowed to join due to group_replication_allow_local_disjoint_gtids_join option'
 
解決辦法:
mysql> set global group_replication_allow_local_disjoint_gtids_join=ON;
Query OK, 0 rows affected, 1 warning (0.00 sec)
 
而後再接着加入MGR集羣
mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected, 1 warning (5.14 sec)
 
3) 再次查看MGR組信息 (在三個MGR節點上均可以查看)
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| group_replication_applier | 851d03bb-3e51-11e9-8f8d-00505688047c | 172.16.60.212 |        3306 | RECOVERING   |
| group_replication_applier | 87135ebb-3e51-11e9-8931-005056880888 | 172.16.60.213 |        3306 | RECOVERING   |
| group_replication_applier | 8769f936-3e51-11e9-acaa-005056ac6820 | 172.16.60.211 |        3306 | ONLINE       |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
3 rows in set (0.00 sec)
 
發現新加入的MGR-node2 , MGR-node3兩個節點在集羣裏的狀態是RECOVERING!!!
 
查看日誌
[root@MGR-node3 ~]# tail -2000 /var/log/mysqld.log
.....................
.....................
2019-03-04T09:15:35.146740Z 734 [ERROR] Slave I/O for channel 'group_replication_recovery': Got fatal error 1236 from master when
reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has
purged binary logs containing GTIDs that the slave requires.', Error_code: 1236
 
解決辦法:
登陸主庫172.16.60.211, 查看被purge的GTID:
[root@MGR-node1 ~]#  mysql -p123456
....................
mysql> show global variables like 'gtid_purged';
+---------------+------------------------------------------+
| Variable_name | Value                                    |
+---------------+------------------------------------------+
| gtid_purged   | 8769f936-3e51-11e9-acaa-005056ac6820:1-2 |
+---------------+------------------------------------------+
1 row in set (0.00 sec)
 
接着在兩個從庫172.16.60.212, 172.16.60.213的數據庫上執行下面命令,即跳過這個GTID:
mysql> STOP GROUP_REPLICATION;
Query OK, 0 rows affected (10.14 sec)
 
mysql> reset master;
Query OK, 0 rows affected (0.06 sec)
 
mysql> set global gtid_purged = '8769f936-3e51-11e9-acaa-005056ac6820:1-2';
Query OK, 0 rows affected (0.24 sec)
 
mysql>  START GROUP_REPLICATION;
Query OK, 0 rows affected, 1 warning (3.49 sec)
 
再次查看查看MGR組信息 (在三個MGR節點上均可以查看),
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| group_replication_applier | 851d03bb-3e51-11e9-8f8d-00505688047c | 172.16.60.212 |        3306 | ONLINE       |
| group_replication_applier | 87135ebb-3e51-11e9-8931-005056880888 | 172.16.60.213 |        3306 | ONLINE       |
| group_replication_applier | 8769f936-3e51-11e9-acaa-005056ac6820 | 172.16.60.211 |        3306 | ONLINE       |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
3 rows in set (0.00 sec)
 
經過上面能夠看出:  三個MGR節點狀態爲online,而且主節點爲172.16.60.211,只有主節點能夠寫入,其餘兩個MGR節點只讀,MGR單主模式搭建成功。

==============================================================================
驗證下MGR單主模式下節點數據的同步以及讀寫操做:
先在主庫節點172.16.60.211上建立測試數據庫
[root@MGR-node1 ~]# mysql -p123456
..............
mysql> CREATE DATABASE kevin CHARACTER SET utf8 COLLATE utf8_general_ci;   
Query OK, 1 row affected (0.06 sec)

mysql> use kevin;
Database changed
mysql> create table if not exists haha (id int(10) PRIMARY KEY AUTO_INCREMENT,name varchar(50) NOT NULL);
Query OK, 0 rows affected (0.24 sec)

mysql> insert into kevin.haha values(1,"wangshibo"),(2,"guohuihui"),(3,"yangyang"),(4,"shikui"); 
Query OK, 4 rows affected (0.13 sec)
Records: 4  Duplicates: 0  Warnings: 0

mysql> select * from kevin.haha;
+----+-----------+
| id | name      |
+----+-----------+
|  1 | wangshibo |
|  2 | guohuihui |
|  3 | yangyang  |
|  4 | shikui    |
+----+-----------+
4 rows in set (0.00 sec)

接着在其餘的兩個從節點172.16.60.212和172.16.60.213上查看數據, 發現主庫數據已經同步到兩個從庫上了
[root@MGR-node2 ~]# mysql -p123456
..................
mysql> select * from kevin.haha;
+----+-----------+
| id | name      |
+----+-----------+
|  1 | wangshibo |
|  2 | guohuihui |
|  3 | yangyang  |
|  4 | shikui    |
+----+-----------+
4 rows in set (0.00 sec)

而後嘗試在兩個從庫上更新數據, 發現更新失敗! 由於這是MGR單主模式, 從庫只能進行讀操做, 不能進行寫操做!
[root@MGR-node3 ~]# mysql -p123456
.................
mysql> select * from kevin.haha;
+----+-----------+
| id | name      |
+----+-----------+
|  1 | wangshibo |
|  2 | guohuihui |
|  3 | yangyang  |
|  4 | shikui    |
+----+-----------+
4 rows in set (0.00 sec)

mysql> delete from kevin.haha where id>3;
ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement
mysql> insert into kevin.haha values(11,"beijing"),(12,"shanghai"),(13,"anhui");
ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement

只有在主庫上才能進行寫操做
[root@MGR-node1 ~]# mysql -p123456
..............
mysql> insert into kevin.haha values(11,"beijing"),(12,"shanghai"),(13,"anhui");
Query OK, 3 rows affected (0.15 sec)
Records: 3  Duplicates: 0  Warnings: 0

mysql> select * from kevin.haha;
+----+-----------+
| id | name      |
+----+-----------+
|  1 | wangshibo |
|  2 | guohuihui |
|  3 | yangyang  |
|  4 | shikui    |
| 11 | beijing   |
| 12 | shanghai  |
| 13 | anhui     |
+----+-----------+
7 rows in set (0.00 sec)

4.5 切換到多主模式
MGR切換模式須要從新啓動組複製,因些須要在全部節點上先關閉組複製,設置 group_replication_single_primary_mode=OFF 等參數,再啓動組複製。

1) 中止組複製(在全部MGR節點上執行):
mysql> stop group_replication;
Query OK, 0 rows affected (9.08 sec)

mysql> set global group_replication_single_primary_mode=OFF;
Query OK, 0 rows affected (0.00 sec)

mysql> set global group_replication_enforce_update_everywhere_checks=ON;
Query OK, 0 rows affected (0.00 sec)

2) 隨便選擇某個MGR節點執行 (好比這裏選擇在MGR-node1節點):
[root@MGR-node1 ~]# mysql -p123456
...............
mysql> SET GLOBAL group_replication_bootstrap_group=ON; 
Query OK, 0 rows affected (0.00 sec)

mysql> START GROUP_REPLICATION; 
Query OK, 0 rows affected (2.20 sec)

mysql> SET GLOBAL group_replication_bootstrap_group=OFF;
Query OK, 0 rows affected (0.00 sec)

3) 而後在其餘的MGR節點執行 (這裏指MGR-node2和MGR-node3節點上執行):
mysql> START GROUP_REPLICATION; 
Query OK, 0 rows affected, 1 warning (5.89 sec)

4) 查看MGR組信息 (在任意一個MGR節點上均可以查看)
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| group_replication_applier | 851d03bb-3e51-11e9-8f8d-00505688047c | 172.16.60.212 |        3306 | ONLINE       |
| group_replication_applier | 87135ebb-3e51-11e9-8931-005056880888 | 172.16.60.213 |        3306 | ONLINE       |
| group_replication_applier | 8769f936-3e51-11e9-acaa-005056ac6820 | 172.16.60.211 |        3306 | ONLINE       |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
3 rows in set (0.00 sec)

能夠看到全部MGR節點狀態都是online,角色都是PRIMARY,MGR多主模式搭建成功。

=========================================
驗證下MGR多主模式的節點數據同步:
在MGR-node1節點更新數據:
[root@MGR-node1 ~]# mysql -p123456
.................
mysql> select * from kevin.haha;
+----+-----------+
| id | name      |
+----+-----------+
|  1 | wangshibo |
|  2 | guohuihui |
|  3 | yangyang  |
|  4 | shikui    |
| 11 | beijing   |
| 12 | shanghai  |
| 13 | anhui     |
+----+-----------+
7 rows in set (0.00 sec)

mysql> delete from kevin.haha where id>10;
Query OK, 3 rows affected (0.08 sec)

在MGR-node2節點更新數據
[root@MGR-node2 ~]# mysql -p123456
...............
mysql> select * from kevin.haha;
+----+-----------+
| id | name      |
+----+-----------+
|  1 | wangshibo |
|  2 | guohuihui |
|  3 | yangyang  |
|  4 | shikui    |
+----+-----------+
4 rows in set (0.00 sec)

mysql> insert into kevin.haha values(11,"beijing"),(12,"shanghai"),(13,"anhui");
Query OK, 3 rows affected (0.08 sec)
Records: 3  Duplicates: 0  Warnings: 0

在MGR-node3節點更新數據
[root@MGR-node3 ~]# mysql -p123456
.............
mysql> select * from kevin.haha;
+----+-----------+
| id | name      |
+----+-----------+
|  1 | wangshibo |
|  2 | guohuihui |
|  3 | yangyang  |
|  4 | shikui    |
| 11 | beijing   |
| 12 | shanghai  |
| 13 | anhui     |
+----+-----------+
7 rows in set (0.00 sec)

mysql> delete from kevin.haha where id>11;
Query OK, 2 rows affected (0.14 sec)

mysql> select * from kevin.haha;
+----+-----------+
| id | name      |
+----+-----------+
|  1 | wangshibo |
|  2 | guohuihui |
|  3 | yangyang  |
|  4 | shikui    |
| 11 | beijing   |
+----+-----------+
5 rows in set (0.00 sec)

如上, MGR多主模式下, 全部節點均可以進行讀寫操做.

4.6  切回單主模式

1) 中止組複製(在全部MGR節點上執行):
mysql> stop group_replication;
Query OK, 0 rows affected (9.29 sec)

mysql> set global group_replication_enforce_update_everywhere_checks=OFF;
Query OK, 0 rows affected (0.00 sec)

mysql> set global group_replication_single_primary_mode=ON;
Query OK, 0 rows affected (0.00 sec)

2) 選擇一個節點做爲主節點, 在主節點上執行 (這裏選擇MGR-node1節點做爲主節點)
[root@MGR-node1 ~]# mysql -p123456
................
mysql> SET GLOBAL group_replication_bootstrap_group=ON; 
Query OK, 0 rows affected (0.00 sec)

mysql> START GROUP_REPLICATION; 
Query OK, 0 rows affected (2.12 sec)

mysql> SET GLOBAL group_replication_bootstrap_group=OFF;
Query OK, 0 rows affected (0.00 sec)

3) 在其餘剩餘的節點, 也就是從庫節點上執行 (這裏從庫節點指的就是MGR-node2和MGR-node3):
mysql> START GROUP_REPLICATION; 
Query OK, 0 rows affected, 1 warning (6.16 sec)

4) 查看MGR組信息 (在任意一個MGR節點上均可以查看)
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| group_replication_applier | 851d03bb-3e51-11e9-8f8d-00505688047c | 172.16.60.212 |        3306 | ONLINE       |
| group_replication_applier | 87135ebb-3e51-11e9-8931-005056880888 | 172.16.60.213 |        3306 | ONLINE       |
| group_replication_applier | 8769f936-3e51-11e9-acaa-005056ac6820 | 172.16.60.211 |        3306 | ONLINE       |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
3 rows in set (0.00 sec)

這樣就又切回到MGR單主模式了, 其中172.16.60.211是主節點,具備寫權限. 另外兩個節點172.16.60.212和172.16.60.213是從庫節點, 只能讀不能寫.

4.7  故障切換

1) 單主模式
若是主節點掛掉了, 經過選舉程序會從從庫節點中選擇一個做爲主庫節點.  以下模擬故障:

關閉主庫MGR-node1的mysqld服務
[root@MGR-node1 ~]# systemctl stop mysqld

接着在其餘節點上查看MGR組信息. 好比在MGR-node2節點查看 
[root@MGR-node2 ~]# mysql -p123456
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| group_replication_applier | 851d03bb-3e51-11e9-8f8d-00505688047c | 172.16.60.212 |        3306 | ONLINE       |
| group_replication_applier | 87135ebb-3e51-11e9-8931-005056880888 | 172.16.60.213 |        3306 | ONLINE       |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
2 rows in set (0.00 sec)

嘗試在MGR-node2節點更新數據
mysql> select * from kevin.haha;
+----+-----------+
| id | name      |
+----+-----------+
|  1 | wangshibo |
|  2 | guohuihui |
|  3 | yangyang  |
|  4 | shikui    |
| 11 | beijing   |
| 12 | shanghai  |
| 13 | anhui     |
+----+-----------+
7 rows in set (0.00 sec)

mysql> delete from kevin.haha where id>10;
Query OK, 3 rows affected (0.06 sec)

如上, 發如今以前的主庫MGR-node1節點掛掉後, MGR-node2節點能夠進行寫操做了, 說明此時已經選舉MGR-node2節點爲新的主節點了
那麼,MGR-node3節點仍是從節點, 只能讀不能寫
[root@MGR-node3 ~]# mysql -p123456
..............
mysql> select * from kevin.haha;
+----+-----------+
| id | name      |
+----+-----------+
|  1 | wangshibo |
|  2 | guohuihui |
|  3 | yangyang  |
|  4 | shikui    |
+----+-----------+
4 rows in set (0.00 sec)

mysql> insert into kevin.haha values(11,"beijing"),(12,"shanghai"),(13,"anhui");
ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement

而後再恢復MGR-node1節點, 恢復後, 須要手動激活下該節點的組複製功能
[root@MGR-node1 ~]# systemctl start mysqld
[root@MGR-node1 ~]# mysql -p123456
...............
mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (3.15 sec)

mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| group_replication_applier | 851d03bb-3e51-11e9-8f8d-00505688047c | 172.16.60.212 |        3306 | ONLINE       |
| group_replication_applier | 87135ebb-3e51-11e9-8931-005056880888 | 172.16.60.213 |        3306 | ONLINE       |
| group_replication_applier | 8769f936-3e51-11e9-acaa-005056ac6820 | 172.16.60.211 |        3306 | ONLINE       |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
3 rows in set (0.00 sec)

mysql> select * from kevin.haha;
+----+-----------+
| id | name      |
+----+-----------+
|  1 | wangshibo |
|  2 | guohuihui |
|  3 | yangyang  |
|  4 | shikui    |
+----+-----------+
4 rows in set (0.00 sec)

mysql> insert into kevin.haha values(11,"beijing"),(12,"shanghai"),(13,"anhui");
ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement

發現MGR-node1節點恢復後, 則變爲了從庫節點, 只能讀不能寫.

若是從節點掛了, 恢復後, 只須要手動激活下該節點的組複製功能("START GROUP_REPLICATION;"), 
便可正常加入到MGR組複製集羣內並自動同步其餘節點數據.

=============================================================
2)  多主模式
 若是某個節點掛了, 則其餘的節點繼續進行同步. 
 當故障節點恢復後, 只須要手動激活下該節點的組複製功能("START GROUP_REPLICATION;"), 
 便可正常加入到MGR組複製集羣內並自動同步其餘節點數據.

                                                               基於Mysql8.0, 安裝MGR 單主/多主模式的集羣環境                                                            

上面案例是基於Mysql5.7版本的操做記錄, 若是換成Mysql8.0版本, 則稍微有些地方不同.
Mysql8.0版本按照上面的操做, 在實操中沒有出現報錯.
 
Mysql8.0安裝手冊: https://www.cnblogs.com/kevingrace/p/10482469.html
 
查看組信息, 會顯示主從角色: PRIMARY 和 SECONDARY
 
單主模式
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 | 9d9e69cb-3fb2-11e9-9420-005056ac6820 | 172.16.60.211 |        3306 | ONLINE       | PRIMARY     | 8.0.15         |
| group_replication_applier | a5edb094-3fb2-11e9-9ddf-00505688047c | 172.16.60.212 |        3306 | ONLINE       | SECONDARY   | 8.0.15         |
| group_replication_applier | a8e04386-3fb2-11e9-9eb3-005056880888 | 172.16.60.213 |        3306 | ONLINE       | SECONDARY   | 8.0.15         |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+
3 rows in set (0.00 sec)
 
多主模式
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 | 9d9e69cb-3fb2-11e9-9420-005056ac6820 | 172.16.60.211 |        3306 | ONLINE       | PRIMARY     | 8.0.15         |
| group_replication_applier | a5edb094-3fb2-11e9-9ddf-00505688047c | 172.16.60.212 |        3306 | ONLINE       | PRIMARY     | 8.0.15         |
| group_replication_applier | a8e04386-3fb2-11e9-9eb3-005056880888 | 172.16.60.213 |        3306 | ONLINE       | PRIMARY     | 8.0.15         |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+
3 rows in set (0.00 sec)

若是節點發生故障, 在恢復後須要從新加入到MGR集羣裏, 正確的作法是:
先stop組複製, 而後再start組複製! 否則可能會形成加入到集羣后的狀態是"RECOVERING"!

正確的作法: 
mysql> stop GROUP_REPLICATION; 
Query OK, 0 rows affected (8.18 sec)

mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (4.16 sec)

                                                               設置MGR組集羣的白名單網段: 添加節點所在網段                                                           

或者出現報錯:  '[GCS] The member is leaving a group without being on one.'
這是由於沒有設置白名單網段:須要添加節點本身所在網段.
 
在任意一個MGR節點上執行:
[root@MGR-node1 ~]# mysql -p123456
.................
 
# 添加白名單網段
mysql> stop group_replication;
Query OK, 0 rows affected (9.41 sec)
 
mysql> 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";
Query OK, 0 rows affected (0.00 sec)
 
mysql> start group_replication; 
Query OK, 0 rows affected (3.37 sec)
 
mysql> show variables like "group_replication_ip_whitelist";
+--------------------------------+-----------------------------------------------------------+
| Variable_name                  | Value                                                     |
+--------------------------------+-----------------------------------------------------------+
| group_replication_ip_whitelist | 127.0.0.1/32,172.16.60.0/24,172.16.50.0/24,172.16.51.0/24 |
+--------------------------------+-----------------------------------------------------------+
1 row in set (0.01 sec)

group_replication_ip_whitelist = <ip,net,...>  
表示設置白名單,若不配置默認爲AUTOMATIC,自動識別本機網口的私網地址和私網網段,127.0.0.1 鏈接請求始終被容許,
必定要注意: 配置白名單前面必定要先關閉 Group Replication, 及先要執行"stop group_replication;"

也能夠在/etc/my.cnf文件裏配置白名單信息.
相關文章
相關標籤/搜索