乐趣区

关于mysql:6-MGR状态监控-深入浅出MGR

jiezi
  • GreatSQL 社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。

[toc]

MGR 和传统主从复制相似，在运行过程中次要关注各节点的运行状态，以及 Secondary 节点的事务是否有提早。本文介绍如何监控 MGR 节点状态、事务状态等。

1. 节点状态监控

通过查问 performance_schema.replication_group_members 表即可晓得 MGR 各节点的状态：

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 | af39db70-6850-11ec-94c9-00155d064000 | 192.168.6.27 |        4306 | ONLINE       | PRIMARY     | 8.0.25         |
| group_replication_applier | b05c0838-6850-11ec-a06b-00155d064000 | 192.168.6.27 |        4307 | ONLINE       | SECONDARY   | 8.0.25         |
| group_replication_applier | b0f86046-6850-11ec-92fe-00155d064000 | 192.168.6.27 |        4308 | ONLINE       | SECONDARY   | 8.0.25         |
+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+

输入后果中次要几个列的解读如下：

  • MEMBER_ID 列值就是各节点的 server_uuid，用于惟一标识每个节点，在命令行模式下，调用 udf 时传入 MEMBER_ID 以指定各节点。
  • MEMBER_ROLE 示意各节点的角色，如果是 PRIMARY 则示意该节点可承受读写事务，如果是 SECONDARY 则示意该节点只能承受只读事务。如果只有一个节点是 PRIMARY，其余都是 SECONDARY，则示意以后处于 单主模式 ；如果所有节点都是 PRIMARY，则示意以后处于 多主模式。

  • MEMBER_STATE 示意各节点的状态，共有几种状态：ONLINE、RECOVERING、OFFLINE、ERROR、UNREACHABLE 等，上面别离介绍几种状态。

    • ONLINE，示意节点处于失常状态，可提供服务。
    • RECOVERING，示意节点正在进行分布式复原，期待退出集群，这时候有可能正在从 donor 节点利用 clone 复制数据，或者传输 binlog 中。
    • OFFLINE，示意该节点以后处于离线状态。揭示，在正要退出或重退出集群时，可能也会有很短霎时的状态显示为 OFFLINE。
    • ERROR，示意该节点以后处于谬误状态，无奈成为集群的一员。当节点正在进行分布式复原或利用事务时，也是有可能处于这个状态的。当节点处于 ERROR 状态时，是无奈参加集群事务裁决的。节点正在退出或重退出集群时，在实现兼容性查看成为正式 MGR 节点前，可能也会显示为 ERROR 状态。
    • UNREACHABLE，当组通信音讯收发超时时，故障检测机制会将本节点标记为狐疑状态，狐疑其可能无奈和其余节点连贯，例如当某个节点意外断开连接时。当在某个节点上看到其余节点处于 UNREACHABLE 状态时，有可能意味着此时局部节点产生了网络分区，也就是多个节点决裂成两个或多个子集，子集内的节点能够互通，但子集间无奈互通。

当节点的状态不是 ONLINE 时，就该当立刻收回告警并查看产生了什么。

在节点状态发生变化时，或者有节点退出、退出时，表 performance_schema.replication_group_members 的数据都会更新，各节点间会替换和共享这些状态信息，因而能够在任意节点查看。

2. MGR 事务状态监控

另一个须要重点关注的是 Secondary 节点的事务状态，更确切的说是关注待认证事务及待利用事务队列大小。执行上面的 SQL 即可查看，次要关注非 Primary 节点的 COUNT_TRANSACTIONS_IN_QUEUE 和 COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE 这两列的值是否较大：

mysql> SELECT MEMBER_ID AS id, COUNT_TRANSACTIONS_IN_QUEUE AS trx_tobe_verified, COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE AS trx_tobe_applied, COUNT_TRANSACTIONS_CHECKED AS trx_chkd, COUNT_TRANSACTIONS_REMOTE_APPLIED AS trx_done, COUNT_TRANSACTIONS_LOCAL_PROPOSED AS proposed FROM performance_schema.replication_group_member_stats;
+--------------------------------------+-------------------+------------------+----------+----------+----------+
| id                                   | trx_tobe_verified | trx_tobe_applied | trx_chkd | trx_done | proposed |
+--------------------------------------+-------------------+------------------+----------+----------+----------+
| 4ebd3504-11d9-11ec-8f92-70b5e873a570 |                 0 |                0 |   422248 |        6 |   422248 |
| 549b92bf-11d9-11ec-88e1-70b5e873a570 |                 0 |           238391 |   422079 |   183692 |        0 |
| 5596116c-11d9-11ec-8624-70b5e873a570 |              2936 |           238519 |   422115 |   183598 |        0 |
| ed5fe7ba-37c2-11ec-8e12-70b5e873a570 |              2976 |           238123 |   422167 |   184044 |        0 |
+--------------------------------------+-------------------+------------------+----------+----------+----------+

其中，COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE 的值示意期待被 apply 的事务队列大小，COUNT_TRANSACTIONS_IN_QUEUE 示意期待被认证的事务队列大小，这二者任何一个值大于 0，都示意以后有肯定水平的提早。

还能够通过关注上述两个数值的变动，看看两个队列是在逐渐加大还是放大，据此判断 Primary 节点是否 ” 跑得太快 ” 了，或者 Secondary 节点是否 ” 跑得太慢 ”。

多提一下，在启用流控（flow control）时，上述两个值超过相应的阈值时（group_replication_flow_control_applier_threshold 和 group_replication_flow_control_certifier_threshold 默认阈值都是 25000），就会触发流控机制。

3. 其余监控

另外，也能够查看接管到的事务和已执行完的事务之间的差距来判断：

mysql> SELECT RECEIVED_TRANSACTION_SET FROM performance_schema.replication_connection_status WHERE  channel_name = 'group_replication_applier' UNION ALL SELECT variable_value FROM performance_schema.global_variables WHERE  variable_name = 'gtid_executed'\G
*************************** 1. row ***************************
RECEIVED_TRANSACTION_SET: 6cfb873b-573f-11ec-814a-d08e7908bcb1:1-3124520
*************************** 2. row ***************************
RECEIVED_TRANSACTION_SET: 6cfb873b-573f-11ec-814a-d08e7908bcb1:1-3078139

能够看到，接管到的事务 GTID 曾经到了 3124520，而本地只执行到 3078139，二者的差距是 46381。

能够顺便继续关注这个差值的变动状况，估算出本地节点是否能及时追平提早，还是会加大提早。

另外，当原来的主节点产生故障，想要手动抉择某个节点做为新的主节点时，也应该先判断哪个节点已执行的事务 GTID 值更大，应优先选择该节点。

4. 小结

本文介绍了 MGR 监控的次要关注点，包含节点状态以及复制提早状态，以及如何预判复制提早会持续扩充还是能及时追上的办法。

参考资料、文档

  • MySQL 8.0 Reference Manual
  • 数据库内核开发 – 温正湖
  • Group Replication 原理 – 宋利兵

免责申明

因集体程度无限，专栏中不免存在错漏之处，请勿间接复制文档中的命令、办法间接利用于线上生产环境。请读者们务必先充沛了解并在测试环境验证通过前方可正式施行，防止造成生产环境的毁坏或侵害。

Enjoy GreatSQL :)

文章举荐：

GreatSQL 季报（2021.12.26）

https://mp.weixin.qq.com/s/FZ…

技术分享 |sysbench 压测工具用法浅析

https://mp.weixin.qq.com/s/m1…

故障剖析 | linux 磁盘 io 利用率高，剖析的正确姿态

https://mp.weixin.qq.com/s/7c…

技术分享 | 闪回在 MySQL 中的实现和改良

https://mp.weixin.qq.com/s/6j…

万答 #20，索引下推如何进行数据过滤

https://mp.weixin.qq.com/s/pt…

对于 GreatSQL

GreatSQL 是由万里数据库保护的 MySQL 分支，专一于晋升 MGR 可靠性及性能，反对 InnoDB 并行查问个性，是实用于金融级利用的 MySQL 分支版本。

Gitee:

https://gitee.com/GreatSQL/Gr…

GitHub:

https://github.com/GreatSQL/G…

Bilibili：

https://space.bilibili.com/13…

微信 &QQ 群：

可搜寻增加 GreatSQL 社区助手微信好友，发送验证信息“加群”退出 GreatSQL/MGR 交换微信群

QQ 群：533341697

微信小助手：wanlidbc

本文由博客一文多发平台 OpenWrite 公布！

退出移动版