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的流控措施
