MySQL组复制MGR(三)-- 组复制监控

如果MySQL启用了性能监控数据库performance_schema,则在搭建组复制的时候会创建2个表:

  • performance_schema.replication_group_members
  • performance_schema.replication_group_member_stats

这些performance_schema里面的表也显示组复制的信息:

  • performance_schema.replication_connection_status
  • performance_schema.replication_applier_status

由复制插件创建的复制通道被命名为:

  • group_replication_recovery:此通道用于与分布式恢复阶段相关的复制更改
  • group_replication_applier:此通道用于来自组的传入更改。

下面主要介绍前2个表。


(1)performance_schema.replication_group_members

该表用于监控MySQL组成员的状态信息

mysql> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
 | CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
 | group_replication_applier | 533fe6ba-bcdf-11ea-9516-000c295111ae | mgr-node1   |        3306 | ONLINE       |
 | group_replication_applier | 5ca45641-bcdd-11ea-918e-000c29fa726d | mgr-node2   |        3306 | ONLINE       |
 | group_replication_applier | 62ad32e3-bcdd-11ea-9bbb-000c2978d7f6 | mgr-node3   |        3306 | ONLINE       |
+---------------------------+--------------------------------------+-------------+-------------+--------------+

这里需要关注组成员的数量已经成员状态(MEMBER_STATE):

状态描述组同步
ONLINE该成员可以作为一个具有所有功能的组成员,客户端可以开始连接执行事务
RECOVERING 该成员正在恢复成为一个活跃的组成员
OFFLINE 插件已加载但成员不属于任何组
ERROR 恢复阶段或者应用更改时出现错误,server就会进入此状态
UNREACHABLE 每当本地故障检测器怀疑给定服务器无法访问时(例如由于非自愿断开连接),它将显示该服务器的状态为UNREACHABLE


(2)performance_schema.replication_group_member_stats

复制组中的每个成员都认证并应用该组接收的事务,该表记录了认证过程相关的信息,如检查了多少事务、发现了多少冲突。

mysql> select * from performance_schema.replication_group_member_stats \G
*************************** 1. row ***************************
                      CHANNEL_NAME: group_replication_applier
                           VIEW_ID: 15956427854145598:3
                         MEMBER_ID: 533fe6ba-bcdf-11ea-9516-000c295111ae
       COUNT_TRANSACTIONS_IN_QUEUE: 0
        COUNT_TRANSACTIONS_CHECKED: 20000
          COUNT_CONFLICTS_DETECTED: 0
COUNT_TRANSACTIONS_ROWS_VALIDATING: 2
TRANSACTIONS_COMMITTED_ALL_MEMBERS: dc04ba77-bcf2-11ea-85bf-000c295111ae:1-276051:1000003-1005707
    LAST_CONFLICT_FREE_TRANSACTION: dc04ba77-bcf2-11ea-85bf-000c295111ae:276051

各个字段的含义:

CHANNEL_NAME: 组复制通道的名称
VIEW_ID:
MEMBER_ID: 成员的id
COUNT_TRANSACTIONS_IN_QUEUE: 队列中等待冲突检测的事务数,冲突检测后,排队等待应用
COUNT_TRANSACTIONS_CHECKED: 已进行冲突检查的事务数量
COUNT_CONFLICTS_DETECTED: 未通过冲突检查的事务数量
COUNT_TRANSACTIONS_ROWS_VALIDATING: 表示冲突检测数据库的当前大小
TRANSACTIONS_COMMITTED_ALL_MEMBERS: 表示在当前视图的成员上成功提交的事务
LAST_CONFLICT_FREE_TRANSACTION: 显示最后一个检查无冲突的事务标识符

这些信息对于组性能监控非常重要,例如,假设组成员之一总是报出大量事务在队列中,这意味着该成员数据存在延迟,不能保持最新。基于这些信息,你可以决定去移除该成员,或者延迟其它节点的事务处理,从而减小排队的影响。



【完】

posted @ 2020-07-25 11:06  gegeman  阅读(1343)  评论(0编辑  收藏  举报