记一次MySQL复制延迟的优化

最近，有一套MySQL数据库每天夜里22点到凌晨2点都会出现，从库复制延迟的告警。
给人第一的感觉就是最近做过主从的切换，可能双1的参数设置又被还原了。
于是确认了下，发现不是双1，

mysql> show global variables like 'innodb_flush_log_at_trx_commit';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| innodb_flush_log_at_trx_commit | 2     |
+--------------------------------+-------+
1 row in set (0.00 sec)

mysql> show global variables like 'sync_binlog';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| sync_binlog   | 10000 |
+---------------+-------+
1 row in set (0.00 sec)

根据我们以往的经验来看，既然不是双1，那就考虑是不是有什么大事务？
于是找慢日志，发现慢日志里，除了几个监控层面的SQL，没有其他的慢查询。
说明是没有大事务的。

cat slow.log 
       
# Query_time: 0.200973  Lock_time: 0.000098 Rows_sent: 3684  Rows_examined: 3684
SET timestamp=1682557910;
SELECT OBJECT_SCHEMA, OBJECT_NAME, ifnull(INDEX_NAME, 'NONE') as INDEX_NAME,
            COUNT_FETCH, COUNT_INSERT, COUNT_UPDATE, COUNT_DELETE,
            SUM_TIMER_FETCH, SUM_TIMER_INSERT, SUM_TIMER_UPDATE, SUM_TIMER_DELETE
          FROM performance_schema.table_io_waits_summary_by_index_usage
          WHERE OBJECT_SCHEMA NOT IN ('mysql', 'performance_schema');

最可能是原因的两个地方，确没发现问题，于是，我们来从监控上，看看能否找到蛛丝马迹。

image.png

从这个图，基本可以确定了，有一个批任务，并发太高，commit次数过多，导致从库延迟。
既然原因找到了，就好处理了。

于是通过mysqlbinlog，解析出来，找到对应的库名和表名。

找到对应的开发，至于如何确定这个库是哪个开发的，就看dba对业务的熟练层度了，或者是公司的平台发布机制，有对应的历史记录可寻。

通过了解，这是一个批任务，每天晚上10点开始执行，replace 700万条临时数据到生产数据库中，每天读取1000条到缓存，然后逐条提交。

这基本符合了预期的判断。
于是就有了下面的对话，

image.png

过了几天，没告警，都遗忘了这个事，
今天打开监控一看，效果杠杠的。

image.png