MySQL高可用--MGR入门（2）组复制监控常用相关表

前文介绍了 MGR单主多主模式搭建 ，今天为大家讲解MGR组复制监控常用相关表。

MGR单个节点状态：

MGR整个组的状态：

主要用到4张表：

performance_schema.replication_group_member_stats

performance_schema.replication_group_members

performance_schema.replication_connection_status

performance_schema.replication_applier_status

1. replication_group_member_stats

是用来展示组复制所有成员信息的表，有关验证和应用程序的统计信息对于了解申请队列增长情况、触发了多少冲突、检查了多少事务、哪些事务已被所有成员提交等等非常有用。

这张表主要是监控各个节点的性能，如果出现某个节点的事务号和其他节点差很多，那这个节点肯定出现了延迟，如果长时间的延迟，极有可能被群员投票给踢出去。

这张表只有在配置组复制后才会有数据。其中字段包括：

其中最重要的列，也是经常被观察的指数如下：

• COUNT_TRANSACTTIONS_IN_QUEUE：组复制队列中等待冲突检测的事务数，只有当冲突检测通过才会排队应用到各个节点上。（远程等待被确认的事务数）
• COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE：当前节点收到的等待的事务数。（远程的事务还有多少没有被应用)
• COUNT_TRANSANCTIONS_CHECKED：已经通过冲突检测的事务数。
• COUNT_TRANSACTIONS_REMOTE_APPLIED：当前节点收到的应用的事务数。（本地已经应用的事务数）
• COUNT_TRANSACTIONS_LOCAL_PROPOSED：源自此成员并发送给复制组的事务数。（本地已经提交的事务数）
• CANNEL_NAME：这个组复制通道的名称。
• VIEW_ID：组复制对应的视图号。
• MEMBER_ID：复制中组成员的 ID，这个 ID 和本身 MySQL 实例的 UUID 没关系。
• COUNT_CONFLICTS_DETECTED：未通过冲突检测的事务数。
• COUNT_TRANSACTIONS_ROWS_VALIDATING：冲突检查数据库的大小。
• TRANSACTIONS_COMMITTED_ALL_MEMBERS：已在复制组的所有成员上成功提交的事务，显示为 GTID 集。
• LAST_CONFLICT_FREE_TRANSACTION：最后一次冲突事务的 GITD 号。
• COUNT_TRANSACTIONS_REMOTE_APPLIED：当前节点收到的应用的事务数。
• COUNT_TRANSACTIONS_LOCAL_PROPOSED：源自此成员并发送给复制组的事务数。
• COUNT_TRANSACTIONS_LOCAL_ROLLBACK：源自此成员并被复制组回滚的事务数。

2.replication_group_members

用于监控组内成员复制状态的表：

• CHANNEL_NAME：组复制的通道名。
• MEMBER_ID：组成员 ID。
• MEMBER_HOST：组成员的主机名。
• MEMBER_PORT：组成员数据库实例端口，注意这里是实例端口。
• MEMBER_STATE：组成员当前的状态，这个栏位总共有 4 个状态Online 表示正常工作状态，表示该节点目前一切 OK。

Recovering 表示节点正在加入组中，这个状态有可能是正在同步数据，也有可能是正在和主节点发生通信，如果长期处于这个状态，往往是 host 没配，需要检查下 host 配置
Offline 表示这个节点的组复制插件已经加载
Unreachable 表示经过仲裁，某个节点已经崩溃或者不可访问。

• MEMBER_ROLE：成员在组内的角色，如果是单主模式，主的节点就会显示 PRIMARY，其他节点显示 SECONDARY，如果是多主模式，所有节点均为 PRIMARY。
• MEMBER_VERSION：MySQL 的版本。

3. replication_connection_status

用于记录当前节点连接状态的表：

• CHANNEL_NAME：组复制通道名。
• GROUP_NAME：组复制名，就是组的 UUID 号。
• SOURCE_UUID：组复制源的 UUID 号。
• THREAD_ID：组复制 I/O 功能的 threadid。
• SERVICE_STATE：显示成员当前的活跃状态。
• COUNT_RECEIVED_HEARTBEATS：从上一次重置主从后获得的心跳数。
• LAST_HEARTBEAT_TIMESTAMP：节点的最后一次心跳时间。
• RECEIVED_TRANSACTION_SET：与该从站接收的所有事务相对应的一组全局事务 ID（GTID）。如果未使用 GTID，则为空。
• LAST_ERROR_NUMBER：最后一次 I/O 同步线程错误编号，0 为无错误。
• LAST_ERROR_MESSAGE：最后一次 I/O 同步线程错误日志，记录在 MySQL 错误日志中。
• LAST_ERROR_TIMESTAMP：最后一次 I/O 线程错误的时间。
• LAST_QUEUED_TRANSACTION：该节点同步的 relay log 中最后一个事务的 GTID 号。
• LAST_QUEUED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP：最后一次，在各个节点中写入的事务准备好提交，产生写集并且发送到各个节点做冲突校验时候的时间。
• LAST_QUEUED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP：最后一次事务最终提交的时间。
• LAST_QUEUED_TRANSACTION_START_QUEUE_TIMESTAMP：I/O 线程将最后一个事务放置在 relaylog 中的时间。
• LAST_QUEUED_TRANSACTION_END_QUEUE_TIMESTAMP：进入 relaylog 排队的时间。
• QUEUEING_TRANSACTION：当前 relaylog 中全局事务的 ID。
• QUEUEING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP：当前事务进入写集的时间。
• QUEUEING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP：当前事务最后提交的时间。
• QUEUEING_TRANSACTION_START_QUEUE_TIMESTAMP：当前日志进入 relaylog 的时间。

可用此表来判断延迟：

select RECEIVED_TRANSACTION_SET from replication_connection_status where CHANNEL_NAME='group_replication_applier'
union all
select VARIABLE_VALUE from global_variables where VARIABLE_NAME ='gtid_executed';

本地已经执行的GTID和接收到远程的GTID的差异：

4. replication_applier_status

用于显示当前组复制线程做了什么的表：

• CHANNEL_NAME：复制通道的名字。
• SERVICE_STATE：当复制通道的应用程序线程处于活动或空闲状态时显示为 ON，表示关闭时，应用程序线程未处于活动状态。
• REMAINING_DELAY：同步复制线程的延迟时间。
• COUNT_TRANSACTIONS_RETRIES：SQL 线程无法应用日志重试的次数。

墨天轮原文链接：https://www.modb.pro/db/168460?sjhy（复制链接至浏览器或点击文末阅读原文查看)

关于作者

陈家睿，云和恩墨MySQL技术顾问,拥有MySQL OCP、PGCE、OBCA、SCDP证书，长期服务于电信行业。现负责公司MySQL数据库、分布式数据库运维方面的技术工作；热衷于运维故障处理、备份恢复、升级迁移、性能优化的学习与分享。

END