监控告警

本文描述对GreatSQL数据库进行监控有哪几个主要关注点。

除去常规的服务的可用性、性能监控外，对GreatSQL数据库的监控建议关注以下几方面：

  1. SQL平均响应耗时
  2. 锁、等待事件
  3. 大事务
  4. MGR监控

下面我们针对这几个不同监控维度进行详细介绍。

1. SQL平均响应耗时

除了TPS、QPS外，SQL平均响应耗时也是衡量数据库性能的重要指标之一。

TPS、QPS好比高速公路收费站闸机每分钟能通过多少辆车，而SQL平均响应耗时则是每辆车通过闸机的平均耗时。

前者考验收费站单位时间内的处理能力，后者是作为用户体验的衡量维度。

前者通过增设闸机数量（提高并发度），即可提高处理能力；而后者则需要通过优化闸机处理机制（优化数据库 & 每条SQL），才能提高响应效率。

在GreatSQL中，可以利用 benchmark() 函数来衡量SQL平均响应耗时：

  1. greatsql> \help benchmark
  2. Name: 'BENCHMARK'
  3. Description:
  4. Syntax:
  5. BENCHMARK(count,expr)
  6. ...
  7. Examples:
  8. greatsql> SELECT BENCHMARK(1000000,AES_ENCRYPT('hello','goodbye'));
  9. +---------------------------------------------------+
  10. | BENCHMARK(1000000,AES_ENCRYPT('hello','goodbye')) |
  11. +---------------------------------------------------+
  12. |                                                 0 |
  13. +---------------------------------------------------+
  14. 1 row in set (4.74 sec)

即调用 benchmark() 函数进行固定次数的计算，根据其耗时，作为SQL平均响应耗时的衡量指标。

并且可以在业务空闲时段取得该值作为基准数据，再根据业务高峰时期的耗时作为对比，即可知道业务高峰期SQL平均响应耗时增加了多少，效率降低了多少。

例如：

  1. time mysql -q -N -s -e "SELECT BENCHMARK(100000,AES_ENCRYPT('hello','goodbye'))"
  2. 0
  4. real    0m0.024s
  5. user    0m0.001s
  6. sys     0m0.004s

这就可以得到耗时是 0.024s，即可认为当前SQL平均响应耗时是及24ms，通过监控系统在不同时段获取该值，即可知道这个指标的变化波动幅度了。

2. 锁、等待事件

2.1 当前行锁数量

  1. greatsql> select * from performance_schema.global_status where variable_name = 'Innodb_row_lock_current_waits';
  2. +-------------------------------+----------------+
  3. | VARIABLE_NAME                 | VARIABLE_VALUE |
  4. +-------------------------------+----------------+
  5. | Innodb_row_lock_current_waits | 0              |
  6. +-------------------------------+----------------+

当该值大于0的时候，就要立即发出告警，表示当前存在行锁等待事件，要检查是否有事务持有行锁未释放。

2.2 IBP wait free

  1. greatsql> select * from performance_schema.global_status where variable_name = 'Innodb_buffer_pool_wait_free';
  2. +-------------------------------+----------------+
  3. | VARIABLE_NAME                 | VARIABLE_VALUE |
  4. +-------------------------------+----------------+
  5. | Innodb_buffer_pool_wait_free  | 0              |
  6. +-------------------------------+----------------+

当该值大于0的时候，就要立即发出告警，表示InnoDB Buffer Pool严重不够用，如果物理内存足够，则适当加大，或者迁移到更高内存的服务器上。

2.3 InnoDB log wait

  1. greatsql> select * from performance_schema.global_status where variable_name = 'Innodb_log_waits';
  2. +------------------+----------------+
  3. | VARIABLE_NAME    | VARIABLE_VALUE |
  4. +------------------+----------------+
  5. | Innodb_log_waits | 0              |
  6. +------------------+----------------+

当该值大于0的时候，就要立即发出告警，表示InnoDB Log Buffer严重不够用，如果物理内存足够，则适当加大，或者迁移到更高内存的服务器上。

2.4 InnoDB Purge Lag

  1. greatsql> SELECT `COUNT`,`COMMENT` FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME = 'trx_rseg_history_len';
  2. +-------+-------------------------------------+
  3. | COUNT | COMMENT                             |
  4. +-------+-------------------------------------+
  5. |    14 | Length of the TRX_RSEG_HISTORY list |
  6. +-------+-------------------------------------+
  8. greatsql> pager cat - | grep -i 'History list length'
  9. PAGER set to 'cat - | grep -i 'History list length''
  11. # 或者换一种方式查看
  12. greatsql> show engine innodb status\G
  13. History list length 4

当该值超过2000后，就要立即发出告警，表示当前等待被purge的队列较大，需要检查是否物理I/O存在瓶颈，或者有个大事务提交了。

3. 大事务

在生产环境中，可能因为种种原因产生大事务，或者运行很长时间的事务。

这些事务中可能对数据库执行大量修改操作，需要持有行锁、MDL锁等资源，如果事务长时间不提交/回滚，则可能对其他业务请求造成严重影响，这些请求可能会被长时间阻塞。

因此，需要关注运行中的大事务、长事务，一旦发现超过阈值，就应当发出告警。

  1. # 找到活跃时间最长的事务
  2. greatsql> SELECT * FROM information_schema.innodb_trx ORDER BY trx_started ASC LIMIT 1;
  4. # 找到等待时间最长的事务
  5. greatsql> SELECT * FROM sys.innodb_lock_waits ORDER BY wait_age_secs DESC LIMIT 1;
  7. # 找到特别需要关注的事务
  8. greatsql> SELECT * FROM information_schema.innodb_trx WHERE
  9.   trx_lock_structs >= 5 OR    -- 持有超过5把锁
  10.   trx_rows_locked >= 100 OR   -- 超过100行被锁
  11.   trx_rows_modified >= 100 OR -- 超过100行被修改
  12.   TIME_TO_SEC(TIMEDIFF(NOW(),trx_started)) > 100;    -- 事务活跃超过100秒

以上阈值可根据实际情况进行调整，需要对生产环境中的活跃大事务保持关注，避免造成连锁影响。

4. MGR监控

对MGR除了监控其服务状态外，更重要的是监控各节点间的事务延迟情况，以此判断各节点的事务处理能力，以及评估是否需要提升服务器配置等级。

  1. greatsql> SELECT MEMBER_ID AS id, COUNT_TRANSACTIONS_IN_QUEUE AS trx_tobe_certified,
  2.   COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE AS relaylog_tobe_applied,
  3.   COUNT_TRANSACTIONS_CHECKED AS trx_chkd,
  4.   COUNT_TRANSACTIONS_REMOTE_APPLIED AS trx_done,
  5.   COUNT_TRANSACTIONS_LOCAL_PROPOSED AS proposed
  6.   FROM performance_schema.replication_group_member_stats;
  7. +--------------------------------------+-------------------+---------------------+----------+----------+----------+
  8. | id                                   |trx_tobe_certified |relaylog_tobe_applied| trx_chkd | trx_done | proposed |
  9. +--------------------------------------+-------------------+---------------------+----------+----------+----------+
  10. | 4ebd3504-11d9-11ec-8f92-70b5e873a570 |                 0 |                   0 |   422248 |        6 |   422248 |
  11. | 549b92bf-11d9-11ec-88e1-70b5e873a570 |                 0 |              238391 |   422079 |   183692 |        0 |
  12. | 5596116c-11d9-11ec-8624-70b5e873a570 |              2936 |              238519 |   422115 |   183598 |        0 |
  13. | ed5fe7ba-37c2-11ec-8e12-70b5e873a570 |              2976 |              238123 |   422167 |   184044 |        0 |
  14. +--------------------------------------+-------------------+---------------------+----------+----------+----------+

其中，relaylog_tobe_applied 的值表示远程事务写到relay log后，等待回放的事务队列，trx_tobe_certified 表示等待被认证的事务队列大小，这二者任何一个值大于0，都表示当前有一定程度的延迟，应当发出告警。

还可以通过关注上述两个数值的变化，看看两个队列是在逐步加大还是缩小，据此判断Primary节点是否”跑得太快”了，或者Secondary节点是否”跑得太慢”。

如果某个节点上的 relaylog_tobe_applied 值特别大，则要引起关注，检查该节点上的业务压力是否过大，或者服务器配置是否有问题。

在GreatSQL中，针对MGR applier线程，新增以下几个状态变量：

  1. group_replication_apply_queue_size：applier线程中尚未处理的消息队列的大小。如果该值累计较大，说明当前节点可能存在较大的延迟，也即有较多事务数据尚未写入到Realy Log中。

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

  3. group_replication_applied_data_messages：applier线程累计应用的用户数据的事务消息的总量，即已经写入到Relay Log中的事务总量。通过和 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线程将事务数据写入Relay Log中，会进行批处理，降低刷盘次数，提高磁盘利用率。该变量表示累计被io buffer未进行刷盘的Binlog Events的数量。通过和 group_replication_applied_events 对比，可以估算大体多少个Event会进行一次刷盘，分析Relay Log磁盘利用情况。

  6. group_replication_before_commit_request_time：用于统计事务commit阶段，消耗在mgr层面的时间；与之相关的还有一个 group_replication_flow_control_time，当开启流控时，统计所有事务commit阶段，因流控缘故消耗的总时间。group_replication_before_commit_request_time 是不包括 group_replication_flow_control_time 的这部分时间的，也就是mgr实际的总消耗时间是 group_replication_before_commit_request_time + group_replication_flow_control_time。

关于MGR监控，更多详情参考文档：MGR状态监控监控告警 - 图1 (opens new window)。

问题反馈

联系我们

扫码关注微信公众号

greatsql-wx