配置的叢集成員，通訊時會把主機名與ip地址進行對應，最好是在/etc/hosts中設定好，如果沒有設定，則會碰到如下

錯誤：

2018-05-02T13:04:32.437256Z 10 [Note] 'CHANGE MASTER TO FOR CHANNEL 'group_replication_recovery' executed'. Previous state master_host='myserver01', master_port= 24801, master_log_file='', master_log_pos= 4, master_bind=''. New state master_host='myserver01', master_port= 24801, master_log_file='', master_log_pos= 4, master_bind=''.
2018-05-02T13:04:32.449673Z 10 [Note] Plugin group_replication reported: 'Establishing connection to a group replication recovery donor 595937c0-4d9c-11e8-a819-00163e06ea60 at myserver01 port: 24801.'
2018-05-02T13:04:32.450108Z 14 [Warning] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.
2018-05-02T13:04:32.450878Z 14 [ERROR] Slave I/O for channel 'group_replication_recovery': error connecting to master '
 
[email protected]:24801' - retry-time: 60  retries: 1, Error_code: 2005
2018-05-02T13:04:32.450887Z 14 [Note] Slave I/O thread for channel 'group_replication_recovery' killed while connecting to master
2018-05-02T13:04:32.450890Z 14 [Note] Slave I/O thread exiting for channel 'group_replication_recovery', read up to log 'FIRST', position 4
2018-05-02T13:04:32.451012Z 10 [ERROR] Plugin group_replication reported: 'There was an error when connecting to the donor server. Please check that group_replication_recovery channel credentials and all MEMBER_HOST column values of performance_schema.replication_group_members table are correct and DNS resolvable.'
2018-05-02T13:04:32.451020Z 10 [ERROR] Plugin group_replication reported: 'For details please check performance_schema.replication_connection_status table and error log messages of Slave I/O for channel group_replication_recovery.'
2018-05-02T13:04:32.451185Z 10 [Note] Plugin group_replication reported: 'Retrying group recovery connection with another donor. Attempt 3/10'
 

在檢視中會看到狀態一直在recovering：

mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | 29d2ae7b-4de8-11e8-a27e-00163e06ea60 | myserver01  |       24802 | RECOVERING   |
| group_replication_applier | 595937c0-4d9c-11e8-a819-00163e06ea60 | myserver01  |       24801 | ONLINE       |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
2 rows in set (0.00 sec)
 

檢視當前叢集的成員狀態及哪個例項為主節點的方法：

mysql> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | 29d2ae7b-4de8-11e8-a27e-00163e06ea60 | myserver01  |       24802 | ONLINE       |
| group_replication_applier | 2fdfc55d-4de8-11e8-a3af-00163e06ea60 | myserver01  |       24803 | ONLINE       |
| group_replication_applier | 595937c0-4d9c-11e8-a819-00163e06ea60 | myserver01  |       24801 | ONLINE       |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
3 rows in set (0.00 sec)

mysql> show global status like '%group_replication_primary%';
+----------------------------------+--------------------------------------+
| Variable_name                    | Value                                |
+----------------------------------+--------------------------------------+
| group_replication_primary_member | 595937c0-4d9c-11e8-a819-00163e06ea60 |
+----------------------------------+--------------------------------------+
1 row in set (0.01 sec)

檢視當前例項是否有延遲等效能問題（通過佇列深度判斷）的方法：

mysql> select * from performance_schema.replication_group_member_stats\G
*************************** 1. row ***************************
                      CHANNEL_NAME: group_replication_applier
                           VIEW_ID: 15252658123489942:3
                         MEMBER_ID: 2fdfc55d-4de8-11e8-a3af-00163e06ea60
       COUNT_TRANSACTIONS_IN_QUEUE: 0
        COUNT_TRANSACTIONS_CHECKED: 0
          COUNT_CONFLICTS_DETECTED: 0
COUNT_TRANSACTIONS_ROWS_VALIDATING: 0
TRANSACTIONS_COMMITTED_ALL_MEMBERS: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-6
    LAST_CONFLICT_FREE_TRANSACTION: 
1 row in set (0.00 sec)

通過檢視COUNT_TRANSACTIONS_IN_QUEUE的值，可以判斷等待處理的事務數。

在單主模式（預設模式）下，只有主伺服器是讀寫模式，其他機器會被設定為只讀模式，read_only、super_read_only都被設定為ON狀態，也就是設定為超級只讀模式：

mysql> show variables like '%read_only%';
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| innodb_read_only      | OFF   |
| read_only             | ON    |
| super_read_only       | ON    |
| transaction_read_only | OFF   |
| tx_read_only          | OFF   |
+-----------------------+-------+
5 rows in set (0.00 sec)

當節點需要恢復時，可以調整重試的次數與間隔：

mysql> show global variables like '%group_replication_recovery_retry%';
+----------------------------------------+-------+
| Variable_name                          | Value |
+----------------------------------------+-------+
| group_replication_recovery_retry_count | 10    |
+----------------------------------------+-------+
1 row in set (0.00 sec)

mysql> show global variables like '%group_replication_recovery_reconnect%';
+-----------------------------------------------+-------+
| Variable_name                                 | Value |
+-----------------------------------------------+-------+
| group_replication_recovery_reconnect_interval | 60    |
+-----------------------------------------------+-------+
1 row in set (0.01 sec)

區分故障與節點主動退出的區別，如果節點是主動退出叢集的，存活的叢集的節點總數會做調整，這樣退出的節點多不會導致剩下節點數目小於原始規劃數的一半而導致仲裁失敗，節點只讀。我們測試如下的節點自動退出情形，第一步，把節點3退出（stop group_replication或者資料庫正常shutdown）：

mysql> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | 29d2ae7b-4de8-11e8-a27e-00163e06ea60 | myserver01  |       24802 | ONLINE       |
| group_replication_applier | 2fdfc55d-4de8-11e8-a3af-00163e06ea60 | myserver01  |       24803 | ONLINE       |
| group_replication_applier | 595937c0-4d9c-11e8-a819-00163e06ea60 | myserver01  |       24801 | ONLINE       |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
3 rows in set (0.00 sec)

mysql> stop group_replication;
Query OK, 0 rows affected (9.51 sec)

mysql> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | 2fdfc55d-4de8-11e8-a3af-00163e06ea60 | myserver01  |       24803 | OFFLINE      |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
1 row in set (0.00 sec)

可以看到一個有3個節點的叢集，節點3退出看，只能看到自己屬於OFFLINE狀態，這時在其他節點上觀察：

mysql> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | 29d2ae7b-4de8-11e8-a27e-00163e06ea60 | myserver01  |       24802 | ONLINE       |
| group_replication_applier | 595937c0-4d9c-11e8-a819-00163e06ea60 | myserver01  |       24801 | ONLINE       |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
2 rows in set (0.00 sec)

可以看到線上節點資訊上，已經把第3個節點資訊去掉，不影響仲裁。等節點3維護完啟動群組複製功能後，會重新加進來，重新配置叢集成員資訊。

如果時網路，機器故障等情況，成員資訊不會自動調整，成員狀態會處於UNREACHABLE，什麼時候會有ERROR狀態，是已經加入叢集但恢復失敗的情況下會出現。

5.7.20後有個新的引數group_replication_member_weight，單主模式下，當選舉發生時，權重越大優先選擇為新的主機。

5. 7.19後有引數group_replication_transaction_size_limit，指定允許的事務大小，防止過大事務導致組同步失敗，這個值允許設定的最大值為2147483647，2G，好像大於max_allowed_packet的1G，最好設定成小於1G，直接避免超過1G事務導致其他複製失敗的情況。

使用組複製的基礎要求：

1、必須使用innodb引擎，衝突時要回滾，使用其他引擎可能會資料不一致。
2、每個表都要求顯示定義主鍵，用於衝突檢測識別。
3、開啟GTID，通過GTID來追蹤各事務在各機器上的情況 。
4、binlog使用row模式，確保各機器資料的一致性。
5、使用READ COMMITTED的隔離級別來規避Gap Locks。