运维工作中你遇到过哪些神奇事件？

GreatSQL社区

搜索

[已解决] 请教greatsql新增mgr指标含义？

833 14 2023-11-14 17:59
本帖最后由 running_db 于 2023-11-15 19:55 编辑

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文档都没查到。
  1. group_replication_apply_queue_size            3                        
  2. group_replication_applied_messages      4000000          45         400
  3. group_replication_applied_data_messages     3500000          45         400
  4. group_replication_applied_events             70                        
  5. group_replication_before_commit_request_time 22500000000      250000     4000000
复制代码
3、另外再请教下，有个疑问，开启快速单主模式的情况下，主从gtid差距非常大，比如100万，如果这时候主库挂了，切到从库，这部分差距是丢掉了么？还是新主库会等待这100万应用完毕，才开启可写？
全部回复(14)
只看楼主
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/Great ... 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
  1. (Tue Nov 14 18:20:03 2023)[root@GreatSQL][(none)]>SHOW GLOBAL STATUS LIKE 'group_replication_applied_events';
  2. +----------------------------------+-------+
  3. | Variable_name                    | Value |
  4. +----------------------------------+-------+
  5. | group_replication_applied_events | 20    |
  6. +----------------------------------+-------+
  7. 1 row in set (0.01 sec)

  9. (Tue Nov 14 18:20:03 2023)[root@GreatSQL][(none)]>SHOW GLOBAL STATUS LIKE 'group_replication_io_buffered_events';
  10. +--------------------------------------+-------+
  11. | Variable_name                        | Value |
  12. +--------------------------------------+-------+
  13. | group_replication_io_buffered_events | 0     |
  14. +--------------------------------------+-------+
复制代码


tps统计：下面数据时区差8小时，时间是当时的时间
  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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这个指标。
  1. (Wed Nov 15 15:56:21 2023)[root@GreatSQL][(none)]>SHOW GLOBAL STATUS LIKE 'group_replication_apply_queue_size';
  2. +------------------------------------+-------+
  3. | Variable_name                      | Value |
  4. +------------------------------------+-------+
  5. | group_replication_apply_queue_size | 1     |
  6. +------------------------------------+-------+
  7. 1 row in set (0.01 sec)

  9. (Wed Nov 15 15:56:21 2023)[root@GreatSQL][(none)]>SHOW GLOBAL STATUS LIKE 'group_replication_apply_queue_size';
  10. +------------------------------------+-------+
  11. | Variable_name                      | Value |
  12. +------------------------------------+-------+
  13. | group_replication_apply_queue_size | 1     |
  14. +------------------------------------+-------+
  15. 1 row in set (0.00 sec)

  17. (Wed Nov 15 15:56:22 2023)[root@GreatSQL][(none)]>SHOW GLOBAL STATUS LIKE 'group_replication_applied_messages';
  18. +------------------------------------+--------+
  19. | Variable_name                      | Value  |
  20. +------------------------------------+--------+
  21. | group_replication_applied_messages | 248668 |
  22. +------------------------------------+--------+
  23. 1 row in set (0.01 sec)

  25. (Wed Nov 15 15:56:40 2023)[root@GreatSQL][(none)]>SHOW GLOBAL STATUS LIKE 'group_replication_applied_messages';
  26. +------------------------------------+--------+
  27. | Variable_name                      | Value  |
  28. +------------------------------------+--------+
  29. | group_replication_applied_messages | 249441 |
  30. +------------------------------------+--------+
  31. 1 row in set (0.01 sec)

  33. (Wed Nov 15 15:56:42 2023)[root@GreatSQL][(none)]>SHOW GLOBAL STATUS LIKE 'group_replication_applied_data_messages';
  34. +-----------------------------------------+-------+
  35. | Variable_name                           | Value |
  36. +-----------------------------------------+-------+
  37. | group_replication_applied_data_messages | 65526 |
  38. +-----------------------------------------+-------+
  39. 1 row in set (0.00 sec)

  41. (Wed Nov 15 15:56:52 2023)[root@GreatSQL][(none)]>SHOW GLOBAL STATUS LIKE 'group_replication_applied_data_messages';
  42. +-----------------------------------------+-------+
  43. | Variable_name                           | Value |
  44. +-----------------------------------------+-------+
  45. | group_replication_applied_data_messages | 65862 |
  46. +-----------------------------------------+-------+
  47. 1 row in set (0.00 sec)

  49. (Wed Nov 15 15:56:53 2023)[root@GreatSQL][(none)]>SHOW GLOBAL STATUS LIKE 'group_replication_applied_events';
  50. +----------------------------------+-------+
  51. | Variable_name                    | Value |
  52. +----------------------------------+-------+
  53. | group_replication_applied_events | 12    |
  54. +----------------------------------+-------+
  55. 1 row in set (0.00 sec)

  57. (Wed Nov 15 15:57:02 2023)[root@GreatSQL][(none)]>SHOW GLOBAL STATUS LIKE 'group_replication_applied_events';
  58. +----------------------------------+-------+
  59. | Variable_name                    | Value |
  60. +----------------------------------+-------+
  61. | group_replication_applied_events | 12    |
  62. +----------------------------------+-------+
  63. 1 row in set (0.00 sec)

  65. (Wed Nov 15 15:57:03 2023)[root@GreatSQL][(none)]>SHOW GLOBAL STATUS LIKE 'group_replication_before_commit_request_time';
  66. +----------------------------------------------+-----------+
  67. | Variable_name                                | Value     |
  68. +----------------------------------------------+-----------+
  69. | group_replication_before_commit_request_time | 625217041 |
  70. +----------------------------------------------+-----------+
  71. 1 row in set (0.01 sec)

  73. (Wed Nov 15 15:57:12 2023)[root@GreatSQL][(none)]>SHOW GLOBAL STATUS LIKE 'group_replication_before_commit_request_time';
  74. +----------------------------------------------+-----------+
  75. | Variable_name                                | Value     |
  76. +----------------------------------------------+-----------+
  77. | group_replication_before_commit_request_time | 627625326 |
  78. +----------------------------------------------+-----------+
  79. 1 row in set (0.01 sec)

  81. (Wed Nov 15 15:57:13 2023)[root@GreatSQL][(none)]>SHOW GLOBAL STATUS LIKE 'group_replication_io_buffered_events';
  82. +--------------------------------------+-------+
  83. | Variable_name                        | Value |
  84. +--------------------------------------+-------+
  85. | group_replication_io_buffered_events | 0     |
  86. +--------------------------------------+-------+
  87. 1 row in set (0.01 sec)

  89. (Wed Nov 15 15:58:11 2023)[root@GreatSQL][(none)]>SHOW GLOBAL STATUS LIKE 'group_replication_io_buffered_events';
  90. +--------------------------------------+-------+
  91. | Variable_name                        | Value |
  92. +--------------------------------------+-------+
  93. | group_replication_io_buffered_events | 0     |
  94. +--------------------------------------+-------+
复制代码
回复 采纳

举报

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
回复 采纳

举报

下一页 »
12下一页
running_db

8

主题

0

博客

39

贡献

注册会员

Rank: 2

积分
64

助人为乐（铜）

发消息
互动与交流
社区活动
论坛问答
加入社区
贡献者指南
学习与应用
文章博客
文档资料
视频资料
常见问题
发现社区
社区准则
建议反馈
社区之星

合作电话：010-64087828

社区邮箱：greatsql@greatdb.com

社区公众号
社区小助手
QQ群
友情链接
万里数据库开源中国墨天轮开放原子开源基金会OpenEuler
©2022 GreatSQL All Rights Reserved. ( 京ICP备06057874号 )
GMT+8, 2024-5-6 11:59 , Processed in 0.019494 second(s), 18 queries , Redis On.
快速回复 返回顶部 返回列表