MGR的一个简单故障案例
传统的复制
传统的 MySQL 提供了一种简单的源到副本复制方法。源是主要的，并且有一个或多个副本，它们是次要的。源应用事务，提交它们，然后它们稍后（因此异步）发送到副本以重新执行（在基于语句的复制中）或应用（在基于行的复制中）。它是一个无共享系统，默认情况下所有服务器都有数据的完整副本。
主从异步复制：
半同步复制：
不同实例之间的箭头表示服务器之间交换的消息或服务器与客户端应用程序之间交换的消息。
MGR
MySQL Group Replication 建立在这些属性和抽象之上，并实现了多源更新无处不在的复制协议。复制组由多个服务器组成，组中的每个服务器可以随时独立执行事务。但是，所有读写事务只有在获得组批准后才会提交。换句话说，对于任何读写事务，组都需要决定是否提交，因此提交操作不是来自原始服务器的单方面决定。只读事务不需要组内协调并立即提交。
当读写事务准备在原始服务器上提交时，服务器会自动广播写入值（已更改的行）和相应的写入集（已更新行的唯一标识符）。因为交易是通过原子广播发送的，组中的所有服务器要么接收交易，要么都不接收。如果他们收到它，那么他们都以与之前发送的其他交易相同的顺序接收它。因此，所有服务器都以相同的顺序接收同一组交易，并为交易建立全局总顺序。
但是，在不同服务器上并发执行的事务之间可能存在冲突。在称为认证的过程中，通过检查和比较两个不同并发事务的写集来检测此类冲突 . 在认证过程中，冲突检测在行级别进行：如果在不同服务器上执行的两个并发事务更新同一行，则存在冲突。冲突解决过程指出，首先排序的事务在所有服务器上提交，第二个排序的事务中止，因此在原始服务器上回滚并被组中的其他服务器删除。例如，如果 t1 和 t2 在不同站点并发执行，都更改同一行，并且 t2 在 t1 之前排序，则 t2 赢得冲突，t1 回滚。这实际上是分布式首次提交获胜规则。请注意，如果两个事务必然经常发生冲突，
为了应用和外部化经过认证的事务，如果不破坏一致性和有效性，组复制允许服务器偏离约定的事务顺序。Group Replication 是一个最终一致性系统，这意味着一旦传入流量减慢或停止，所有组成员都具有相同的数据内容。当流量在流动时，交易可以以稍微不同的顺序外部化，或者在其他成员之前在某些成员上外部化。例如，在多主模式下，本地事务可能会在认证后立即外部化，尽管尚未应用全局顺序中较早的远程事务。当认证过程确定交易之间没有冲突时，这是允许的。在单主模式下，在主服务器上，并发、无冲突的本地事务有可能以与 Group Replication 同意的全局顺序不同的顺序提交和外部化。在不接受来自客户端的写入的辅助节点上，事务始终以约定的顺序提交和外部化。非冲突的本地事务可能以与 Group Replication 同意的全局顺序不同的顺序提交和外部化。在不接受来自客户端的写入的辅助节点上，事务始终以约定的顺序提交和外部化。非冲突的本地事务可能以与 Group Replication 同意的全局顺序不同的顺序提交和外部化。在不接受来自客户端的写入的辅助节点上，事务始终以约定的顺序提交和外部化。
下图描述了 MySQL Group Replication 协议，通过将其与 MySQL Replication（甚至 MySQL 半同步复制）进行比较，您可以看到一些差异。为了清楚起见，这张图片中缺少一些潜在的共识和 Paxos 相关信息。
在2N+1个节点组成的单主模式组复制集群中，主库上一个事务提交时，会将事务修改记录相关的信息和事务产生的BINLOG事件打包生成一个写集(WRITE SET)，将写集发送给所有节点，并通过至少N个节点投票通过才能事务提交成功。
在事务执行期间，会将：
1、事务操作生成的map event/query event/dml event等写入BINLOG CACHE中(内存)
2、将Write Set写入到Rpl_transaction_write_set_ctx中(内存)
在事务提交时，具体在MYSQL_BIN_LOG::prepare之后但是在MYSQL_BIN_LOG::ordered_commit之前，即事务相关的BINLOG Event还在BINLOG CACHE没有写入到BINLOG FILE前，将BINLOG CACHE中和Rpl_transaction_write_set_ctx中的数据进行处理并写入到transaction_msg中，由gcs_module负责发送transaction_msg到各个节点，等待各节点进行事务认证。
由于transaction_msg中包含BINLOG信息，并在事务认证期间发送给MGR各节点，因此无需等待主节点的BINLOG落盘后再发送给备用节点。
每个MGR群集中的节点上，都存在IO线程和SQL线程，IO线程会解析transaction_msg获取到BINLOG EVENT并保存到RELAY LOG中，再由SQL线程执行重放到辅助节点上。
从MGR复制原理上看，当主节点事务提交时，辅助节点上可能还未重放该事务对应的BINLOG，因此MGR仍属于异步复制。
部署过程（不包括mysql router层）
S1: #用户资格 CREATE USER rpl_user@'%' IDENTIFIED BY 'password123'; GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%'; FLUSH PRIVILEGES; CHANGE MASTER TO MASTER_USER='rpl_user',master_PASSWORD='password123' FOR CHANNEL 'group_replication_recovery'; #引导 SET GLOBAL group_replication_bootstrap_group=ON; START GROUP_REPLICATION; SET GLOBAL group_replication_bootstrap_group=OFF; SELECT * FROM performance_schema.replication_group_members; +---------------------------+--------------------------------------+-------------+-------------+---------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | +---------------------------+--------------------------------------+-------------+-------------+---------------+ | group_replication_applier | ce9be252-2b71-11e6-b8f4-00212844f856 | s1 | 3306 | ONLINE | +—————————————+--------------------------------------+-------------+-------------+---------------+ S2/S3/S4/…: SET SQL_LOG_BIN=0; CREATE USER rpl_user@'%' IDENTIFIED BY 'password123'; GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%'; SET SQL_LOG_BIN=1; CHANGE MASTER TO MASTER_USER='rpl_user',master_PASSWORD='password123' FOR CHANNEL 'group_replication_recovery'; CHANGE MASTER TO MASTER_USER='mysql_innodb_cluster_122',master_PASSWORD='Yupei.123' FOR CHANNEL 'group_replication_recovery'; START GROUP_REPLICATION; SELECT * FROM performance_schema.replication_group_members; +---------------------------+--------------------------------------+-------------+-------------+---------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | +---------------------------+--------------------------------------+-------------+-------------+---------------+ | group_replication_applier | 395409e1-6dfa-11e6-970b-00212844f856 | s1 | 3306 | ONLINE | | group_replication_applier | ac39f1e6-6dfa-11e6-a69d-00212844f856 | s2 | 3306 | ONLINE |复制
故障现象
进行检查的时候，3320节点一直处于RECOVERING状态，并且保持一段时间。
mysql> START GROUP_REPLICATION; Query OK, 0 rows affected (3.80 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 | b78dad52-c376-11eb-93d3-000c2902fb88 | 127.0.0.1 | 3320 | RECOVERING | SECONDARY | 8.0.25 | | group_replication_applier | f5c936c4-c374-11eb-a95d-000c2902fb88 | 127.0.0.1 | 3310 | ONLINE | PRIMARY | 8.0.25 | +---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+ 2 rows in set (0.00 sec)复制
通过 performance_schema.replication_connection_status检查状态。
performance_schema.replication_connection_status状态检查
mysql> select * from performance_schema.replication_connection_status\G *************************** 1. row *************************** CHANNEL_NAME: group_replication_applier GROUP_NAME: b2347c8c-c373-11eb-a6bc-e2cf689cd558 SOURCE_UUID: b2347c8c-c373-11eb-a6bc-e2cf689cd558 THREAD_ID: NULL SERVICE_STATE: ON COUNT_RECEIVED_HEARTBEATS: 0 LAST_HEARTBEAT_TIMESTAMP: 0000-00-00 00:00:00.000000 RECEIVED_TRANSACTION_SET: b2347c8c-c373-11eb-a6bc-e2cf689cd558:1-15 LAST_ERROR_NUMBER: 0 LAST_ERROR_MESSAGE: LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000 LAST_QUEUED_TRANSACTION: LAST_QUEUED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000 LAST_QUEUED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000 LAST_QUEUED_TRANSACTION_START_QUEUE_TIMESTAMP: 0000-00-00 00:00:00.000000 LAST_QUEUED_TRANSACTION_END_QUEUE_TIMESTAMP: 0000-00-00 00:00:00.000000 QUEUEING_TRANSACTION: QUEUEING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000 QUEUEING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000 QUEUEING_TRANSACTION_START_QUEUE_TIMESTAMP: 0000-00-00 00:00:00.000000 *************************** 2. row *************************** CHANNEL_NAME: group_replication_recovery GROUP_NAME: SOURCE_UUID: THREAD_ID: NULL SERVICE_STATE: OFF COUNT_RECEIVED_HEARTBEATS: 0 LAST_HEARTBEAT_TIMESTAMP: 0000-00-00 00:00:00.000000 RECEIVED_TRANSACTION_SET: LAST_ERROR_NUMBER: 2061 LAST_ERROR_MESSAGE: error connecting to master 'rpl_user@127.0.0.1:3310' - retry-time: 60 retries: 1 message: Authentication plugin 'caching_sha2_password' reported error: Authentication requires secure connection. LAST_ERROR_TIMESTAMP: 2021-06-02 19:01:10.713689 LAST_QUEUED_TRANSACTION: LAST_QUEUED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000 LAST_QUEUED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000 LAST_QUEUED_TRANSACTION_START_QUEUE_TIMESTAMP: 0000-00-00 00:00:00.000000 LAST_QUEUED_TRANSACTION_END_QUEUE_TIMESTAMP: 0000-00-00 00:00:00.000000 QUEUEING_TRANSACTION: QUEUEING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000 QUEUEING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000 QUEUEING_TRANSACTION_START_QUEUE_TIMESTAMP: 0000-00-00 00:00:00.000000复制
解决方法：
向主库申请公钥： mysql -u rpl_user -h127.0.0.1 -P3310 --get-server-public-key -ppassword123复制
