Contents
  1. 1. 18.3.1 Group Replication Server States
  2. 2. 18.3.2 The replication_group_members Table
  3. 3. 18.3.3 Replication_group_member_stats

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的一些状态信息,比如:

1
2
3
4
5
6
7
8
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的流控措施

Contents
  1. 1. 18.3.1 Group Replication Server States
  2. 2. 18.3.2 The replication_group_members Table
  3. 3. 18.3.3 Replication_group_member_stats

幸福,不在于得到的多

而在于计较的少