请教greatsql新增mgr指标含义？

running_db 发表于 2023-11-14 17:59:38

1、环境说明

OS：Rocky Linux release 8.8 5.4.259-1.el8.elrepo.x86_64
DB：GreatSQL-8.0.32-24-Linux-glibc2.28-x86_64

2、问题描述
在使用pt-mysql-summary时发现几个mgr相关的指标，想查查含义，但是mysql官方文档和greatsql文档都没查到。
group_replication_apply_queue_size          3
group_replication_applied_messages    4000000       45       400
group_replication_applied_data_messages 3500000       45       400
group_replication_applied_events          70
group_replication_before_commit_request_time 22500000000    250000 40000003、另外再请教下，有个疑问，开启快速单主模式的情况下，主从gtid差距非常大，比如100万，如果这时候主库挂了，切到从库，这部分差距是丢掉了么？还是新主库会等待这100万应用完毕，才开启可写？

yejr 发表于 2023-11-14 18:06:05

先回复问题2：

1. group_replication_apply_queue_size：当前applier线程中，尚未处理的消息队列的大小，如果该值累计较大，节点可能存在较大的延迟。对于用户数据来说，这些事务的数据尚未写入到realylog中。

2. group_replication_applied_messages：applier线程累计应用的消息总量，包括用户数据的事务消息，和其它组复制运行过程中产生的各种消息。

3. group_replication_applied_data_messages：applier线程累计应用的用户数据的事务消息的总量，即已经写入到relaylog中的事务总量。通过和group_replication_applied_messages对比，可以分析事务消息的占比情况。

4. group_replication_applied_events：applier线程累计应用的用户数据的事务的binlog events总量，通过和group_replication_applied_data_messages进行对比，可以估算平均一个事务大体写了多少个binlog event。

5. group_replication_io_buffered_events：applier线程将事务数据写入relaylog中，会进行批处理，降低刷盘次数，提高磁盘利用率。该变量表示累计被io buffer未进行刷盘的binlog events的数量。通过和group_replication_applied_events对比，可以估算大体多少个event会进行一次刷盘，分析relaylog磁盘利用情况。

yejr 发表于 2023-11-14 18:08:09

回复问题3

在MGR中，所有事务都要把binlog发送到secondary节点，你说的GTID延迟只是这些事务还没被apply。旧primary节点挂掉后，新的primary是否需要等待这些事务被apply再响应用户请求，具体要看你的选项 group_replication_consistency 是如何设置的。

更多内容请先阅读文档：https://gitee.com/GreatSQL/GreatSQL-Doc/blob/master/deep-dive-mgr/deep-dive-mgr-16.md

running_db 发表于 2023-11-14 18:21:59

本帖最后由 running_db 于 2023-11-15 09:48 编辑

yejr 发表于 2023-11-14 18:06
先回复问题2：

1. group_replication_apply_queue_size：当前applier线程中，尚未处理的消息队列的大小， ...
我发现统计数据不太对，当前正在做测试，update执行每秒300多个，但是group_replication_applied_events这个值一直为20，group_replication_io_buffered_events 这个为0(Tue Nov 14 18:20:03 2023)[(none)]>SHOW GLOBAL STATUS LIKE 'group_replication_applied_events';
+----------------------------------+-------+
| Variable_name | Value |
+----------------------------------+-------+
| group_replication_applied_events | 20 |
+----------------------------------+-------+
1 row in set (0.01 sec)

(Tue Nov 14 18:20:03 2023)[(none)]>SHOW GLOBAL STATUS LIKE 'group_replication_io_buffered_events';
+--------------------------------------+-------+
| Variable_name | Value |
+--------------------------------------+-------+
| group_replication_io_buffered_events | 0 |
+--------------------------------------+-------+

tps统计：下面数据时区差8小时，时间是当时的时间
current_time: 2023-11-14 10:21:22, time_ms: 17, select_per_second: 0, insert_per_second: 0, update_per_second: 277, delete_per_second: 0, conn_count: 104, max_conn: 3000, recv_mbps: 760, send_mbps: 296
current_time: 2023-11-14 10:21:23, time_ms: 17, select_per_second: 0, insert_per_second: 0, update_per_second: 313, delete_per_second: 0, conn_count: 104, max_conn: 3000, recv_mbps: 830, send_mbps: 322
current_time: 2023-11-14 10:21:24, time_ms: 18, select_per_second: 0, insert_per_second: 0, update_per_second: 371, delete_per_second: 0, conn_count: 104, max_conn: 3000, recv_mbps: 1000, send_mbps: 387
current_time: 2023-11-14 10:21:25, time_ms: 18, select_per_second: 0, insert_per_second: 0, update_per_second: 325, delete_per_second: 0, conn_count: 104, max_conn: 3000, recv_mbps: 875, send_mbps: 339
current_time: 2023-11-14 10:21:26, time_ms: 48, select_per_second: 0, insert_per_second: 0, update_per_second: 370, delete_per_second: 0, conn_count: 104, max_conn: 3000, recv_mbps: 1191, send_mbps: 441
current_time: 2023-11-14 10:21:27, time_ms: 18, select_per_second: 0, insert_per_second: 0, update_per_second: 444, delete_per_second: 0, conn_count: 99, max_conn: 3000, recv_mbps: 1032, send_mbps: 417
current_time: 2023-11-14 10:21:28, time_ms: 19, select_per_second: 0, insert_per_second: 0, update_per_second: 463, delete_per_second: 0, conn_count: 104, max_conn: 3000, recv_mbps: 1223, send_mbps: 474
current_time: 2023-11-14 10:21:29, time_ms: 18, select_per_second: 0, insert_per_second: 0, update_per_second: 383, delete_per_second: 0, conn_count: 90, max_conn: 3000, recv_mbps: 1032, send_mbps: 404

wangbin579 发表于 2023-11-15 14:08:11

对于fast mode，切到从库，新主库会等这些应用完毕才能接受新的请求。

由于官方MySQL MGR采用了原先异步复制的代码，这部分回放效率很差，所以差距会有点大。回放快的版本，以后会出来的。

phoenix.zhang 发表于 2023-11-15 14:30:09

本帖最后由 phoenix.zhang 于 2023-11-15 14:36 编辑

running_db 发表于 2023-11-14 18:21
我发现统计数据不太对，当前正在做测试，update执行每秒300多个，但是group_replication_applied_events这 ...
查询的global status是主节点的，还是从节点的数据？如果是从节点的，该从节点的mgr处于什么状态呢？
以及其它几个相关的global status，applied_messages，applied_data_messages，apply_queue_size都是什么值呢？

running_db 发表于 2023-11-15 15:59:55

本帖最后由 running_db 于 2023-11-15 16:06 编辑

phoenix.zhang 发表于 2023-11-15 14:30
查询的global status是主节点的，还是从节点的数据？如果是从节点的，该从节点的mgr处于什么状态呢？
以及 ...
在主节点查看的，以下日志，是现在测试的，每个指标获取了两次，group_replication_io_buffered_events和group_replication_applied_events没变化。另外叶老师也少说了一个group_replication_before_commit_request_time这个指标。
(Wed Nov 15 15:56:21 2023)[(none)]>SHOW GLOBAL STATUS LIKE 'group_replication_apply_queue_size';
+------------------------------------+-------+
| Variable_name                   | Value |
+------------------------------------+-------+
| group_replication_apply_queue_size | 1 |
+------------------------------------+-------+
1 row in set (0.01 sec)

(Wed Nov 15 15:56:21 2023)[(none)]>SHOW GLOBAL STATUS LIKE 'group_replication_apply_queue_size';
+------------------------------------+-------+
| Variable_name                   | Value |
+------------------------------------+-------+
| group_replication_apply_queue_size | 1 |
+------------------------------------+-------+
1 row in set (0.00 sec)

(Wed Nov 15 15:56:22 2023)[(none)]>SHOW GLOBAL STATUS LIKE 'group_replication_applied_messages';
+------------------------------------+--------+
| Variable_name                   | Value|
+------------------------------------+--------+
| group_replication_applied_messages | 248668 |
+------------------------------------+--------+
1 row in set (0.01 sec)

(Wed Nov 15 15:56:40 2023)[(none)]>SHOW GLOBAL STATUS LIKE 'group_replication_applied_messages';
+------------------------------------+--------+
| Variable_name                   | Value|
+------------------------------------+--------+
| group_replication_applied_messages | 249441 |
+------------------------------------+--------+
1 row in set (0.01 sec)

(Wed Nov 15 15:56:42 2023)[(none)]>SHOW GLOBAL STATUS LIKE 'group_replication_applied_data_messages';
+-----------------------------------------+-------+
| Variable_name                         | Value |
+-----------------------------------------+-------+
| group_replication_applied_data_messages | 65526 |
+-----------------------------------------+-------+
1 row in set (0.00 sec)

(Wed Nov 15 15:56:52 2023)[(none)]>SHOW GLOBAL STATUS LIKE 'group_replication_applied_data_messages';
+-----------------------------------------+-------+
| Variable_name                         | Value |
+-----------------------------------------+-------+
| group_replication_applied_data_messages | 65862 |
+-----------------------------------------+-------+
1 row in set (0.00 sec)

(Wed Nov 15 15:56:53 2023)[(none)]>SHOW GLOBAL STATUS LIKE 'group_replication_applied_events';
+----------------------------------+-------+
| Variable_name                | Value |
+----------------------------------+-------+
| group_replication_applied_events | 12 |
+----------------------------------+-------+
1 row in set (0.00 sec)

(Wed Nov 15 15:57:02 2023)[(none)]>SHOW GLOBAL STATUS LIKE 'group_replication_applied_events';
+----------------------------------+-------+
| Variable_name                | Value |
+----------------------------------+-------+
| group_replication_applied_events | 12 |
+----------------------------------+-------+
1 row in set (0.00 sec)

(Wed Nov 15 15:57:03 2023)[(none)]>SHOW GLOBAL STATUS LIKE 'group_replication_before_commit_request_time';
+----------------------------------------------+-----------+
| Variable_name                            | Value |
+----------------------------------------------+-----------+
| group_replication_before_commit_request_time | 625217041 |
+----------------------------------------------+-----------+
1 row in set (0.01 sec)

(Wed Nov 15 15:57:12 2023)[(none)]>SHOW GLOBAL STATUS LIKE 'group_replication_before_commit_request_time';
+----------------------------------------------+-----------+
| Variable_name                            | Value |
+----------------------------------------------+-----------+
| group_replication_before_commit_request_time | 627625326 |
+----------------------------------------------+-----------+
1 row in set (0.01 sec)

(Wed Nov 15 15:57:13 2023)[(none)]>SHOW GLOBAL STATUS LIKE 'group_replication_io_buffered_events';
+--------------------------------------+-------+
| Variable_name                      | Value |
+--------------------------------------+-------+
| group_replication_io_buffered_events | 0 |
+--------------------------------------+-------+
1 row in set (0.01 sec)

(Wed Nov 15 15:58:11 2023)[(none)]>SHOW GLOBAL STATUS LIKE 'group_replication_io_buffered_events';
+--------------------------------------+-------+
| Variable_name                      | Value |
+--------------------------------------+-------+
| group_replication_io_buffered_events | 0 |
+--------------------------------------+-------+

running_db 发表于 2023-11-15 16:03:31

本帖最后由 running_db 于 2023-11-15 16:05 编辑

wangbin579 发表于 2023-11-15 14:08
对于fast mode，切到从库，新主库会等这些应用完毕才能接受新的请求。

由于官方MySQL MGR采用了原先异步复 ...
你说的是主从不同步了，切主后不接受查询和事务么？我另外一个帖子就是，主从gtid相差较大，我kill主后，新主切换成功了，但是查询阻塞。是这个快速单主模式的原因阻塞的？
大佬，看看这个https://greatsql.cn/thread-520-1-1.html

phoenix.zhang 发表于 2023-11-15 16:20:11

running_db 发表于 2023-11-15 15:59
在主节点查看的，以下日志，是现在测试的，每个指标获取了两次，group_replication_io_buffered_events和g ...

主节点查看没有意义。

这些global status是作用于applier线程的，applier线程类似于普通主从复制的slave io线程，用于将mgr内部paxos接收的各类消息进行处理，同时对事务相关的数据进行写relaylog，所以这里applied_events，就是已经写relaylog的events总数，io_buffered_events就是写relaylog过程中内部batch落盘的events数量。

phoenix.zhang 发表于 2023-11-15 16:29:38

running_db 发表于 2023-11-15 15:59
在主节点查看的，以下日志，是现在测试的，每个指标获取了两次，group_replication_io_buffered_events和g ...

另外，before_commit_request_time是用于统计事务commit阶段，消耗在mgr层面的时间；与之相关的还有一个flow_control_time，当开启流控时，统计所有事务commit阶段，因流控缘故消耗的总时间。

其中，before_commit_request_time是不包括flow_control_time的这部分时间的，也就是mgr实际的总消耗时间是：before_commit_request_time + flow_control_time

页: [1] 2

GreatSQL社区's Archiver

请教greatsql新增mgr指标含义？