组复制监控 | 全方位认识 MySQL 8.0 Group Replication

Posted 沃趣技术

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了组复制监控 | 全方位认识 MySQL 8.0 Group Replication相关的知识，希望对你有一定的参考价值。

_
_
_

作者  罗小波 · 沃趣科技数据库高级技术专家

出品  沃趣科技


_

假设已启用performance_schema(performance_schema=ON)，那么我们可以使用performance_schema下的表来监控组复制的运行状态。

  • 监控组成员同步事务的状态以及组成员自身的状态表。

    *performance_schema.replication_group_member_stats：记录组成员各自同步数据的状态信息。

    *performance_schema.replication_group_members：记录组成员本身的状态信息。

  • 监控由MGR插件创建的两个组复制专用通道group_replication_recovery和group_replication_applier相关的状态表（这些表在主从复制拓扑中也用于记录从库复制线程的状态信息）。

    *performance_schema.replication_connection_status：记录从组中接受到的且在applier队列（中继日志）中排队的事务（单主模式下，对于主要节点，该表中只有一行组复制通道group_replication_applier的状态记录。对于辅助节点，即复制远端事务的组成员，此表中会多一行组复制通道group_replication_recovery的状态记录），可以理解为主从复制拓扑中，IO线程的位置信息。

    *performance_schema.replication_applier_status：记录组复制的专用复制通道group_replication_recovery和group_replication_applier本身的状态信息（同样，单主模式下，对于主要节点，该表中只有一行组复制通道group_replication_applier的状态记录。对于辅助节点，即复制远端事务的组成员，此表中会多一行复制通道group_replication_recovery的状态记录），可以理解为主从复制拓扑中，IO线程的状态信息。

  • 监控关于两个组复制专用通道group_replication_recovery和group_replication_applier中接受的并正在进行分发与应用的事务状态表。

    *performance_schema.replication_applier_status_by_coordinator：记录SQL协调器线程分发事务相关的状态（单主模式下，对于主要节点，该表中只有一行组复制通道group_replication_applier的状态记录。对于辅助节点，即复制远端事务的组成员，此表中会多一行组复制通道group_replication_recovery的状态记录）。

    *performance_schema.replication_applier_status_by_worker：记录worker线程应用事务相关的状态（单主模式下，对于主要节点，该表中只有组复制通道group_replication_applier的记录，但具体的行数由系统变量slave_parallel_workers定义值决定。对于辅助节点，即复制远端事务的组成员，此表中会多记录组复制通道group_replication_recovery对应的记录，该通道记录的行数仍然由系统变量slave_parallel_workers定义值决定）。

  • PS：关于组复制专用通道：

    *group_replication_recovery：此通道用于与分布式恢复阶段复制相关的变更数据 。

    *group_replication_applier：此通道用于组状态正常的情况下，复制（接收）来自组的变更数据。


3.1. 组复制成员状态


组复制的组成员存在多种有效预设状态值。如果所有组成员之间的通信正常，则所有组成员都能报告相同的状态。但是，如果存在网络分区，或者有成员脱离了组，则可能会报告不同的状态信息。具体来说，如果我们查看一个已经脱离组的Server，则由于它已经脱离了组，所以无法报告关于其他组成员状态的更新信息。如果存在分区，导致冲裁失效（活跃成员数量低于了总成员数量的半数），则组成员相互之间就不能够交换状态信息。此时组状态仍然不正常，不同的组成员上查看到的自身状态可能各不相同，但，如果只有少数成员发生故障，活跃成员占多数，则，除了脱离组的Server之外，其他剩余活跃成员中看到的所有组的成员都能够报告相同的状态。

关于组成员的有效状态列表及其对应的含义如下表。

状态值 状态描述 是否与组保持同步
ONLINE

表示该成员已经准备好作为一个功能齐全的组成员（活跃成员），这意味着该成员可以正常接受客户端的访问（单主模式下，主要节点可接受读写访问， 
辅助节点只可接受只读访问；多主模式下，所有成员都是主要节点，都可以接受读写访问）。

是

RECOVERING

表示该成员正在成为该组的活跃成员，目前正在恢复过程中，正在接受来自donor节点的状态转移数据。

否

OFFLINE

表示该Server已加载了MGR插件，但此时Server不属于任何组。

否

ERROR

表示该成员处于错误状态，不能作为任何组的成员正常工作。如果该Server曾经成功加入过组一次，后续发生任何故障， 
则会根据系统变量group_replication_exit_state_action设置的在退出操作（默认值为READ_ONLY）时执行不同的调整，使得成员在执行退出之后所处的状态可能不同。 
如果设置为READ_ONLY，则该成员退出时处于只读模式(super_read_only= on)，成员状态可能可能为OFFLINE； 
如果设置为OFFLINE_MODE，则该成员退出时处于脱机模式(offline_mode= on, super_read_only= on )，此时成员状态为ERROR，而不是OFFLINE状态。 
如果设置为ABORT_SERVER，则该成员在意外脱离组并耗尽了重新加入组的尝试次数之后，数据库的实例进程将被自动关闭，并从组的视图中删除该成员。

否

UNREACHABLE

当本地故障检测器怀疑某个给定的成员不可访问时(例如，由于非自愿与组断开了连接时)，将显示该成员的状态为UNREACHABLE。

否


3.2. performance_schema.replication_group_members表


performance_schema.replication_group_members表用于监控组中的不同成员实例的状态。每当视图发生更改时，表中的信息就会更新，例如：当有新成员加入组动态更改组的配置时，组成员之间交换它们的一些元数据来同步协作结果并保持持续协作。这些信息在属于组中的所有成员之间共享，因此，可以从组中的任何活跃成员查询到一致性的关于所有组成员的信息。如下：

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 | 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 |
+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+

根据这个结果，我们可以看到这个组由三个成员组成、每个成员的主机和端口号(客户端用来连接到该成员的SQL访问端口，非组成员内部的通讯端口)、以及该成员的server_uuid、MEMBER_STATE列显示组中所有成员都为ONLINE状态、MEMBER_ROLE列显示组中有两个辅助节点和一个主要节点（表示该组运行在单主模式下）、MEMBER_VERSION列显示每个组成员运行的MySQL Server版本（这在对组复制拓扑做升级操作时非常有用）。

PS：有关Member_host列值及其对分布式恢复过程的影响的更多信息，请参见上文中“2.1.3. 用户凭证”部分。


3.3. performance_schema.replication_group_member_stats表


组复制中的每个成员都会各自对从组中接受的事务进行冲突认证检测，然后进行应用。该表中记录了有关从组中接受事务以及应用事务相关的统计信息，这些统计信息对于了解applier队列如何增长、发现了多少冲突事务、验证了多少事务、在什么地方提交了哪些事务等等都很有用。

  • performance_schema.replication_group_member_stats表提供与认证过程相关的组级别统计信息，还提供组复制中每个成员接收和发起的事务的统计信息。这些信息在组中所有成员之间共享，因此可以从任何组成员查询到关于所有组成员的统计信息。注意，远程成员中的统计信息刷新频率由系统变量group_replication_flow_control_period指定，因此，这些统计信息可能与在发起事务（本地事务）的组成员中查询到的统计信息略有不同。此表中记录的组成员状态信息类似如下：

root@localhost : (none):07: > SELECT * FROM performance_schema.replication_group_member_stats\G
*************************** 1. row ***************************
                          CHANNEL_NAME: group_replication_applier
                               VIEW_ID: 15692965051216743:7
                             MEMBER_ID: 2d283e92-de7b-11e9-a14d-525400c33752
           COUNT_TRANSACTIONS_IN_QUEUE: 0
            COUNT_TRANSACTIONS_CHECKED: 342710
              COUNT_CONFLICTS_DETECTED: 0
    COUNT_TRANSACTIONS_ROWS_VALIDATING: 0
    TRANSACTIONS_COMMITTED_ALL_MEMBERS: 320675e6-de7b-11e9-b3a9-5254002a54f2:1-4,
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-342718
        LAST_CONFLICT_FREE_TRANSACTION: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:342718
COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 0
     COUNT_TRANSACTIONS_REMOTE_APPLIED: 342711
     COUNT_TRANSACTIONS_LOCAL_PROPOSED: 0
     COUNT_TRANSACTIONS_LOCAL_ROLLBACK: 0
*************************** 2. row ***************************
                          CHANNEL_NAME: group_replication_applier
                               VIEW_ID: 15692965051216743:7
                             MEMBER_ID: 2e33b2a7-de7b-11e9-9a21-525400bdd1f2
           COUNT_TRANSACTIONS_IN_QUEUE: 0
            COUNT_TRANSACTIONS_CHECKED: 342710
              COUNT_CONFLICTS_DETECTED: 0
    COUNT_TRANSACTIONS_ROWS_VALIDATING: 0
    TRANSACTIONS_COMMITTED_ALL_MEMBERS: 320675e6-de7b-11e9-b3a9-5254002a54f2:1-4,
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-342718
        LAST_CONFLICT_FREE_TRANSACTION: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:342718
COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 0
     COUNT_TRANSACTIONS_REMOTE_APPLIED: 342710
     COUNT_TRANSACTIONS_LOCAL_PROPOSED: 0
     COUNT_TRANSACTIONS_LOCAL_ROLLBACK: 0
*************************** 3. row ***************************
                          CHANNEL_NAME: group_replication_applier
                               VIEW_ID: 15692965051216743:7
                             MEMBER_ID: 320675e6-de7b-11e9-b3a9-5254002a54f2
           COUNT_TRANSACTIONS_IN_QUEUE: 0
            COUNT_TRANSACTIONS_CHECKED: 342713
              COUNT_CONFLICTS_DETECTED: 0
    COUNT_TRANSACTIONS_ROWS_VALIDATING: 0
    TRANSACTIONS_COMMITTED_ALL_MEMBERS: 320675e6-de7b-11e9-b3a9-5254002a54f2:1-4,
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-342718
        LAST_CONFLICT_FREE_TRANSACTION: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:342718
COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 0
     COUNT_TRANSACTIONS_REMOTE_APPLIED: 4
     COUNT_TRANSACTIONS_LOCAL_PROPOSED: 342713
     COUNT_TRANSACTIONS_LOCAL_ROLLBACK: 0
3 rows in set (0.01 sec)

上述查询到的组成员状态信息对于监控组中活跃成员（已建立组通讯连接的成员）的性能非常重要。例如：假设与其他成员相比，组中的某个成员的状态中总是发现队列中存在大量事务。这意味着该成员可能存在大量事务延迟，无法与组中的其他成员保持数据同步。根据这些信息，可以决定是否需要从组中删除该成员，或者延迟处理组中其他成员的事务，以减少队列中的事务数量。这些信息还可以帮助确定如何调整MGR插件的流控阈值，更详细的信息请参见"6.2. 流量控制"。


| 作者简介

罗小波·沃趣科技高级数据库技术专家

IT从业多年，主要负责MySQL 产品的数据库支撑与售后二线支撑。曾参与版本发布系统、轻量级监控系统、运维管理平台、数据库管理平台的设计与编写，熟悉MySQL体系结构，Innodb存储引擎，喜好专研开源技术，多次在公开场合做过线下线上数据库专题分享，发表过多篇数据库相关的研究文章。


相关链接





_
_

更多干货，欢迎来撩~


以上是关于组复制监控 | 全方位认识 MySQL 8.0 Group Replication的主要内容，如果未能解决你的问题，请参考以下文章

组复制常见疑问 | 全方位认识 MySQL 8.0 Group Replication

组复制要求和限制 | 全方位认识 MySQL 8.0 Group Replication

复制信息记录表|全方位认识 mysql 系统库

沃趣科技日志信息记录表|全方位认识 mysql 系统库

用python监控mysql的主从复制

MySQL复制中slave延迟监控