https://dev.mysql.com/doc/refman/8.0/en/group-replication-monitoring.html

使用Perfomance Schema来监控MGR

MGR主要添加了这两个表

• performance_schema.replication_group_member_stats
• performance_schema.replication_group_members

关于MGR复制相关的表

• performance_schema.replication_connection_status
• performance_schema.replication_applier_status

MGR创建了两个复制通道

• group_replication_recovery: 主要是分布式恢复阶段的replication changes
• group_replication_applier：主要用作来组group的 incoming changes

18.3.1 Group Replication Server States

如果servers之间协作正常，那么看到的state都是一样的
但是，一旦发生网络分区，或者有server挂掉并脱离group，那么不同信息就会被报告出来
如果一个server离开了这个group，那么它就不能上报其他server的状态信息
如果发生了网络分区，那么仲裁法定人数就缺少，servers之间就不能很好的协作，他们只能猜测其他server的状态并报告为unreachable

• Table 18.1 Server State

字段	描述	组同步
ONLINE	用户可正常连接和执行事务	yes
RECOVERING	正在从donar服务器同步数据	no
OFFLINE	插件已经装载，但是该成员不属于任何组	no
ERROR	无论是recovery阶段，还是应用事务更新，表示遇到错误了	no
UNREACHABLE	失联了	no

重要：一旦实例的状态变成了ERROR，super_read_only 会被设置成on
如果ERROR状态消失，需要人工介入调整super_read_only=OFF

注意：MGR不是强同步的，但是最终会一致的
确切的说：事务会按照相同的顺序发送给这个group的所有成员，但是事务的执行、commit完全由成员自行处理，并不是同步进行的

18.3.2 The replication_group_members Table

performance_schema.replication_group_members 这个表主要用来监控不同成员的状态
表里面的信息会自动更新，如果有新成员的加入或离开
每个成员的元数据信息都是共享的，可以被其他成员随时查到
这个表主要是在比较高的层面来看复制group的一些状态信息，比如：

SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME              | MEMBER_ID                               | MEMBER_HOST  | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 041f26d8-f3f3-11e8-adff-080027337932 | example1     |      3306   | ONLINE       | SECONDARY   | 8.0.13         |
| group_replication_applier | f60a3e10-f3f2-11e8-8258-080027337932 | example2     |      3306   | ONLINE       | PRIMARY     | 8.0.13         |
| group_replication_applier | fc890014-f3f2-11e8-a9fd-080027337932 | example3     |      3306   | ONLINE       | SECONDARY   | 8.0.13         |
+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+

从上面的输出可以看出： 这个组由3个成员组成，每个成员的host、port、server-uuid一清二楚
MEMBER_STATE显示他们都是online状态
MEMBER_ROLE这列显示 有2个secondaries，1个primary，因此这个group是一个single-primary 模式的GR
MEMBER_VERSION这列在某些场景对你非常重要，比如：你需要升级一个group，或者将不同mysql版本的server组合在一起的时候

18.3.3 Replication_group_member_stats

每个组的成员认证和执行事务两步
关于认证和执行事务的一些统计信息对明白applier queue（有多少冲突被发现了，多少事务被check了，哪些事务被commit了 等等）的增长非常有用

performance_schema.replication_group_member_stats 提供了group-level 级别的认证、统计等很多信息
这里面的信息是所有成员共享的，任何成员都能查得到
值得注意的是：刷新远程成员的统计信息是根据 group_replication_flow_control_period选项，所以在本地查的信息可能互相有点延迟，有点差异是正常现象

• Table 18.2 replication_group_member_stats

字段	描述
Channel_name	GR通道的名称
View_id	group的当前view id
Member_id	成员的uuid
Count_transactions_in_queue	需要被检测的冲突事务数量
Count_transactions_checked	已经被检测为冲突的事务数量
Count_conflicts_detected	没有通过冲突检测的事务数量
Count_transactions_rows_validating	冲突检测数据库的大小
Transactions_committed_all_members	所有成员都commit成功的事务集
Last_conflict_free_transaction	The transaction identifier of the last conflict free transaction checked.
Count_transactions_remote_in_applier_queue	有多少远程事务在队列里面需要被执行
Count_transactions_remote_applied	已经被执行过的远程事务数量
Count_transactions_local_proposed	本地产生的需要被其他远程成员执行的事务数量
Count_transactions_local_rollback	本地产生的事务，有多少是发送给其他成员，后面又被自己rollback的事务数量

这些信息对监控MGR非常重要
举个例子：假设这个group中的一个成员延迟了，无法跟上其他成员，那么你会看到queue里面有很多事务
通过以上信息，你可以决定是要移除这个成员，还是延迟在其他成员中处理这些事务来减少这个队列中的事务数量
通过以上信息，也能帮助你决定是否需要开启MGR的流控措施