MySQL 8 複製（八）——組複製安裝部署

一、部署單主模式組複製

1. 安裝MGR外掛

2. 準備配置檔案

3. 重啟主庫例項

4. 啟動組複製

5. 向組中新增例項

二、組複製監控

三、容錯示例

1. 一個SECONDARY例項正常shutdown

2. 一個SECONDARY例項異常shutdown

3. PRIMARY例項正常shutdown

4. PRIMARY例項異常shutdown

MGR作為MySQL伺服器的外掛提供，組中的每個伺服器都需要配置和安裝外掛。本文說明配置具有三個伺服器的組複製的詳細步驟，三個獨立的MySQL例項已經安裝好。拓撲結構如圖1所示。

MySQL 8 複製（八）——組複製安裝部署

圖1

MySQL版本為8.0.16，各伺服器對應的IP地址和主機名如下。所有伺服器都要先配置好不同的主機名，並修改/etc/hosts檔案配置域名解析。

S1：172.16.1.125 hdp2

S2：172.16.1.126 hdp3

S3：172.16.1.127 hdp4

一、部署單主模式組複製

單主模式中，規劃hdp2為PRIMARY，hdp3、hdp4為SECONDARY。

1. 安裝MGR外掛

在hdp2的MySQL例項中安裝MGR外掛。

mysql> install plugin group_replication soname 'group_replication.so';

Query OK, 0 rows affected (0.01 sec)

檢查MGR外掛是否安裝。

mysql> show plugins;

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

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

(...)

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

46 rows in set (0.00 sec)

2. 準備配置檔案

hdp2的配置檔案/etc/my.cnf內容如下：

[mysqld]

server_id=1125

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= "172.16.1.125:33061"

group_replication_group_seeds= "172.16.1.125:33061,172.16.1.126:33061,172.16.1.127:33061"

group_replication_bootstrap_group=off

主要引數說明：

組複製資料必須儲存在InnoDB事務儲存引擎中，使用其它儲存引擎可能導致組複製出錯。因此設定disabled_storage_engines禁用其它儲存引擎。

配置transaction_write_set_extraction指示伺服器對於每個事務，必須收集寫集並使用XXHASH64雜湊演算法編碼。從MySQL 8.0.2開始，此設定是預設設定，因此可以省略此行。

配置group_replication_group_name告訴外掛它正在加入或建立的組名為aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa。group_replication_group_name的值必須是有效的UUID。在二進位制日誌中為組複製事件設定GTID時，將在內部使用此UUID。可以使用SELECT UUID()或Linux的uuidgen命令生成UUID。

配置group_replication_start_on_boot指示外掛在伺服器啟動時不自動啟動操作。這在設定組複製時很重要，因為它確保可以在手動啟動外掛之前配置伺服器。配置成員後，可以將group_replication_start_on_boot設定為on，以便在伺服器引導時自動啟動組複製。

配置group_replication_local_address告訴外掛使用網路地址172.16.1.125和埠33061與組中的其它成員進行內部通訊。組複製將此地址用於涉及組通訊引擎（XCom，Paxos變體）的遠端例項的內部成員到成員連線。此埠必須與用於客戶端連線的埠不同，並且不得用於客戶端應用程式。在執行組複製時，必須為組成員之間的內部通訊保留它。

配置group_replication_group_seeds設定組成員的IP和埠，這些成員稱為種子成員。建立連線後，組成員身份資訊將列在performance_schema.replication_group_members中。通常，group_replication_group_seeds列表包含每個組成員的group_replication_local_address的 ip:port，但這不是強制性的，可以選擇組成員的子集作為種子。啟動該組的伺服器不使用此選項，因為它是初始伺服器，負責引導組。換句話說，引導該組的伺服器上的任何現有資料都是用作下一個加入成員的資料。第二個伺服器上的任何缺失資料都從引導成員上的資料中複製，然後組擴充套件。加入的第三個伺服器可以要求這兩個伺服器中的任何一個作為捐贈者，資料被同步到新成員，然後該組再次擴充套件。後續伺服器在加入時重複此過程。

配置group_replication_bootstrap_group指示外掛是否引導該組。此選項只能在一個伺服器例項上使用，通常是第一次引導組時（或者在整個組關閉並重新備份的情況下）。如果多次引導組，例如當多個伺服器例項設定了此選項時，則可以建立一個人工腦裂的情景，存在兩個具有相同名稱的不同組。

hdp3、hdp4的配置檔案中只有server_id和group_replication_local_address兩個引數值不同，其它配置引數與hdp2相同：

# hdp3：

server_id=1126

group_replication_local_address= "172.16.1.126:33061"

# hdp4：

server_id=1127

group_replication_local_address= "172.16.1.127:33061"

3. 重啟主庫例項

執行下面的命令重啟hdp2的MySQL例項。

mysqladmin -uroot -p123456 shutdown

mysqld_safe --defaults-file=/etc/my.cnf &

4. 啟動組複製

在hdp2上執行以下步驟啟動組複製。組複製使用非同步複製協議實現分散式恢復，在將組成員加入組之前同步資料。分散式恢復過程依賴於名為group_replication_recovery的複製通道，該通道用於將事務從捐贈者轉移到加入該組的成員。因此需要設定具有正確許可權的複製使用者，以便組複製可以建立直接的成員到成員恢復複製通道。

（1）建立複製使用者

create user 'repl'@'%' identified with 'mysql_native_password' by '123456';

grant replication slave on *.* to 'repl'@'%';

（2）配置用於新成員與捐贈者之間非同步複製的複製通道

change master to master_user='repl', master_password='123456' for channel 'group_replication_recovery';

（3）啟動組複製

要啟動該組，需指示伺服器S1引導該組，然後啟動組複製。此載入程式應僅由單個伺服器完成，該伺服器啟動組並且只執行一次。

set global group_replication_bootstrap_group=on;

start group_replication;

set global group_replication_bootstrap_group=off;

（4）確認組複製是否啟動成功

一旦START GROUP_REPLICATION語句返回，該組就已啟動。可以檢查該組現在是否已建立，並且其中包含一個成員：

mysql> select * from performance_schema.replication_group_members;

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

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

| group_replication_applier | 8eed0f5b-6f9b-11e9-94a9-005056a57a4e | hdp2 | 3306 | ONLINE | PRIMARY | 8.0.16 |

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

1 row in set (0.00 sec)

此表中的資訊確認組中的成員具有唯一識別符號8eed0f5b-6f9b-11e9-94a9-005056a57a4e，它是ONLINE並且在hdp2上偵聽埠3306上的客戶端連線。

為了證明伺服器確實在一個組中並且它能夠處理負載，建立一個表並向其新增一些內容。

create database test;

use test;

create table t1(a bigint auto_increment primary key);

組複製環境下要求每個表都需要有主鍵，否則表上的DML會報錯：

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

建立一個能長時間執行的儲存過程。

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 ;

-- 模擬聯機事務

call p1(100000);

5. 向組中新增例項

在上一步儲存過程執行期間執行下面的步驟，聯機向組中新增例項。

（1）從hdp2向hdp3、hdp4聯機複製資料

在hdp2上執行以下命令，可以開兩個終端並行執行。關於xtrabackup的使用細節，參見https://wxy0327.blog.csdn.net/article/details/90081518#3.%20%E8%81%94%E6%9C%BA。

# 複製到hdp3

xtrabackup -uroot -p123456 --socket=/tmp/mysql.sock --no-lock --backup --compress --stream=xbstream --parallel=4 --target-dir=./ | ssh mysql@172.16.1.126 "xbstream -x -C /usr/local/mysql/data/ --decompress"

# 複製到hdp4

xtrabackup -uroot -p123456 --socket=/tmp/mysql.sock --no-lock --backup --compress --stream=xbstream --parallel=4 --target-dir=./ | ssh mysql@172.16.1.127 "xbstream -x -C /usr/local/mysql/data/ --decompress"

（2）在hdp3、hdp4上應用日誌

分別在hdp3、hdp4上執行以下命令：

xtrabackup --prepare --target-dir=/usr/local/mysql/data/

（3）啟動hdp3、hdp4的MySQL例項

分別在hdp3、hdp4上執行以下命令：

mysqld_safe --defaults-file=/etc/my.cnf &

（4）將hdp3、hdp4加入到組中

分別在hdp3、hdp4上執行以下SQL命令：

-- 重置relay log info

reset slave all;

-- 設定複製通道

change master to master_user='repl', master_password='123456' for channel 'group_replication_recovery';

-- 新增到組

start group_replication;

此命令返回後檢視performance_schema.replication_group_members表，MEMBER_STATE開始時的值為RECOVERING，表示新增伺服器正在追趕主庫。當趕上主庫時，MEMBER_STATE值改為ONLINE，最終顯示該組中有三個ONLINE狀態的伺服器。注意，組複製中每個成員執行的事務不是同步的，但最終同步。更確切地說，事務以相同的順序傳遞給所有組成員，但是它們的執行不同步，這意味著在接受提交事務之後，每個成員按照自己的進度提交。

mysql> select * from performance_schema.replication_group_members;

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

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

| group_replication_applier | 5c93a708-a393-11e9-8343-005056a5497f | hdp4 | 3306 | ONLINE | SECONDARY | 8.0.16 |

| group_replication_applier | 5f045152-a393-11e9-8020-005056a50f77 | hdp3 | 3306 | ONLINE | SECONDARY | 8.0.16 |

| group_replication_applier | 8eed0f5b-6f9b-11e9-94a9-005056a57a4e | hdp2 | 3306 | ONLINE | PRIMARY | 8.0.16 |

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

3 rows in set (0.00 sec)

CHANNEL_NAME：通道名稱。組複製外掛建立兩個複製通道。group_replication_recovery用於與分散式恢復階段相關的複製更改。group_replication_applier用於來自組傳入的更改，是應用直接來自組的事務的通道。

MEMBER_ID：組成員例項的server_uuid。

MEMBER_HOST：組成員主機名。如果配置了report_host引數，這裡顯示IP地址。

MEMBER_ROLE：成員角色，主為PRIMARY，從為SECONDARY。

MEMBER_VERSION：成員資料庫例項版本。

MEMBER_STATE：成員狀態，取值和含義如下表所示：

取值

含義

狀態是否在組內同步

ONLINE

表示該成員可正常提供服務

YES

RECOVERING

表示當前成員正在從其它節點恢復資料

YES

OFFLINE

表示組複製外掛已經載入，但是該成員不屬於任何一個複製組

NO

ERROR

表示成員在recovery階段出現錯誤或者從其它節點同步狀態中出現錯誤

NO

UNREACHABLE

成員處於不可達狀態，無法與之進行網路通訊

NO

從上表可以知道，只有ONLINE和RECOVERING兩種狀態會在叢集中得到同步。這個狀態同步是指狀態在所有成員上查詢均能保持一致。對於OFFLINE、ERROR和UNREABLE：

只有在當前OFFLINE成員查詢replication_group_members表才能得到OFFLINE狀態，在其它成員上查詢replication_group_members表，則沒有該成員的狀態，因為OFFLINE成員已經不屬於這個複製組了。

只有在當前ERROR成員查詢replication_group_members表才能得到ERROR狀態，同上面的OFFLINE，在其它成員上查詢也看不到該成員。

假設成員A與B網路通訊失敗，那麼在節點A上查詢replication_group_members表，有可能得到B的狀態為UNREACHABLE。

成員狀態轉移如圖2所示。

MySQL 8 複製（八）——組複製安裝部署

圖2

當一個成員加進一個複製組，其狀態首先變成RECOVERING，表示當前成員正處於叢集恢復階段。這個階段下，成員會選擇叢集中一個成員作為捐贈者（donor），利用傳統的非同步複製做資料恢復。當資料能夠成功追平，成員的狀態將會變成ONLINE，這個過程中透過其他成員也可以看到該節點的狀態，不管是RECOVERING還是最後的ONLINE。

假如該成員在RECOVERING階段出現了異常，如選擇donor進行復制失敗或者在追趕donor資料的過程中失敗，那麼該成員的狀態將會變成ERROR。注意，這時候在其它成員上查詢時，發現該RECOVERING節點已經從組裡面被移除。

另外，如果一個ONLINE成員失去與其它成員的通訊（可能因為成員當機或者網路異常），則該成員在其他成員上面查詢到的狀態將會是UNREACHABLE。如果這個UNREACHABLE成員在規定的超時時間內沒有恢復，那麼成員將會被移除。這個規定的超時時間，取決於叢集失去這個成員後還能不能達到可用狀態。如果失去這個成員叢集仍然可用，那麼這個UNREACHABLE的超時時間很短，幾乎看不到這個狀態。但是，如果失去這個成員後叢集馬上不可用，那麼這個成員將會一直處於UNREACHABLE狀態。

以一個例子來驗證。kill（注意是kill例項而不是正常shutdown例項）hdp4的MySQL例項。

ps -ef | grep mysqld | grep -v grep | awk '{print $2}' | xargs kill -9

透過其它可用成員查詢到，那一kill掉的例項從叢集中被移除了：

mysql> select * from performance_schema.replication_group_members;

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

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

| group_replication_applier | 5f045152-a393-11e9-8020-005056a50f77 | hdp3 | 3306 | ONLINE | SECONDARY | 8.0.16 |

| group_replication_applier | 8eed0f5b-6f9b-11e9-94a9-005056a57a4e | hdp2 | 3306 | ONLINE | PRIMARY | 8.0.16 |

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

2 rows in set (0.00 sec)

接下來再kill掉hdp3的MySQL例項。再次查詢replication_group_members：

mysql> select * from performance_schema.replication_group_members;

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

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

| group_replication_applier | 5f045152-a393-11e9-8020-005056a50f77 | hdp3 | 3306 | UNREACHABLE | SECONDARY | 8.0.16 |

| group_replication_applier | 8eed0f5b-6f9b-11e9-94a9-005056a57a4e | hdp2 | 3306 | ONLINE | PRIMARY | 8.0.16 |

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

2 rows in set (0.00 sec)

這個時候，UNREACHABLE狀態將一直持續。而且此時，叢集不滿足2N + 1，叢集已經不可用（即使有主成員，它也是不可寫的）。恢復組複製步驟：

（1）在hdp2重新建立一個新的複製組

stop group_replication;

set global group_replication_bootstrap_group=on;

start group_replication;

set global group_replication_bootstrap_group=off;

（2）啟動hdp3、hdp4的MySQL例項

mysqld_safe --defaults-file=/etc/my.cnf &

（3）將hdp3、hdp4重新加入新複製組

change master to master_user='repl', master_password='123456' for channel 'group_replication_recovery';

start group_replication;

此時檢視二進位制日誌中的檢視更改事件，可以看到建立過兩個複製組，每新增一個成員，view_id的序號加1。

[mysql@hdp2/usr/local/mysql/data]$mysqlbinlog binlog.000003 | grep view_id

#190711 12:19:17 server id 1125 end_log_pos 3406788 View_change_log_event: view_id=15628187590651916:2

#190711 12:19:17 server id 1125 end_log_pos 6037781 View_change_log_event: view_id=15628187590651916:3

#190711 14:59:01 server id 1125 end_log_pos 21750924 View_change_log_event: view_id=15628283431266410:1

#190711 14:59:01 server id 1125 end_log_pos 21751315 View_change_log_event: view_id=15628283431266410:2

#190711 14:59:01 server id 1125 end_log_pos 21751706 View_change_log_event: view_id=15628283431266410:3

二、組複製監控

與監控傳統主從複製的show slave status不同，組複製監控主要依賴以下幾個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表用於監視作為組成員的不同伺服器例項的狀態。只要檢視更改，就會更新表中的資訊。例如，因新成員加入而動態更改組的配置時。此時，伺服器交換一些後設資料以使其自身同步並繼續一起協作。資訊在作為複製組成員的所有伺服器例項之間共享，因此可以從任何成員查詢有關所有組成員的資訊。此表可用作獲取複製組狀態的高階檢視。

performance_schema.replication_group_member_stats表提供與認證過程相關的組級資訊，以及由複製組的每個成員接收和發起的事務的統計資訊。資訊在作為複製組成員的所有伺服器例項之間共享，因此可以從任何成員查詢有關所有組成員的資訊。重新整理遠端成員的統計資訊由group_replication_flow_control_period配置引數中指定的訊息週期控制（預設值為1秒），因此可能與本地收集的查詢成員的統計資訊略有不同。

CHANNEL_NAME：組複製通道名稱。

VIEW_ID：複製組當前檢視ID。

MEMBER_ID：組成員的server_uuid。

COUNT_TRANSACTIONS_IN_QUEUE：佇列中等待衝突檢測的事務數。一旦事務透過了衝突檢查，它們就會排隊等待應用。

COUNT_TRANSACTIONS_CHECKED：透過沖突檢查的事務數。

COUNT_CONFLICTS_DETECTED：未透過沖突檢測檢查的事務數。

COUNT_TRANSACTIONS_ROWS_VALIDATING：衝突檢查資料庫的大小。

TRANSACTIONS_COMMITTED_ALL_MEMBERS：已在複製組的所有成員上成功提交的事務，顯示為GTID集。這是以固定的時間間隔更新的。

LAST_CONFLICT_FREE_TRANSACTION：最後一次衝突，被釋放的事務識別符號。

COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE：此成員從複製組收到的等待應用的事務數。

COUNT_TRANSACTIONS_REMOTE_APPLIED：此成員從複製組中收到並已應用的事務數。

COUNT_TRANSACTIONS_LOCAL_PROPOSED：源自此成員併傳送給複製組的事務數。

COUNT_TRANSACTIONS_LOCAL_ROLLBACK：源自此成員並被複制組回滾的事務數。

該表欄位對於監視組中連線成員的效能很重要。例如，假設組中的一個成員總是在其佇列中報告與其它成員相比存在大量事務。這意味著該成員存在延遲，並且無法與該組的其它成員保持同步。根據此資訊，可能決定從組中刪除該成員，或者延遲處理該組其它成員上的事務，以減少排隊事務的數量。此資訊還可以幫助決定如何調整組複製外掛的流控制。

performance_schema.replication_connection_status顯示有關組複製的資訊，例如已從組接收並在應用程式佇列（中繼日誌）中排隊的事務。performance_schema.replication_applier_status顯示與組複製相關的通道和執行緒的狀態。如果有許多不同的工作執行緒應用事務，那麼該表也可用於監視每個工作執行緒正在執行的操作。

performance_schema.replication_connection_status表欄位含義如下：

CHANNEL_NAME：組複製通道名稱。始終存在預設複製通道，可以新增更多複製通道。

GROUP_NAME：如果此伺服器是組的成員，則顯示伺服器所屬的組的名稱。

SOURCE_UUID：組識別符號。

THREAD_ID：I/O執行緒ID。

SERVICE_STATE：ON表示執行緒存在且處於活動狀態或空閒狀態，OFF表示執行緒不再存在，CONNECTING表示執行緒存在並連線到主伺服器。

COUNT_RECEIVED_HEARTBEATS：成員自上次重啟、重置、或者發出了CHANGE MASTER TO語句後，收到的心跳訊號總數。

LAST_HEARTBEAT_TIMESTAMP：成員收到最新心跳訊號的時間戳。

RECEIVED_TRANSACTION_SET：已經被接收的GTID集。

LAST_ERROR_NUMBER：導致I/O執行緒停止的最新錯誤的錯誤號，0表示無錯誤。RESET MASTER或RESET SLAVE將重置該列中顯示的值。

LAST_ERROR_MESSAGE：導致I/O執行緒停止的最新錯誤的錯誤訊息，空字串表示無錯誤。RESET MASTER或RESET SLAVE將重置該列中顯示的值。

LAST_ERROR_TIMESTAMP：最近發生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：當複製通道的應用程式執行緒處於活動狀態或空閒狀態時顯示ON，OFF表示應用程式執行緒未處於活動狀態。

REMAINING_DELAY：延遲複製時則此欄位指示剩餘的延遲秒數，其它情況此欄位為NULL。

COUNT_TRANSACTIONS_RETRIES：顯示由於SQL執行緒無法應用事務而進行的重試次數。給定事務的最大重試次數由slave_transaction_retries系統變數設定。replication_applier_status_by_worker表顯示有關單執行緒或多執行緒從庫的事務重試的詳細資訊。

三、容錯示例

以三成員為例，驗證以下場景下對整個叢集的影響：

一個SECONDARY例項正常shutdown。

一個SECONDARY例項異常shutdown。

PRIMARY例項正常shutdown。

PRIMARY例項異常shutdown。

因為只有三個成員，這四種場景均能夠保證最大票數。無法保證最大票數時，如上面例子中三個成員中的兩個異常當機，則整個叢集無法正常讀寫，需要管理員人為介入解決問題。這種情況顯然不屬於容錯的範疇。

1. 一個SECONDARY例項正常shutdown

（1）主庫上執行長時間執行的事務

-- 在hdp2上執行

use test;

truncate table t1;

call p1(100000);

（2）在上一步執行期間停止一個從庫

# 停止hdp4的MySQL例項

mysqladmin -uroot -p123456 shutdown

（3）檢查剩餘組複製成員狀態

在hdp2上檢查複製組成員狀態：

mysql> select * from performance_schema.replication_group_members;

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

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

| group_replication_applier | 5f045152-a393-11e9-8020-005056a50f77 | hdp3 | 3306 | ONLINE | SECONDARY | 8.0.16 |

| group_replication_applier | 8eed0f5b-6f9b-11e9-94a9-005056a57a4e | hdp2 | 3306 | ONLINE | PRIMARY | 8.0.16 |

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

2 rows in set (0.00 sec)

在hdp3檢查複製事務和資料：

mysql> select * from performance_schema.replication_group_member_stats where member_id='5f045152-a393-11e9-8020-005056a50f77'\G

*************************** 1. row ***************************

CHANNEL_NAME: group_replication_applier

VIEW_ID: 15628283431266410:4

MEMBER_ID: 5f045152-a393-11e9-8020-005056a50f77

COUNT_TRANSACTIONS_IN_QUEUE: 0

COUNT_TRANSACTIONS_CHECKED: 29540

COUNT_CONFLICTS_DETECTED: 0

COUNT_TRANSACTIONS_ROWS_VALIDATING: 10221

TRANSACTIONS_COMMITTED_ALL_MEMBERS: 8eed0f5b-6f9b-11e9-94a9-005056a57a4e:1-2,

aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-119329

LAST_CONFLICT_FREE_TRANSACTION: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:129549

COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 1

COUNT_TRANSACTIONS_REMOTE_APPLIED: 29540

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 | 29538 | 29538 |

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

1 row in set (0.00 sec)

可以看到，一個SECONDARY例項正常shutdown，對應用來說只是少了只讀例項。複製組中的剩餘成員狀態依然是ONLINE。主庫正常讀寫，從庫正常複製，並且沒有積壓的事務（COUNT_TRANSACTIONS_IN_QUEUE為0）。

（4）恢復shutdown的例項

啟動hdp4的MySQL例項：

mysqld_safe --defaults-file=/etc/my.cnf &

在hdp4上檢查組複製成員狀態：

mysql> select * from performance_schema.replication_group_members;

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

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

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

1 row in set (0.00 sec)

此時hdp4的狀態為OFFLINE，已經從複製組中被移除。在hdp4檢查複製事務和資料：

mysql> select * from performance_schema.replication_group_member_stats where member_id='5c93a708-a393-11e9-8343-005056a5497f'\G

Empty set (0.00 sec)

mysql> select min(a),max(a),count(*) from test.t1;

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

| min(a) | max(a) | count(*) |

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

| 1 | 2803 | 2803 |

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

1 row in set (0.02 sec)

可以看到，此時performance_schema.replication_group_member_stats表中已經沒有此成員相關的資訊，例項停止時插入了2803條資料。

將hdp4重新加入複製組：

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;

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

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

| group_replication_applier | 5c93a708-a393-11e9-8343-005056a5497f | hdp4 | 3306 | RECOVERING | SECONDARY | 8.0.16 |

| group_replication_applier | 5f045152-a393-11e9-8020-005056a50f77 | hdp3 | 3306 | ONLINE | SECONDARY | 8.0.16 |

| group_replication_applier | 8eed0f5b-6f9b-11e9-94a9-005056a57a4e | hdp2 | 3306 | ONLINE | PRIMARY | 8.0.16 |

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

3 rows in set (0.00 sec)

mysql> select * from performance_schema.replication_group_member_stats where member_id='5c93a708-a393-11e9-8343-005056a5497f'\G

*************************** 1. row ***************************

CHANNEL_NAME: group_replication_applier

VIEW_ID: 15628283431266410:5

MEMBER_ID: 5c93a708-a393-11e9-8343-005056a5497f

COUNT_TRANSACTIONS_IN_QUEUE: 1

COUNT_TRANSACTIONS_CHECKED: 0

COUNT_CONFLICTS_DETECTED: 0

COUNT_TRANSACTIONS_ROWS_VALIDATING: 0

TRANSACTIONS_COMMITTED_ALL_MEMBERS: 8eed0f5b-6f9b-11e9-94a9-005056a57a4e:1-2,

aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-134250

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 | 64545 | 64545 |

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

1 row in set (0.01 sec)

hdp4開始處於RECOVERING狀態，表明它正在追趕組的複製進度，當趕上後，它的狀態將變為ONLINE。由此可見，一個SECONDARY例項正常shutdown基本對複製組沒有影響（就是少了一個讀成員）。當把它重新加入組中，落後的事務自動恢復，直至趕上狀態自動變為ONLINE。

2. 一個SECONDARY例項異常shutdown

（1）主庫上執行長時間執行的事務

-- 在hdp2上執行

use test;

truncate table t1;

call p1(100000);

（2）在上一步執行期間停止一個從庫

# 停止hdp4的MySQL例項

ps -ef | grep mysqld | grep -v grep | awk {'print $2'} | xargs kill -9

（3）檢查剩餘組複製成員狀態

在hdp2上檢查複製組成員狀態：

mysql> select * from performance_schema.replication_group_members;

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

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

| group_replication_applier | 5f045152-a393-11e9-8020-005056a50f77 | hdp3 | 3306 | ONLINE | SECONDARY | 8.0.16 |

| group_replication_applier | 8eed0f5b-6f9b-11e9-94a9-005056a57a4e | hdp2 | 3306 | ONLINE | PRIMARY | 8.0.16 |

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

2 rows in set (0.00 sec)

在hdp3檢查複製事務和資料：

mysql> select * from performance_schema.replication_group_member_stats where member_id='5f045152-a393-11e9-8020-005056a50f77'\G

*************************** 1. row ***************************

CHANNEL_NAME: group_replication_applier

VIEW_ID: 15628283431266410:6

MEMBER_ID: 5f045152-a393-11e9-8020-005056a50f77

COUNT_TRANSACTIONS_IN_QUEUE: 0

COUNT_TRANSACTIONS_CHECKED: 106387

COUNT_CONFLICTS_DETECTED: 0

COUNT_TRANSACTIONS_ROWS_VALIDATING: 6385

TRANSACTIONS_COMMITTED_ALL_MEMBERS: 8eed0f5b-6f9b-11e9-94a9-005056a57a4e:1-2,

aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-200011

LAST_CONFLICT_FREE_TRANSACTION: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:206397

COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 0

COUNT_TRANSACTIONS_REMOTE_APPLIED: 106389

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 | 6385 | 6385 |

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

1 row in set (0.00 sec)

可以看到，一個SECONDARY例項異常shutdown，對複製組的影響與正常shutdown別無二致。

（4）恢復shutdown的例項

啟動hdp4的MySQL例項：

mysqld_safe --defaults-file=/etc/my.cnf &

在hdp4上檢查組複製成員狀態：

mysql> select * from performance_schema.replication_group_members;

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

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

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

1 row in set (0.01 sec)

此時hdp4的狀態為OFFLINE，已經從複製組中被移除。在hdp4檢查複製事務和資料：

mysql> select * from performance_schema.replication_group_member_stats where member_id='5c93a708-a393-11e9-8343-005056a5497f'\G

Empty set (0.00 sec)

mysql> select min(a),max(a),count(*) from test.t1;

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

| min(a) | max(a) | count(*) |

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

| 1 | 1759 | 1759 |

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

1 row in set (0.02 sec)

可以看到，此時performance_schema.replication_group_member_stats表中已經沒有此成員相關的資訊，例項停止時插入了1759條資料。

將hdp4重新加入複製組：

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;

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

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

| group_replication_applier | 5c93a708-a393-11e9-8343-005056a5497f | hdp4 | 3306 | RECOVERING | SECONDARY | 8.0.16 |

| group_replication_applier | 5f045152-a393-11e9-8020-005056a50f77 | hdp3 | 3306 | ONLINE | SECONDARY | 8.0.16 |

| group_replication_applier | 8eed0f5b-6f9b-11e9-94a9-005056a57a4e | hdp2 | 3306 | ONLINE | PRIMARY | 8.0.16 |

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

3 rows in set (0.00 sec)

mysql> select * from performance_schema.replication_group_member_stats where member_id='5c93a708-a393-11e9-8343-005056a5497f'\G

*************************** 1. row ***************************

CHANNEL_NAME: group_replication_applier

VIEW_ID: 15628283431266410:7

MEMBER_ID: 5c93a708-a393-11e9-8343-005056a5497f

COUNT_TRANSACTIONS_IN_QUEUE: 16608

COUNT_TRANSACTIONS_CHECKED: 0

COUNT_CONFLICTS_DETECTED: 0

COUNT_TRANSACTIONS_ROWS_VALIDATING: 0

TRANSACTIONS_COMMITTED_ALL_MEMBERS: 8eed0f5b-6f9b-11e9-94a9-005056a57a4e:1-2,

aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-230667

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 | 38350 | 38350 |

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

1 row in set (0.00 sec)

hdp4正處於RECOVERING狀態，表明它正在追趕組的複製進度，當趕上後，它的狀態將變為ONLINE。由此可見，一個SECONDARY例項的正常shutdown和異常shutdown，對複製組的影響和恢復過程都沒有任何區別。其實就多了一個MySQL例項的恢復過程，這是在重新啟動hdp4時自動進行的，對使用者是完全透明。

3. PRIMARY例項正常shutdown

（1）主庫上執行長時間執行的事務

-- 在hdp2上執行

use test;

truncate table t1;

call p1(100000);

（2）在上一步執行期間停止主庫

# 停止hdp2的MySQL例項

mysqladmin -uroot -p123456 shutdown

（3）檢查剩餘組複製成員狀態

在hdp3、hdp4上檢查複製組成員狀態：

mysql> select * from performance_schema.replication_group_members;

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

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

| group_replication_applier | 5c93a708-a393-11e9-8343-005056a5497f | hdp4 | 3306 | ONLINE | PRIMARY | 8.0.16 |

| group_replication_applier | 5f045152-a393-11e9-8020-005056a50f77 | hdp3 | 3306 | ONLINE | SECONDARY | 8.0.16 |

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

2 rows in set (0.01 sec)

可以看到，當PRIMARY例項正常shutdown，複製組中的剩餘成員狀態依然是ONLINE，並且自動把其中一個SECONDARY（本例中為hdp4）提升為PRIMARY。在hdp3、hdp4上檢查複製事務和資料：

mysql> select * from performance_schema.replication_group_member_stats\G

*************************** 1. row ***************************

CHANNEL_NAME: group_replication_applier

VIEW_ID: 15628283431266410:8

MEMBER_ID: 5c93a708-a393-11e9-8343-005056a5497f

COUNT_TRANSACTIONS_IN_QUEUE: 0

COUNT_TRANSACTIONS_CHECKED: 987

COUNT_CONFLICTS_DETECTED: 0

COUNT_TRANSACTIONS_ROWS_VALIDATING: 1

TRANSACTIONS_COMMITTED_ALL_MEMBERS: 8eed0f5b-6f9b-11e9-94a9-005056a57a4e:1-2,

aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-301000

LAST_CONFLICT_FREE_TRANSACTION: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:301000

COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 0

COUNT_TRANSACTIONS_REMOTE_APPLIED: 987

COUNT_TRANSACTIONS_LOCAL_PROPOSED: 0

COUNT_TRANSACTIONS_LOCAL_ROLLBACK: 0

*************************** 2. row ***************************

CHANNEL_NAME: group_replication_applier

VIEW_ID: 15628283431266410:8

MEMBER_ID: 5f045152-a393-11e9-8020-005056a50f77

COUNT_TRANSACTIONS_IN_QUEUE: 0

COUNT_TRANSACTIONS_CHECKED: 200989

COUNT_CONFLICTS_DETECTED: 0

COUNT_TRANSACTIONS_ROWS_VALIDATING: 1

TRANSACTIONS_COMMITTED_ALL_MEMBERS: 8eed0f5b-6f9b-11e9-94a9-005056a57a4e:1-2,

aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-301000

LAST_CONFLICT_FREE_TRANSACTION: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:301000

COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 0

COUNT_TRANSACTIONS_REMOTE_APPLIED: 200992

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 | 986 | 986 |

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

1 row in set (0.00 sec)

（4）恢復shutdown的例項

啟動hdp2的MySQL例項：

mysqld_safe --defaults-file=/etc/my.cnf &

在hdp2上檢查組複製成員狀態：

mysql> select * from performance_schema.replication_group_members;

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

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

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

1 row in set (0.01 sec)

此時hdp2的狀態為OFFLINE，已經從複製組中被移除。在hdp2檢查複製事務和資料：

mysql> select * from performance_schema.replication_group_member_stats where member_id='8eed0f5b-6f9b-11e9-94a9-005056a57a4e'\G

Empty set (0.00 sec)

mysql> select min(a),max(a),count(*) from test.t1;

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

| min(a) | max(a) | count(*) |

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

| 1 | 986 | 986 |

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

1 row in set (0.01 sec)

可以看到，此時performance_schema.replication_group_member_stats表中已經沒有此成員相關的資訊，例項停止時插入了986條資料。

將hdp2重新加入複製組：

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;

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

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

| group_replication_applier | 5c93a708-a393-11e9-8343-005056a5497f | hdp4 | 3306 | ONLINE | PRIMARY | 8.0.16 |

| group_replication_applier | 5f045152-a393-11e9-8020-005056a50f77 | hdp3 | 3306 | ONLINE | SECONDARY | 8.0.16 |

| group_replication_applier | 8eed0f5b-6f9b-11e9-94a9-005056a57a4e | hdp2 | 3306 | ONLINE | SECONDARY | 8.0.16 |

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

3 rows in set (0.00 sec)

mysql> select * from performance_schema.replication_group_member_stats where member_id='8eed0f5b-6f9b-11e9-94a9-005056a57a4e'\G

*************************** 1. row ***************************

CHANNEL_NAME: group_replication_applier

VIEW_ID: 15628283431266410:9

MEMBER_ID: 8eed0f5b-6f9b-11e9-94a9-005056a57a4e

COUNT_TRANSACTIONS_IN_QUEUE: 0

COUNT_TRANSACTIONS_CHECKED: 0

COUNT_CONFLICTS_DETECTED: 0

COUNT_TRANSACTIONS_ROWS_VALIDATING: 0

TRANSACTIONS_COMMITTED_ALL_MEMBERS: 8eed0f5b-6f9b-11e9-94a9-005056a57a4e:1-2,

aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-301001

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 | 986 | 986 |

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

1 row in set (0.00 sec)

hdp2處於ONLINE狀態，但角色已經變成了SECONDARY。

此時hdp2變為一個只讀成員：

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.00 sec)

而hdp4成為讀寫成員（主庫）：

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，角色變為SECONDARY。這一切都是自動進行的，應用需要做的是重新連線新的PRIMARY例項，以便繼續執行讀寫事務。

4. PRIMARY例項異常shutdown

（1）主庫上執行長時間執行的事務

-- 在hdp4上執行

use test;

truncate table t1;

call p1(100000);

（2）在上一步執行期間停止主庫

# 停止hdp4的MySQL例項

ps -ef | grep mysqld | grep -v grep | awk {'print $2'} | xargs kill -9

（3）檢查剩餘組複製成員狀態

在hdp2、hdp3上檢查複製組成員狀態：

mysql> select * from performance_schema.replication_group_members;

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

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

| group_replication_applier | 5f045152-a393-11e9-8020-005056a50f77 | hdp3 | 3306 | ONLINE | PRIMARY | 8.0.16 |

| group_replication_applier | 8eed0f5b-6f9b-11e9-94a9-005056a57a4e | hdp2 | 3306 | ONLINE | SECONDARY | 8.0.16 |

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

2 rows in set (0.01 sec)

可以看到，情況與PRIMARY例項正常shutdown一樣，複製組中的剩餘成員狀態依然是ONLINE，並且自動把其中一個SECONDARY（本例中為hdp3）提升為PRIMARY。在hdp2、hdp3上檢查複製事務和資料：

mysql> select * from performance_schema.replication_group_member_stats\G

*************************** 1. row ***************************

CHANNEL_NAME: group_replication_applier

VIEW_ID: 15628283431266410:10

MEMBER_ID: 5f045152-a393-11e9-8020-005056a50f77

COUNT_TRANSACTIONS_IN_QUEUE: 0

COUNT_TRANSACTIONS_CHECKED: 1227

COUNT_CONFLICTS_DETECTED: 0

COUNT_TRANSACTIONS_ROWS_VALIDATING: 1

TRANSACTIONS_COMMITTED_ALL_MEMBERS: 8eed0f5b-6f9b-11e9-94a9-005056a57a4e:1-2,

aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-303809

LAST_CONFLICT_FREE_TRANSACTION: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:303809

COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 0

COUNT_TRANSACTIONS_REMOTE_APPLIED: 1227

COUNT_TRANSACTIONS_LOCAL_PROPOSED: 0

COUNT_TRANSACTIONS_LOCAL_ROLLBACK: 0

*************************** 2. row ***************************

CHANNEL_NAME: group_replication_applier

VIEW_ID: 15628283431266410:10

MEMBER_ID: 8eed0f5b-6f9b-11e9-94a9-005056a57a4e

COUNT_TRANSACTIONS_IN_QUEUE: 0

COUNT_TRANSACTIONS_CHECKED: 2806

COUNT_CONFLICTS_DETECTED: 0

COUNT_TRANSACTIONS_ROWS_VALIDATING: 1

TRANSACTIONS_COMMITTED_ALL_MEMBERS: 8eed0f5b-6f9b-11e9-94a9-005056a57a4e:1-2,

aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-303809

LAST_CONFLICT_FREE_TRANSACTION: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:303809

COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 0

COUNT_TRANSACTIONS_REMOTE_APPLIED: 2808

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 | 1226 | 1226 |

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

1 row in set (0.00 sec)

（4）恢復shutdown的例項

啟動hdp4的MySQL例項：

mysqld_safe --defaults-file=/etc/my.cnf &

在hdp4上檢查組複製成員狀態：

mysql> select * from performance_schema.replication_group_members;

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

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

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

1 row in set (0.00 sec)

此時hdp4的狀態為OFFLINE，已經從複製組中被移除。在hdp4檢查複製事務和資料：

mysql> select * from performance_schema.replication_group_member_stats where member_id='5c93a708-a393-11e9-8343-005056a5497f'\G

Empty set (0.01 sec)

mysql> select min(a),max(a),count(*) from test.t1;

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

| min(a) | max(a) | count(*) |

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

| 1 | 1225 | 1225 |

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

1 row in set (0.01 sec)

可以看到，此時performance_schema.replication_group_member_stats表中已經沒有此成員相關的資訊，例項停止時插入了1225條資料。原PRIMARY比新的PRIMARY還少了一條資料，可見各個例項的提交進度由自己而不是複製組控制。

將hdp4重新加入複製組：

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;

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

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

| group_replication_applier | 5c93a708-a393-11e9-8343-005056a5497f | hdp4 | 3306 | ONLINE | SECONDARY | 8.0.16 |

| group_replication_applier | 5f045152-a393-11e9-8020-005056a50f77 | hdp3 | 3306 | ONLINE | PRIMARY | 8.0.16 |

| group_replication_applier | 8eed0f5b-6f9b-11e9-94a9-005056a57a4e | hdp2 | 3306 | ONLINE | SECONDARY | 8.0.16 |

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

3 rows in set (0.00 sec)

mysql> select * from performance_schema.replication_group_member_stats where member_id='5c93a708-a393-11e9-8343-005056a5497f'\G

*************************** 1. row ***************************

CHANNEL_NAME: group_replication_applier

VIEW_ID: 15628283431266410:11

MEMBER_ID: 5c93a708-a393-11e9-8343-005056a5497f

COUNT_TRANSACTIONS_IN_QUEUE: 0

COUNT_TRANSACTIONS_CHECKED: 0

COUNT_CONFLICTS_DETECTED: 0

COUNT_TRANSACTIONS_ROWS_VALIDATING: 1

TRANSACTIONS_COMMITTED_ALL_MEMBERS: 8eed0f5b-6f9b-11e9-94a9-005056a57a4e:1-2,

aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-303809

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 | 1226 | 1226 |

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

1 row in set (0.00 sec)

hdp4處於ONLINE狀態，但角色已經變成了SECONDARY，資料也已經和其它成員一致。PRIMARY例項正常shutdown與異常shutdown，對組複製和應用的影響來說沒有任何區別。最終得出的結論是，只要保證最大票數的例項可用，組複製中成員的資料恢復、主從角色交換等容錯行為是全自動的，應用只要在必要時修改到主庫的連線即可。

————————————————

版權宣告：本文為CSDN博主「wzy0623」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處連結及本宣告。

原文連結：https://blog.csdn.net/wzy0623/article/details/95619837

About Me

........................................................................................................................

● 本文作者：小麥苗，部分內容整理自網路，若有侵權請聯絡小麥苗刪除

● 本文在itpub、部落格園、CSDN和個人微 信公眾號（
xiaomaimiaolhr）上有同步更新

● 本文itpub地址：
http://blog.itpub.net/26736162 

● 本文部落格園地址：
http://www.cnblogs.com/lhrbest 

● 本文CSDN地址：
https://blog.csdn.net/lihuarongaini 

● 本文pdf版、個人簡介及小麥苗雲盤地址：
http://blog.itpub.net/26736162/viewspace-1624453/ 

● 資料庫筆試面試題庫及解答：
http://blog.itpub.net/26736162/viewspace-2134706/ 

● DBA寶典今日頭條號地址：
 

........................................................................................................................

● QQ群號：
230161599
、618766405

● 微 信群：可加我微 信，我拉大家進群，非誠勿擾

● 聯絡我請加QQ好友
（
646634621
），註明新增緣由

● 於 2020-02-01 06:00 ~ 2020-02-31 24:00 在西安完成

● 最新修改時間：2020-02-01 06:00 ~ 2020-02-31 24:00

● 文章內容來源於小麥苗的學習筆記，部分整理自網路，若有侵權或不當之處還請諒解

● 版權所有，歡迎分享本文，轉載請保留出處

........................................................................................................................

● 
小麥苗的微店：

● 
小麥苗出版的資料庫類叢書：
http://blog.itpub.net/26736162/viewspace-2142121/

● 
小麥苗OCP、OCM、高可用網路班：
http://blog.itpub.net/26736162/viewspace-2148098/

● 
小麥苗騰訊課堂主頁：
https://lhr.ke.qq.com/

........................................................................................................................
使用

微 信客戶端掃描下面的二維碼來關注小麥苗的微 信公眾號（
xiaomaimiaolhr）及QQ群（DBA寶典）、新增小麥苗微 信，
學習最實用的資料庫技術。 


........................................................................................................................

MySQL 8 複製（八）——組複製安裝部署

MySQL 8 複製（八）——組複製安裝部署

相關文章