MySQL Group Replication（二）监控篇

文若2年前技术文章792


说明

组复制搭建成功后，为保证其正常运行，用户需要对组复制进行监控。MySQL 的 performance_schema 库中提供一些表，用于监控组复制的复制过程。

[performance_schema]>show tables like '%replication_group%';
+----------------------------------------------------+
| Tables_in_performance_schema (%replication_group%) |
+----------------------------------------------------+
| replication_group_communication_information        |
| replication_group_configuration_version            |
| replication_group_member_actions                   |
| replication_group_member_stats                     |
| replication_group_members                          |
+----------------------------------------------------+

1. 监控表介绍

1.1. replication_group_members

该表用于监控组复制成员的状态，当成员状态发生更新时，该表的信息会进行同步更新。

select * from performance_schema.replication_group_members;

root@mysql 10:43:  [performance_schema]>select * from replication_group_members\G
*************************** 1. row ***************************
              CHANNEL_NAME: group_replication_applier
                 MEMBER_ID: 4f4ab2eb-b0fd-11ed-b9e2-fa7581637800
               MEMBER_HOST: 172-16-104-55
               MEMBER_PORT: 3306
              MEMBER_STATE: ONLINE
               MEMBER_ROLE: SECONDARY
            MEMBER_VERSION: 8.0.32
MEMBER_COMMUNICATION_STACK: XCom
*************************** 2. row ***************************
              CHANNEL_NAME: group_replication_applier
                 MEMBER_ID: 9590bf9c-c302-11ed-8d53-faa7cd9c6a00
               MEMBER_HOST: 172-16-104-57
               MEMBER_PORT: 3306
              MEMBER_STATE: ONLINE
               MEMBER_ROLE: PRIMARY
            MEMBER_VERSION: 8.0.32
MEMBER_COMMUNICATION_STACK: XCom
*************************** 3. row ***************************
              CHANNEL_NAME: group_replication_applier
                 MEMBER_ID: eccc6b43-b0fc-11ed-8e74-fa0e3cc40b00
               MEMBER_HOST: 172-16-104-56
               MEMBER_PORT: 3306
              MEMBER_STATE: ONLINE
               MEMBER_ROLE: SECONDARY
            MEMBER_VERSION: 8.0.32
MEMBER_COMMUNICATION_STACK: XCom

用户可通过上方 SQL 查询组复制成员的状态。其中包含成员的元数据信息，例如端口、成员 ID 等。

1.1.1. MEMBER_STATE

表示当前成员的联机状态，有 ONLINE（成员在线）、OFFLINE（成员离线）、RECOVERING（成员恢复中）ERROR（成员发生错误） 和 UNREACHABLE（成员无法通信） 5 种。

1.1.2. MEMBER_ROLE

表示当前成员的角色，在单主模式下，成员的角色显示为 PRIMARY 和 SECONDARY 分别用于标识主要成员和次要成员。

1.1.3. MEMBER_VERSION

表示当前成员使用 MySQL 服务器版本，当进行升级或者多个版本组合使用时需要注意里面显示的信息。

1.2. replication_group_member_stats

该表提供了组复制中每个成员事务的验证和应用的统计信息，用户可以通过该表查询队列中正在增长的事务，已经检测多少冲突，有多少事务提交及正在等待提交，通过该表可以观测 MGR 的延迟情况。该表可以查到远程实例的信息，远程统计信息采集周期由 group_replication_flow_control_period 参数控制，默认为 1 秒。

select * from replication_group_member_stats;

root@mysql 11:18:  [performance_schema]>select * from replication_group_member_stats\G
*************************** 1. row ***************************
                              CHANNEL_NAME: group_replication_applier
                                   VIEW_ID: 16831711045345851:21
                                 MEMBER_ID: 4f4ab2eb-b0fd-11ed-b9e2-fa7581637800
               COUNT_TRANSACTIONS_IN_QUEUE: 0
                COUNT_TRANSACTIONS_CHECKED: 1
                  COUNT_CONFLICTS_DETECTED: 0
        COUNT_TRANSACTIONS_ROWS_VALIDATING: 3
        TRANSACTIONS_COMMITTED_ALL_MEMBERS: 9590bf9c-c302-11ed-8d53-faa7cd9c6a00:1-7,
a640da45-e4d1-11ed-a959-fa0e3cc40b00:1-23:1000020
            LAST_CONFLICT_FREE_TRANSACTION: a640da45-e4d1-11ed-a959-fa0e3cc40b00:23
COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 0
         COUNT_TRANSACTIONS_REMOTE_APPLIED: 1
         COUNT_TRANSACTIONS_LOCAL_PROPOSED: 0
         COUNT_TRANSACTIONS_LOCAL_ROLLBACK: 0

1.2.1. CHANNEL_NAME

组复制通道名称。

1.2.2. VIEW_ID

当前组成员的视图 ID。

1.2.3. MEMBER_ID

组成员的 UUID。每个成员具有不同的 ID，通过它可以识别组成员。

1.2.4. COUNT_TRANSACTIONS_IN_QUEUE

等待冲突检测队列中存在的事务数量，一旦事务通过冲突检测，它们将等待进行应用。

1.2.5. COUNT_TRANSACTIONS_CHECKED

已检查冲突的事务数量。

1.2.6. COUNT_CONFLICTS_DETECTED

未通过冲突检测检查的事务数量。

1.2.7. COUNT_TRANSACTIONS_ROWS_VALIDATING

暂时没明白干啥的

1.2.8. TRANSACTIONS_COMMITTED_ALL_MEMBERS

在全部成员上成功提交的事务，用 GTID 集合表示。

1.2.9. LAST_CONFLICT_FREE_TRANSACTION

被检测最后一个无冲突事务的 GTID 信息。

1.2.10. COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE

该成员从组中接收并且等待应用的事务数量。

1.2.11. COUNT_TRANSACTIONS_REMOTE_APPLIED

成员从组中接收并应用的事务数量。

1.2.12. COUNT_TRANSACTIONS_LOCAL_PROPOSED

成员本地产生，并且已经发送给组的事务数量。

1.2.13. COUNT_TRANSACTIONS_LOCAL_ROLLBACK

成员本地产生，已经回滚的事务数量。

1.3. replication_connection_status

该表里包含组复制的连接状态信息，处理事务的 I/O 线程状态，以及 clone 通道状态信息。该表常用于排查复制线程的异常。

select * from performance_schema.replication_connection_status\G

[performance_schema]>select * from replication_connection_status\G
*************************** 1. row ***************************
                                      CHANNEL_NAME: group_replication_applier
                                        GROUP_NAME: a640da45-e4d1-11ed-a959-fa0e3cc40b00
                                       SOURCE_UUID: a640da45-e4d1-11ed-a959-fa0e3cc40b00
                                         THREAD_ID: NULL
                                     SERVICE_STATE: ON
                         COUNT_RECEIVED_HEARTBEATS: 0
                          LAST_HEARTBEAT_TIMESTAMP: 0000-00-00 00:00:00.000000
                          RECEIVED_TRANSACTION_SET: 9590bf9c-c302-11ed-8d53-faa7cd9c6a00:1-7,
a640da45-e4d1-11ed-a959-fa0e3cc40b00:1-42:1000020
                                 LAST_ERROR_NUMBER: 0
                                LAST_ERROR_MESSAGE: 
                              LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000
                           LAST_QUEUED_TRANSACTION: a640da45-e4d1-11ed-a959-fa0e3cc40b00:42
 LAST_QUEUED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 2023-05-05 13:48:29.209358
LAST_QUEUED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 2023-05-05 13:48:29.209358
     LAST_QUEUED_TRANSACTION_START_QUEUE_TIMESTAMP: 2023-05-05 13:48:29.206229
       LAST_QUEUED_TRANSACTION_END_QUEUE_TIMESTAMP: 2023-05-05 13:48:29.206283
                              QUEUEING_TRANSACTION: 
    QUEUEING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
   QUEUEING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
        QUEUEING_TRANSACTION_START_QUEUE_TIMESTAMP: 0000-00-00 00:00:00.000000

1.3.1. CHANNEL_NAME

复制通道的名称，组复制有两个通道，分别是应用通道 group_replication_applier 及恢复通道 group_replication_recovery。

1.3.2. GROUP_NAME

组复制的组名称。

1.3.3. SOURCE_UUID

复制源的 UUID 也就是组复制的名称。

1.3.4. THREAD_ID

I/0 线程的 ID。

1.3.5. SERVICE_STATE

服务线程的状态，ON 表示线程存在，处于活动或空闲状态。OFF 表示线程不存在，CONNECTING 表示线程存在，正在连接源服务器。

1.3.6. COUNT_RECEIVED_HEARTBEATS

自上次重新启动、重置执行 CHANGE REPLICATION SOURCE TO 语句以来，副本收到的心跳信号总数。

1.3.7. LAST_HEARTBEAT_TIMESTAMP

副本上次接收心跳信号的时间戳。

1.3.8. RECEIVED_TRANSACTION_SET

副本接收到的事务集合。

1.3.9. LAST_ERROR_NUMBER

线程错误的数量，为 0 表示没有错误。

1.3.10. LAST_ERROR_MESSAGE

线程的错误信息，为空表示没有错误。

1.3.11. LAST_ERROR_TIMESTAMP

错误发生的时间戳。

1.3.12. LAST_QUEUED_TRANSACTION

上次进入中继日志队列中的事务。

1.3.13. LAST_QUEUED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP

中继日志队列中的最后一个事务在源服务器上提交的时间戳。

完整参考 replication_connection_status 表说明

2. SQL 案例

2.1. 查询延迟事务数量

SELECT 
  MEMBER_ID AS id, 
  COUNT_TRANSACTIONS_IN_QUEUE AS trx_tobe_certified, 
  COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE AS relaylog_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;

trx_tobe_certified 为等待冲突检查的事务数量，relaylog_tobe_applied 表示等待被应用的事务数量，任何一个不为 0 表示有延迟。

2.2. 事务之间差距

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

2.3. 查询组复制状态

select * from performance_schema.replication_group_members;


返回列表

上一篇：MySQL Group Replication（一）部署篇

下一篇：PG的表膨胀

相关文章

Linux解锁线程基本概念和线程控制，步入多线程学习的大门（2）

Linux解锁线程基本概念和线程控制，步入多线程学习的大门（2）

2.4.线程等待：为什么需要线程等待？已经退出的线程，其空间没有被释放，仍然在进程的地址空间内。不然也会造成内存泄露问题！创建新的线程不会复用刚才退出线程的地址空间。主线程退出 == 进程退出 ==...

大数据高可用系列--kudu高可用应急方案

大数据高可用系列--kudu高可用应急方案

1 设置机架感知1.1 前置说明    1.9版本后的kudu已经支持机架感知（cdh6之后的版本中的kudu已支持），由于kudu的每个Tablet一般是三副...

CDH实操--HDFS高可用设置

CDH实操--HDFS高可用设置

1 概述        在HDFS集群中NameNode存在单点故障（SPOF），对于只有一个NameNode的集群，如果NameNode机...

MySQL运维实战(4.7) SQL_MODE之ANSI_QUOTES

默认情况下，mysql使用反引号(`)作为标识符的引号。使用mysql关键字作为表名、字段名会报语法错误，这时可以加上反引号（ `)，避免报错。设置ANSI_QUOTES后，使用双引号（"）...

通过SDK上传oss文件报错“413 Request Entity Too Large”

通过SDK上传oss文件报错“413 Request Entity Too Large”

问题描述通过SDK上传oss文件返回错误如下，客户反馈上传的文件不大，只有200M。浏览器端访问返回504 timeout报错，同客户核实是每次到1min 30s时候上传大文件会报错com.aliyu...

ubuntu20.04服务器安全策略设定

ubuntu20.04服务器安全策略设定

密码策略1、经核查，服务器用户身份标识唯一，口令存储在服务器中采用SHA512算法，服务器配置口令复杂度，口令要求8位以上，字母、数字、特殊字符组成，口令180天定期更换。# SHA512算法查看ca...

发表评论    

◎欢迎参与讨论，请在这里发表您的看法、交流您的观点。

©Copyrights 2016-2022 YUNCHE 浙ICP备2021017017号