備注:測試數(shù)據(jù)庫版本為MySQL 8.0
這個blog我們來聊聊MySQL 組復制
概述
MySQL 是目前最流行的開源關系型數(shù)據(jù)庫，國內(nèi)金融行業(yè)也開始全面使用，其中 MySQL 5.7.17 提出的 MGR（MySQL Group Replication）既可以很好的保證數(shù)據(jù)一致性又可以自動切換，具備故障檢測功能、支持多節(jié)點寫入，MGR 是一項被普遍看好的技術。
MGR（MySQL Group Replication）是 MySQL 自帶的一個插件，可以靈活部署。
MySQL MGR 集群是多個 MySQL Server 節(jié)點共同組成的分布式集群，每個 Server 都有完整的副本，它是基于 ROW 格式的二進制日志文件和 GTID 特性。
MGR架構圖
image.png
MGR拓撲圖
image.png
一.部署單主模式組復制
環(huán)境準備
| 服務器類別 | IP | 數(shù)據(jù)庫版本 |
|---|---|---|
| PRIMARY | 10.31.1.112 | 8.0.20 |
| SECONDARY | 10.31.1.113 | 8.0.20 |
| SECONDARY | 10.31.1.114 | 8.0.20 |
1.1 安裝MGR插件
在10.31.1.112/10.31.1.113/10.31.1.114中安裝mgr插件
-- 安裝mgr插件
mysql> install plugin group_replication soname 'group_replication.so';
Query OK, 0 rows affected (0.14 sec)
-- 檢查mgr插件是否已安裝
mysql> show plugins;
+---------------------------------+--------+--------------------+----------------------+---------+
| Name | Status | Type | Library | License |
+---------------------------------+--------+--------------------+----------------------+---------+
| binlog | ACTIVE | STORAGE ENGINE | NULL | GPL |
********
********
| group_replication | ACTIVE | GROUP REPLICATION | group_replication.so | GPL |
+---------------------------------+--------+--------------------+----------------------+---------+
44 rows in set (0.01 sec)
1.2 準備配置文件
10.31.1.112的配置文件/u01/my3306/my.cnf內(nèi)容如下：
[mysqld]
server_id=1
gtid_mode=ON
enforce-gtid-consistency=true
binlog_checksum=NONE
innodb_buffer_pool_size=4G
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
log_bin=binlog
log_slave_updates=ON
binlog_format=ROW
master_info_repository=TABLE
relay_log_info_repository=TABLE
transaction_write_set_extraction=XXHASH64
group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
group_replication_start_on_boot=off
group_replication_local_address= "10.31.1.112:33061"
group_replication_group_seeds= "10.31.1.112:33061,10.31.1.113:33061,10.31.1.114:33061"
group_replication_bootstrap_group=off
參數(shù)說明
| 參數(shù) | 參數(shù)說明 |
|---|---|
| disabled_storage_engines | 組復制數(shù)據(jù)必須存儲在InnoDB事務存儲引擎中，使用其它存儲引擎可能導致組復制出錯 因此禁用其它的存儲引擎 |
| transaction_write_set_extraction | 指示服務器對于每個事務，必須收集寫集并使用XXHASH64哈希算法編碼。 從MySQL 8.0.2開始，此設置是默認設置，因此可以省略此行。 |
| group_replication_group_name | 告訴插件它正在加入或創(chuàng)建的組名為aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa。 group_replication_group_name的值必須是有效的UUID。 在二進制日志中為組復制事件設置GTID時，將在內(nèi)部使用此UUID。 可以使用SELECT UUID()或Linux的uuidgen命令生成UUID。 |
| group_replication_start_on_boot | 指示插件在服務器啟動時不自動啟動操作。 這在設置組復制時很重要，因為它確保可以在手動啟動插件之前配置服務器。 配置成員后，可以將group_replication_start_on_boot設置為on，以便在服務器引導時自動啟動組復制。 |
| group_replication_local_address | 告訴插件使用網(wǎng)絡地址10.31.1.112和端口3306與組中的其它成員進行內(nèi)部通信。組復制將此地址用于涉及組通信引擎（XCom，Paxos變體）的遠程實例的內(nèi)部成員到成員連接。此端口必須與用于客戶端連接的端口不同，并且不得用于客戶端應用程序。在運行組復制時，必須為組成員之間的內(nèi)部通信保留它。 |
| group_replication_group_seeds | 設置組成員的IP和端口，這些成員稱為種子成員。 建立連接后，組成員身份信息將列在performance_schema.replication_group_members中。 通常，group_replication_group_seeds列表包含每個組成員的group_replication_local_address的 ip:port， 但這不是強制性的，可以選擇組成員的子集作為種子。 啟動該組的服務器不使用此選項，因為它是初始服務器，負責引導組。 換句話說，引導該組的服務器上的任何現(xiàn)有數(shù)據(jù)都是用作下一個加入成員的數(shù)據(jù)。 第二個服務器上的任何缺失數(shù)據(jù)都從引導成員上的數(shù)據(jù)中復制，然后組擴展。 加入的第三個服務器可以要求這兩個服務器中的任何一個作為捐贈者， 數(shù)據(jù)被同步到新成員，然后該組再次擴展。 后續(xù)服務器在加入時重復此過程。 |
| group_replication_bootstrap_group | 指示插件是否引導該組。 此選項只能在一個服務器實例上使用，通常是第一次引導組時（或者在整個組關閉并重新備份的情況下）。 如果多次引導組，例如當多個服務器實例設置了此選項時， 則可以創(chuàng)建一個人工腦裂的情景，存在兩個具有相同名稱的不同組。 |
另外兩臺服務器
10.31.1.113、10.31.1.114的配置文件中只有server_id和group_replication_local_address兩個參數(shù)值不同，其它配置參數(shù)與10.31.1.112相同：
# 10.31.1.113：
server_id=2
group_replication_local_address= "10.31.1.113:33061"
#10.31.1.114：
server_id=3
group_replication_local_address= "10.31.1.114:33061"
1.3重啟mysql服務
mysqladmin -uroot -p -S /u01/my3306/mysql.sock shutdown
/u01/my3306/bin/mysqld_safe --defaults-file=/u01/my3306/my.cnf --user=mysql &
1.4啟動組復制
在10.31.1.112上執(zhí)行以下步驟啟動組復制。組復制使用異步復制協(xié)議實現(xiàn)分布式恢復，在將組成員加入組之前同步數(shù)據(jù)。分布式恢復過程依賴于名為group_replication_recovery的復制通道，該通道用于將事務從捐贈者轉移到加入該組的成員。因此需要設置具有正確權限的復制用戶，以便組復制可以建立直接的成員到成員恢復復制通道。
1.4.1 創(chuàng)建復制用戶
create user 'repl'@'%' identified with 'mysql_native_password' by '123456';
grant replication slave on *.* to 'repl'@'%';
1.4.2 配置用于新成員與捐贈者之間異步復制的復制通道
change master to master_user='repl', master_password='123456' for channel 'group_replication_recovery';
1.4.3 啟動組復制
要啟動該組，需指示服務器S1引導該組，然后啟動組復制。此引導程序應僅由單個服務器完成，該服務器啟動組并且只執(zhí)行一次。
set global group_replication_bootstrap_group=on;
start group_replication;
set global group_replication_bootstrap_group=off;
1.4.4 確認組復制是否啟動成功
一旦START GROUP_REPLICATION語句返回，該組就已啟動?？梢詸z查該組現(xiàn)在是否已創(chuàng)建，并且其中包含一個成員：
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 | c258c587-d22c-11ea-a73e-000c293fa60d | 10.31.1.112 | 3306 | ONLINE | PRIMARY | 8.0.20 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
1 row in set (0.01 sec)
此表中的信息確認組中的成員具有唯一標識符 c258c587-d22c-11ea-a73e-000c293fa60d，它是ONLINE并且在10.31.1.112上偵聽端口3306上的客戶端連接。
1.4.5 向組中添加實例
10.31.1.112運行xtrabackup全備
mkdir -p /backup/mysql/20200731/fulldb
xtrabackup --defaults-file=/u01/my3306/my.cnf --user=root --password=abc123 --port=3306 --backup --target-dir=/backup/mysql/20200731/fulldb
將112備份文件傳輸?shù)?13、114兩臺服務器上
scp -r ./fulldb/ mysql@10.31.1.113:/backup/mysql/20200731/
scp -r ./fulldb/ mysql@10.31.1.114:/backup/mysql/20200731/
在113、114上執(zhí)行如下命令
-- 停止mysql
mysqladmin -uroot -p -S /u01/my3306/mysql.sock shutdown
-- 刪除datadir下的所有文件
cd /u01/my3306/data/
rm -rf *
-- 準備全備份的日志：
xtrabackup --prepare --apply-log-only --target-dir=/backup/mysql/20200731/fulldb
-- 全備份準備
xtrabackup --prepare --target-dir=/backup/mysql/20200731/fulldb
-- 拷回數(shù)據(jù)
xtrabackup -user=root --password=abc123 --port=3306 --datadir=/u01/my3306/data/ --copy-back --target-dir=/backup/mysql/20200731/fulldb/
-- 啟動mysql
/u01/my3306/bin/mysqld_safe --defaults-file=/u01/my3306/my.cnf --user=mysql &
將113、114加入復制組
-- 重置relay log info
reset slave all;
-- 設置復制通道
change master to master_user='repl', master_password='123456' for channel 'group_replication_recovery';
-- 添加到組
start group_replication;
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 | 1e483071-d2f8-11ea-9377-000c297ccd64 | 10.31.1.113 | 3306 | ONLINE | SECONDARY | 8.0.20 |
| group_replication_applier | 4109184b-d2f8-11ea-b1d5-000c295d5891 | 10.31.1.114 | 3306 | ONLINE | SECONDARY | 8.0.20 |
| group_replication_applier | c258c587-d22c-11ea-a73e-000c293fa60d | 10.31.1.112 | 3306 | ONLINE | PRIMARY | 8.0.20 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
3 rows in set (0.01 sec)
參數(shù)說明
| 參數(shù) | 參數(shù)說明 |
|---|---|
| CHANNEL_NAME | 通道名稱。組復制插件創(chuàng)建兩個復制通道。 group_replication_recovery用于與分布式恢復階段相關的復制更改。 group_replication_applier用于來自組傳入的更改，是應用直接來自組的事務的通道。 |
| MEMBER_ID | 組成員實例的server_uuid。 |
| MEMBER_HOST | 組成員主機名。如果配置了report_host參數(shù)，這里顯示IP地址。 |
| MEMBER_ROLE | 成員角色，主為PRIMARY，從為SECONDARY。 |
| MEMBER_VERSION | 成員數(shù)據(jù)庫實例版本。 |
| MEMBER_STATE | 成員狀態(tài)，取值和含義如下表所示： ONLINE：表示該成員可正常提供服務 RECOVERING：表示當前成員正在從其它節(jié)點恢復數(shù)據(jù) OFFLINE： 表示組復制插件已經(jīng)加載，但是該成員不屬于任何一個復制組 ERROR： 表示成員在recovery階段出現(xiàn)錯誤或者從其它節(jié)點同步狀態(tài)中出現(xiàn)錯誤 UNREACHABLE：成員處于不可達狀態(tài)，無法與之進行網(wǎng)絡通訊 |
1.5 UNREACHABLE處理案例
-- 113
ps -ef | grep mysqld | grep -v grep | awk '{print $2}' | xargs kill -9
-- 112上查詢
select * from performance_schema.replication_group_members;
-- 114
ps -ef | grep mysqld | grep -v grep | awk '{print $2}' | xargs kill -9
-- 112上查詢
-- 這個時候，UNREACHABLE狀態(tài)將一直持續(xù)。而且此時，集群不滿足2N + 1，集群已經(jīng)不可用（即使有主成員，它也是不可寫的）
select * from performance_schema.replication_group_members;
[mysql@10.31.1.113 data]$ ps -ef | grep mysqld | grep -v grep | awk '{print $2}' | xargs kill -9
[1]+ Killed /u01/my3306/bin/mysqld_safe --defaults-file=/u01/my3306/my.cnf --user=mysql
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 | 4109184b-d2f8-11ea-b1d5-000c295d5891 | 10.31.1.114 | 3306 | ONLINE | SECONDARY | 8.0.20 |
| group_replication_applier | c258c587-d22c-11ea-a73e-000c293fa60d | 10.31.1.112 | 3306 | ONLINE | PRIMARY | 8.0.20 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
2 rows in set (0.00 sec)
[mysql@10.31.1.114 data]$ ps -ef | grep mysqld | grep -v grep | awk '{print $2}' | xargs kill -9
[1]+ Killed /u01/my3306/bin/mysqld_safe --defaults-file=/u01/my3306/my.cnf --user=mysql
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 | 4109184b-d2f8-11ea-b1d5-000c295d5891 | 10.31.1.114 | 3306 | UNREACHABLE | SECONDARY | 8.0.20 |
| group_replication_applier | c258c587-d22c-11ea-a73e-000c293fa60d | 10.31.1.112 | 3306 | ONLINE | PRIMARY | 8.0.20 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
2 rows in set (0.00 sec)
恢復組復制步驟
1.在112上創(chuàng)建一個新的復制組
stop group_replication;
set global group_replication_bootstrap_group=on;
start group_replication;
set global group_replication_bootstrap_group=off;
2.啟動113、114實例
/u01/my3306/bin/mysqld_safe --defaults-file=/u01/my3306/my.cnf --user=mysql &
3.將113、114重新加入新的復制組
change master to master_user='repl', master_password='123456' for channel 'group_replication_recovery';
start group_replication;
二.組復制監(jiān)控
組復制監(jiān)控依賴performance_schema下幾張表：
performance_schema.replication_group_members
performance_schema.replication_group_member_stats
performance_schema.replication_connection_status
performance_schema.replication_applier_status
performance_schema.replication_group_members表
用于監(jiān)視作為組成員的不同服務器實例的狀態(tài)。只要視圖更改，就會更新表中的信息。例如，因新成員加入而動態(tài)更改組的配置時。此時，服務器交換一些元數(shù)據(jù)以使其自身同步并繼續(xù)一起協(xié)作。信息在作為復制組成員的所有服務器實例之間共享，因此可以從任何成員查詢有關所有組成員的信息。此表可用作獲取復制組狀態(tài)的高級視圖。
performance_schema.replication_group_member_stats表
提供與認證過程相關的組級信息，以及由復制組的每個成員接收和發(fā)起的事務的統(tǒng)計信息。信息在作為復制組成員的所有服務器實例之間共享，因此可以從任何成員查詢有關所有組成員的信息。刷新遠程成員的統(tǒng)計信息由group_replication_flow_control_period配置參數(shù)中指定的消息周期控制（缺省值為1秒），因此可能與本地收集的查詢成員的統(tǒng)計信息略有不同。
| 列 | 列說明 |
|---|---|
| CHANNEL_NAME | 組復制通道名稱。 |
| VIEW_ID | 復制組當前視圖ID。 |
| MEMBER_ID | 組成員的server_uuid。 |
| COUNT_TRANSACTIONS_IN_QUEUE | 隊列中等待沖突檢測的事務數(shù)。一旦事務通過了沖突檢查，它們就會排隊等待應用。 |
| COUNT_TRANSACTIONS_CHECKED | 通過沖突檢查的事務數(shù)。 |
| COUNT_CONFLICTS_DETECTED | 未通過沖突檢測檢查的事務數(shù)。 |
| COUNT_TRANSACTIONS_ROWS_VALIDATING | 沖突檢查數(shù)據(jù)庫的大小。 |
| TRANSACTIONS_COMMITTED_ALL_MEMBERS | 已在復制組的所有成員上成功提交的事務，顯示為GTID集。這是以固定的時間間隔更新的。 |
| LAST_CONFLICT_FREE_TRANSACTION | 最后一次沖突，被釋放的事務標識符。 |
| COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE | 此成員從復制組收到的等待應用的事務數(shù)。 |
| COUNT_TRANSACTIONS_REMOTE_APPLIED | 此成員從復制組中收到并已應用的事務數(shù)。 |
| COUNT_TRANSACTIONS_LOCAL_PROPOSED | 源自此成員并發(fā)送給復制組的事務數(shù)。 |
| COUNT_TRANSACTIONS_LOCAL_ROLLBACK | 源自此成員并被復制組回滾的事務數(shù)。 |
該表字段對于監(jiān)視組中連接成員的性能很重要。例如，假設組中的一個成員總是在其隊列中報告與其它成員相比存在大量事務。這意味著該成員存在延遲，并且無法與該組的其它成員保持同步。根據(jù)此信息，可能決定從組中刪除該成員，或者延遲處理該組其它成員上的事務，以減少排隊事務的數(shù)量。此信息還可以幫助決定如何調整組復制插件的流控制。
performance_schema.replication_connection_status
顯示有關組復制的信息，例如已從組接收并在應用程序隊列（中繼日志）中排隊的事務。performance_schema.replication_applier_status顯示與組復制相關的通道和線程的狀態(tài)。如果有許多不同的工作線程應用事務，那么該表也可用于監(jiān)視每個工作線程正在執(zhí)行的操作。
| 列 | 列說明 |
|---|---|
| CHANNEL_NAME | 組復制通道名稱。始終存在默認復制通道，可以添加更多復制通道。 |
| GROUP_NAME | 如果此服務器是組的成員，則顯示服務器所屬的組的名稱。 |
| SOURCE_UUID | 組標識符。 |
| THREAD_ID | I/O線程ID。 |
| SERVICE_STATE | ON表示線程存在且處于活動狀態(tài)或空閑狀態(tài)，OFF表示線程不再存在，CONNECTING表示線程存在并連接到主服務器。 |
| COUNT_RECEIVED_HEARTBEATS | 成員自上次重啟、重置、或者發(fā)出了CHANGE MASTER TO語句后，收到的心跳信號總數(shù)。 |
| LAST_HEARTBEAT_TIMESTAMP | 成員收到最新心跳信號的時間戳。 |
| RECEIVED_TRANSACTION_SET | 已經(jīng)被接收的GTID集。 |
| LAST_ERROR_NUMBER | 導致I/O線程停止的最新錯誤的錯誤號，0表示無錯誤。RESET MASTER或RESET SLAVE將重置該列中顯示的值。 |
| LAST_ERROR_MESSAGE | 導致I/O線程停止的最新錯誤的錯誤消息，空字符串表示無錯誤。RESET MASTER或RESET SLAVE將重置該列中顯示的值。 |
| LAST_ERROR_TIMESTAMP | 最近發(fā)生I/O錯誤的時間戳。 |
| LAST_QUEUED_TRANSACTION | 排隊到中繼日志的最后一個事務的GTID。 |
| LAST_QUEUED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP | 中繼日志中排隊的最后一個事務在原始主服務器上提交的時間戳。 |
| LAST_QUEUED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP | 中繼日志中排隊的最后一個事務在當前服務器上提交的時間戳。 |
| LAST_QUEUED_TRANSACTION_START_QUEUE_TIMESTAMP | I/O線程將最后一個事務放入中繼日志隊列的時間戳。 |
| LAST_QUEUED_TRANSACTION_END_QUEUE_TIMESTAMP | 最后一個事務排隊到中繼日志文件的時間戳。 |
| QUEUEING_TRANSACTION | 中繼日志中當前排隊事務GTID。 |
| QUEUEING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP | 當前排隊事務在原始主服務器上提交的時間戳。 |
| QUEUEING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP | 當前排隊事務在當前服務器上提交的時間戳。 |
| QUEUEING_TRANSACTION_START_QUEUE_TIMESTAMP | 當前排隊事務的第一個事件何時被I/O線程寫入中繼日志。 |
performance_schema.replication_applier_status表
| 列 | 列說明 |
|---|---|
| CHANNEL_NAME | 組復制通道名稱。始終存在默認復制通道，可以添加更多復制通道。 |
| SERVICE_STATE | 當復制通道的應用程序線程處于活動狀態(tài)或空閑狀態(tài)時顯示ON，OFF表示應用程序線程未處于活動狀態(tài)。 |
| REMAINING_DELAY | 延遲復制時則此字段指示剩余的延遲秒數(shù)，其它情況此字段為NULL。 |
| COUNT_TRANSACTIONS_RETRIES | 顯示由于SQL線程無法應用事務而進行的重試次數(shù)。給定事務的最大重試次數(shù)由slave_transaction_retries系統(tǒng)變量設置。replication_applier_status_by_worker表顯示有關單線程或多線程從庫的事務重試的詳細信息。 |
三.容錯示例
以三成員為例，驗證以下場景下對整個集群的影響：
一個SECONDARY實例正常shutdown。
一個SECONDARY實例異常shutdown。
PRIMARY實例正常shutdown。
PRIMARY實例異常shutdown。
因為只有三個成員，這四種場景均能夠保證最大票數(shù)。無法保證最大票數(shù)時，如上面例子中三個成員中的兩個異常宕機，則整個集群無法正常讀寫，需要管理員人為介入解決問題。這種情況顯然不屬于容錯的范疇。
3.1 一個SECONDARY實例正常shutdown
3.1.1 主庫上執(zhí)行長時間運行的事務
delimiter //
create procedure p1(a int)
begin
? ?declare i int default 1;
? ?while i<=a do
? ? ? insert into t1 select null;
? ? ? set i=i+1;
end while;
end;
//
delimiter ;
-- 在112上執(zhí)行
use test;
truncate table t1;
call p1(100000);
3.1.2 在上一步執(zhí)行期間停止一個從庫
# 停止114的MySQL實例
mysqladmin -uroot -pabc123 shutdown
3.1.3 檢查剩余組復制成員狀態(tài)
-- 在112上執(zhí)行
select * from performance_schema.replication_group_members;
-- 在113上檢查復制事務和數(shù)據(jù)
select * from performance_schema.replication_group_member_stats where member_id='1e483071-d2f8-11ea-9377-000c297ccd64'\G
-- 112運行
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 | 1e483071-d2f8-11ea-9377-000c297ccd64 | 10.31.1.113 | 3306 | ONLINE | SECONDARY | 8.0.20 |
| group_replication_applier | c258c587-d22c-11ea-a73e-000c293fa60d | 10.31.1.112 | 3306 | ONLINE | PRIMARY | 8.0.20 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
2 rows in set (0.00 sec)
-- 113運行
mysql> select * from performance_schema.replication_group_member_stats where member_id='1e483071-d2f8-11ea-9377-000c297ccd64'\G
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
VIEW_ID: 15961790962628600:4
MEMBER_ID: 1e483071-d2f8-11ea-9377-000c297ccd64
COUNT_TRANSACTIONS_IN_QUEUE: 0
COUNT_TRANSACTIONS_CHECKED: 99071
COUNT_CONFLICTS_DETECTED: 0
COUNT_TRANSACTIONS_ROWS_VALIDATING: 28392
TRANSACTIONS_COMMITTED_ALL_MEMBERS: 08260f93-cbe5-11ea-bd0d-000c293fa60d:1-2,
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-370711,
c258c587-d22c-11ea-a73e-000c293fa60d:1-2
LAST_CONFLICT_FREE_TRANSACTION: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:399102
COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 0
COUNT_TRANSACTIONS_REMOTE_APPLIED: 99072
COUNT_TRANSACTIONS_LOCAL_PROPOSED: 0
COUNT_TRANSACTIONS_LOCAL_ROLLBACK: 0
1 row in set (0.01 sec)
可以看到，一個SECONDARY實例正常shutdown，對應用來說只是少了只讀實例。復制組中的剩余成員狀態(tài)依然是ONLINE。主庫正常讀寫，從庫正常復制，并且沒有積壓的事務（COUNT_TRANSACTIONS_IN_QUEUE為0）。
3.1.4 恢復shutdown的實例
-- 114上執(zhí)行
mysqld_safe --defaults-file=/u01/my3306/my.cnf &
114上檢查組復制成員狀態(tài)：
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 | | | NULL | OFFLINE | | |
+---------------------------+-----------+-------------+-------------+--------------+-------------+----------------+
1 row in set (0.00 sec)
此時114的狀態(tài)為OFFLINE，已經(jīng)從復制組中被移除。在114檢查復制事務和數(shù)據(jù)：
mysql> select * from performance_schema.replication_group_member_stats where member_id='4109184b-d2f8-11ea-b1d5-000c295d5891'\G
Empty set (0.00 sec)
mysql> select min(a),max(a),count(*) from test.t1;
+--------+--------+----------+
| min(a) | max(a) | count(*) |
+--------+--------+----------+
| 1 | 5628 | 5628 |
+--------+--------+----------+
1 row in set (0.00 sec)
可以看到，此時performance_schema.replication_group_member_stats表中已經(jīng)沒有此成員相關的信息，實例停止時插入了5628條數(shù)據(jù)。
將114重新加入復制組：
change master to master_user='repl', master_password='123456' for channel 'group_replication_recovery';
start group_replication;
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 | 1e483071-d2f8-11ea-9377-000c297ccd64 | 10.31.1.113 | 3306 | ONLINE | SECONDARY | 8.0.20 |
| group_replication_applier | 4109184b-d2f8-11ea-b1d5-000c295d5891 | 10.31.1.114 | 3306 | RECOVERING | SECONDARY | 8.0.20 |
| group_replication_applier | c258c587-d22c-11ea-a73e-000c293fa60d | 10.31.1.112 | 3306 | ONLINE | PRIMARY | 8.0.20 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
3 rows in set (0.00 sec)
mysql> select * from performance_schema.replication_group_member_stats where member_id='4109184b-d2f8-11ea-b1d5-000c295d5891'\G
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
VIEW_ID: 15961790962628600:5
MEMBER_ID: 4109184b-d2f8-11ea-b1d5-000c295d5891
COUNT_TRANSACTIONS_IN_QUEUE: 1
COUNT_TRANSACTIONS_CHECKED: 0
COUNT_CONFLICTS_DETECTED: 0
COUNT_TRANSACTIONS_ROWS_VALIDATING: 0
TRANSACTIONS_COMMITTED_ALL_MEMBERS:
LAST_CONFLICT_FREE_TRANSACTION:
COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 0
COUNT_TRANSACTIONS_REMOTE_APPLIED: 0
COUNT_TRANSACTIONS_LOCAL_PROPOSED: 0
COUNT_TRANSACTIONS_LOCAL_ROLLBACK: 0
1 row in set (0.00 sec)
114開始處于RECOVERING狀態(tài)，表明它正在追趕組的復制進度，當趕上后，它的狀態(tài)將變?yōu)镺NLINE。由此可見，一個SECONDARY實例正常shutdown基本對復制組沒有影響（就是少了一個讀成員）。當把它重新加入組中，落后的事務自動恢復，直至趕上狀態(tài)自動變?yōu)镺NLINE。
3.2 一個SECONDARY實例異常shutdown
3.2.1 主庫上執(zhí)行長時間運行的事務
-- 在112上執(zhí)行
use test;
truncate table t1;
call p1(100000);
3.2.3 在上一步執(zhí)行期間停止一個從庫
# 停止114的MySQL實例
ps -ef | grep mysqld | grep -v grep | awk {'print $2'} | xargs kill -9
3.2.3 檢查剩余組復制成員狀態(tài)
-- 112上檢查復制組成員狀態(tài)
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 | 1e483071-d2f8-11ea-9377-000c297ccd64 | 10.31.1.113 | 3306 | ONLINE | SECONDARY | 8.0.20 |
| group_replication_applier | c258c587-d22c-11ea-a73e-000c293fa60d | 10.31.1.112 | 3306 | ONLINE | PRIMARY | 8.0.20 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
2 rows in set (0.00 sec)
-- 在113檢查復制事務和數(shù)據(jù)
mysql> select * from performance_schema.replication_group_member_stats where member_id='1e483071-d2f8-11ea-9377-000c297ccd64'\G
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
VIEW_ID: 15961790962628600:6
MEMBER_ID: 1e483071-d2f8-11ea-9377-000c297ccd64
COUNT_TRANSACTIONS_IN_QUEUE: 1
COUNT_TRANSACTIONS_CHECKED: 129976
COUNT_CONFLICTS_DETECTED: 0
COUNT_TRANSACTIONS_ROWS_VALIDATING: 18408
TRANSACTIONS_COMMITTED_ALL_MEMBERS: 08260f93-cbe5-11ea-bd0d-000c293fa60d:1-2,
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-411601,
c258c587-d22c-11ea-a73e-000c293fa60d:1-2
LAST_CONFLICT_FREE_TRANSACTION: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:430008
COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 0
COUNT_TRANSACTIONS_REMOTE_APPLIED: 129977
COUNT_TRANSACTIONS_LOCAL_PROPOSED: 0
COUNT_TRANSACTIONS_LOCAL_ROLLBACK: 0
1 row in set (0.00 sec)
可以看到，一個SECONDARY實例異常shutdown，對復制組的影響與正常shutdown別無二致。
3.2.4 恢復shutdown的實例
-- 啟動114的MySQL實例：
mysqld_safe --defaults-file=/u01/my3306/my.cnf &
在114上檢查組復制成員狀態(tài)：
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 | | | NULL | OFFLINE | | |
+---------------------------+-----------+-------------+-------------+--------------+-------------+----------------+
1 row in set (0.00 sec)
此時114的狀態(tài)為OFFLINE，已經(jīng)從復制組中被移除。 在114檢查復制事務和數(shù)據(jù)：
mysql> select * from performance_schema.replication_group_member_stats where member_id='4109184b-d2f8-11ea-b1d5-000c295d5891'\G
Empty set (0.00 sec)
mysql> select min(a),max(a),count(*) from test.t1;
+--------+--------+----------+
| min(a) | max(a) | count(*) |
+--------+--------+----------+
| 1 | 4491 | 4491 |
+--------+--------+----------+
1 row in set (0.00 sec)
可以看到，此時performance_schema.replication_group_member_stats表中已經(jīng)沒有此成員相關的信息，實例停止時插入了4491條數(shù)據(jù)。
將114重新加入復制組：
change master to master_user='repl', master_password='123456' for channel 'group_replication_recovery';
start group_replication;
再次檢查成員狀態(tài)、復制事務和數(shù)據(jù)：
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 | 1e483071-d2f8-11ea-9377-000c297ccd64 | 10.31.1.113 | 3306 | ONLINE | SECONDARY | 8.0.20 |
| group_replication_applier | 4109184b-d2f8-11ea-b1d5-000c295d5891 | 10.31.1.114 | 3306 | RECOVERING | SECONDARY | 8.0.20 |
| group_replication_applier | c258c587-d22c-11ea-a73e-000c293fa60d | 10.31.1.112 | 3306 | ONLINE | PRIMARY | 8.0.20 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
3 rows in set (0.00 sec)
mysql> select * from performance_schema.replication_group_member_stats where member_id='4109184b-d2f8-11ea-b1d5-000c295d5891'\G
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
VIEW_ID: 15961790962628600:7
MEMBER_ID: 4109184b-d2f8-11ea-b1d5-000c295d5891
COUNT_TRANSACTIONS_IN_QUEUE: 1
COUNT_TRANSACTIONS_CHECKED: 0
COUNT_CONFLICTS_DETECTED: 0
COUNT_TRANSACTIONS_ROWS_VALIDATING: 0
TRANSACTIONS_COMMITTED_ALL_MEMBERS:
LAST_CONFLICT_FREE_TRANSACTION:
COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 0
COUNT_TRANSACTIONS_REMOTE_APPLIED: 0
COUNT_TRANSACTIONS_LOCAL_PROPOSED: 0
COUNT_TRANSACTIONS_LOCAL_ROLLBACK: 0
1 row in set (0.00 sec)
mysql> select min(a),max(a),count(*) from test.t1;
+--------+--------+----------+
| min(a) | max(a) | count(*) |
+--------+--------+----------+
| 1 | 50035 | 50035 |
+--------+--------+----------+
1 row in set (0.03 sec)
114正處于RECOVERING狀態(tài)，表明它正在追趕組的復制進度，當趕上后，它的狀態(tài)將變?yōu)镺NLINE。由此可見，一個SECONDARY實例的正常shutdown和異常shutdown，對復制組的影響和恢復過程都沒有任何區(qū)別。其實就多了一個MySQL實例的恢復過程，這是在重新啟動114時自動進行的，對用戶是完全透明。
3.3 PRIMARY實例正常shutdown
3.3.1 主庫上執(zhí)行長時間運行的事務
-- 在112上執(zhí)行
use test;
truncate table t1;
call p1(100000);
3.3.2 在上一步執(zhí)行期間停止主庫
# 停止112的MySQL實例
mysqladmin -uroot -pabc123 shutdown
3.3.3 檢查剩余組復制成員狀態(tài)
在113、114上檢查復制組成員狀態(tài)：
-- 113執(zhí)行
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 | 1e483071-d2f8-11ea-9377-000c297ccd64 | 10.31.1.113 | 3306 | ONLINE | PRIMARY | 8.0.20 |
| group_replication_applier | 4109184b-d2f8-11ea-b1d5-000c295d5891 | 10.31.1.114 | 3306 | ONLINE | SECONDARY | 8.0.20 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
2 rows in set (0.00 sec)
可以看到，當PRIMARY實例正常shutdown，復制組中的剩余成員狀態(tài)依然是ONLINE，并且自動把其中一個SECONDARY（本例中為113）提升為PRIMARY。在113、114上檢查復制事務和數(shù)據(jù)：
-- 113
mysql> select * from performance_schema.replication_group_member_stats\G
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
VIEW_ID: 15961790962628600:8
MEMBER_ID: 1e483071-d2f8-11ea-9377-000c297ccd64
COUNT_TRANSACTIONS_IN_QUEUE: 0
COUNT_TRANSACTIONS_CHECKED: 208570
COUNT_CONFLICTS_DETECTED: 0
COUNT_TRANSACTIONS_ROWS_VALIDATING: 1
TRANSACTIONS_COMMITTED_ALL_MEMBERS: 08260f93-cbe5-11ea-bd0d-000c293fa60d:1-2,
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-508603,
c258c587-d22c-11ea-a73e-000c293fa60d:1-2
LAST_CONFLICT_FREE_TRANSACTION: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:508603
COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 0
COUNT_TRANSACTIONS_REMOTE_APPLIED: 208573
COUNT_TRANSACTIONS_LOCAL_PROPOSED: 0
COUNT_TRANSACTIONS_LOCAL_ROLLBACK: 0
*************************** 2. row ***************************
CHANNEL_NAME: group_replication_applier
VIEW_ID: 15961790962628600:8
MEMBER_ID: 4109184b-d2f8-11ea-b1d5-000c295d5891
COUNT_TRANSACTIONS_IN_QUEUE: 0
COUNT_TRANSACTIONS_CHECKED: 8568
COUNT_CONFLICTS_DETECTED: 0
COUNT_TRANSACTIONS_ROWS_VALIDATING: 1
TRANSACTIONS_COMMITTED_ALL_MEMBERS: 08260f93-cbe5-11ea-bd0d-000c293fa60d:1-2,
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-508603,
c258c587-d22c-11ea-a73e-000c293fa60d:1-2
LAST_CONFLICT_FREE_TRANSACTION: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:508603
COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 0
COUNT_TRANSACTIONS_REMOTE_APPLIED: 8568
COUNT_TRANSACTIONS_LOCAL_PROPOSED: 0
COUNT_TRANSACTIONS_LOCAL_ROLLBACK: 0
2 rows in set (0.00 sec)
mysql> select min(a),max(a),count(*) from test.t1;
+--------+--------+----------+
| min(a) | max(a) | count(*) |
+--------+--------+----------+
| 1 | 8567 | 8567 |
+--------+--------+----------+
1 row in set (0.01 sec)
-- 114
mysql> select * from performance_schema.replication_group_member_stats\G
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
VIEW_ID: 15961790962628600:8
MEMBER_ID: 1e483071-d2f8-11ea-9377-000c297ccd64
COUNT_TRANSACTIONS_IN_QUEUE: 0
COUNT_TRANSACTIONS_CHECKED: 208570
COUNT_CONFLICTS_DETECTED: 0
COUNT_TRANSACTIONS_ROWS_VALIDATING: 1
TRANSACTIONS_COMMITTED_ALL_MEMBERS: 08260f93-cbe5-11ea-bd0d-000c293fa60d:1-2,
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-508603,
c258c587-d22c-11ea-a73e-000c293fa60d:1-2
LAST_CONFLICT_FREE_TRANSACTION: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:508603
COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 0
COUNT_TRANSACTIONS_REMOTE_APPLIED: 208573
COUNT_TRANSACTIONS_LOCAL_PROPOSED: 0
COUNT_TRANSACTIONS_LOCAL_ROLLBACK: 0
*************************** 2. row ***************************
CHANNEL_NAME: group_replication_applier
VIEW_ID: 15961790962628600:8
MEMBER_ID: 4109184b-d2f8-11ea-b1d5-000c295d5891
COUNT_TRANSACTIONS_IN_QUEUE: 0
COUNT_TRANSACTIONS_CHECKED: 8568
COUNT_CONFLICTS_DETECTED: 0
COUNT_TRANSACTIONS_ROWS_VALIDATING: 1
TRANSACTIONS_COMMITTED_ALL_MEMBERS: 08260f93-cbe5-11ea-bd0d-000c293fa60d:1-2,
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-508603,
c258c587-d22c-11ea-a73e-000c293fa60d:1-2
LAST_CONFLICT_FREE_TRANSACTION: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:508603
COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 0
COUNT_TRANSACTIONS_REMOTE_APPLIED: 8568
COUNT_TRANSACTIONS_LOCAL_PROPOSED: 0
COUNT_TRANSACTIONS_LOCAL_ROLLBACK: 0
2 rows in set (0.00 sec)
mysql> select min(a),max(a),count(*) from test.t1;
+--------+--------+----------+
| min(a) | max(a) | count(*) |
+--------+--------+----------+
| 1 | 8567 | 8567 |
+--------+--------+----------+
1 row in set (0.00 sec)
3.3.4 恢復shutdown的實例
啟動112的MySQL實例：
mysqld_safe --defaults-file=/u01/my3306/my.cnf &
在112上檢查組復制成員狀態(tài)：
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 | | | NULL | OFFLINE | | |
+---------------------------+-----------+-------------+-------------+--------------+-------------+----------------+
1 row in set (0.00 sec)
此時112的狀態(tài)為OFFLINE，已經(jīng)從復制組中被移除。在112檢查復制事務和數(shù)據(jù)：
mysql> select * from performance_schema.replication_group_member_stats where member_id='c258c587-d22c-11ea-a73e-000c293fa60d'\G
Empty set (0.00 sec)
mysql> select min(a),max(a),count(*) from test.t1;
+--------+--------+----------+
| min(a) | max(a) | count(*) |
+--------+--------+----------+
| 1 | 8567 | 8567 |
+--------+--------+----------+
1 row in set (0.01 sec)
可以看到，此時performance_schema.replication_group_member_stats表中已經(jīng)沒有此成員相關的信息，實例停止時插入了8567條數(shù)據(jù)。
將112重新加入復制組：
change master to master_user='repl', master_password='123456' for channel 'group_replication_recovery';
start group_replication;
再次檢查成員狀態(tài)、復制事務和數(shù)據(jù)：
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 | 1e483071-d2f8-11ea-9377-000c297ccd64 | 10.31.1.113 | 3306 | ONLINE | PRIMARY | 8.0.20 |
| group_replication_applier | 4109184b-d2f8-11ea-b1d5-000c295d5891 | 10.31.1.114 | 3306 | ONLINE | SECONDARY | 8.0.20 |
| group_replication_applier | c258c587-d22c-11ea-a73e-000c293fa60d | 10.31.1.112 | 3306 | ONLINE | SECONDARY | 8.0.20 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
3 rows in set (0.00 sec)
mysql> select * from performance_schema.replication_group_member_stats where member_id='c258c587-d22c-11ea-a73e-000c293fa60d'\G
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
VIEW_ID: 15961790962628600:9
MEMBER_ID: c258c587-d22c-11ea-a73e-000c293fa60d
COUNT_TRANSACTIONS_IN_QUEUE: 0
COUNT_TRANSACTIONS_CHECKED: 0
COUNT_CONFLICTS_DETECTED: 0
COUNT_TRANSACTIONS_ROWS_VALIDATING: 1
TRANSACTIONS_COMMITTED_ALL_MEMBERS:
LAST_CONFLICT_FREE_TRANSACTION:
COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 0
COUNT_TRANSACTIONS_REMOTE_APPLIED: 0
COUNT_TRANSACTIONS_LOCAL_PROPOSED: 0
COUNT_TRANSACTIONS_LOCAL_ROLLBACK: 0
1 row in set (0.00 sec)
mysql> select min(a),max(a),count(*) from test.t1;
+--------+--------+----------+
| min(a) | max(a) | count(*) |
+--------+--------+----------+
| 1 | 8567 | 8567 |
+--------+--------+----------+
1 row in set (0.00 sec)
112處于ONLINE狀態(tài)，但角色已經(jīng)變成了SECONDARY。
此時112變?yōu)橐粋€只讀成員：
mysql> show variables like '%read_only%';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| innodb_read_only | OFF |
| read_only | ON |
| super_read_only | ON |
| transaction_read_only | OFF |
+-----------------------+-------+
4 rows in set (0.01 sec)
而113成為讀寫成員（主庫）：
mysql> show variables like '%read_only%';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| innodb_read_only | OFF |
| read_only | OFF |
| super_read_only | OFF |
| transaction_read_only | OFF |
+-----------------------+-------+
4 rows in set (0.01 sec)
由此可見，當PRIMARY實例正常shutdown，組復制會把一個SECONDARY提升為新的PRIMARY。而原來的PRIMARY在重新加入組后立即ONLINE，角色變?yōu)镾ECONDARY。這一切都是自動進行的，應用需要做的是重新連接新的PRIMARY實例，以便繼續(xù)執(zhí)行讀寫事務。
3.4 PRIMARY實例異常shutdown
此處略過，經(jīng)過測試，異常shutdown與 3.3 正常關閉相同。
參考文獻:
1.https://blog.csdn.net/wzy0623/article/details/95619837
2.https://dev.mysql.com/doc/refman/8.0/en/group-replication-configuring-instances.html
