小亦平台会持续给大家科普一些运维过程中常见的问题解决案例，运维朋友们可以在常见问题及解决方案专栏查看更多案例

问题概述

• 告警事件：
  • 2023-07-28 03:31:39.571 首次触发主从延迟告警（延迟1515秒）
  • 2023-07-28 07:41:37 告警解除（延迟恢复至0秒）
• 告警对象：
  • 数据库：寿险-销管02
  • 主机：*.*.*.41（从库）
  • 监控IP：*.*.*.42
• 告警内容：

"数据库名：-，主机：..*.41，用户：repl，端口：3306，延迟时间为1515s"

问题分析

1. 主从延迟的通用原理
   • 主库写入速率高，从库SQL线程应用跟不上
   • 主库存在大事务、长事务或DDL操作
   • 从库锁阻塞写入（如表锁、行锁）
2. 具体排查过程

• Binlog产生速率分析（主库操作）

```ps -ef | grep mysql    # 确认配置文件

cat /etc/my.cnf | grep binlog

ll -h /data/mysql/3306/```

分析：Binlog生成速率正常，无突发增长

• 查看监控平台上资源使用监控：

分析：CPU、内存、I/O及redo/binlog写入量与历史同期持平，排除资源瓶颈

• DDL操作与备份验证：
  • 确认无大表DDL操作
  • 确认无备份任务阻塞从库写入
• 锁等待异常推测：

从库存在应用读写分离（业务查询）
分析：可能因查询锁阻塞复制线程写入

注：MySQL无法回溯历史锁信息，无法直接验证

解决方案

1. 被动等待复现（保留现场）

• 下次告警触发时，立即在主从库执行：

SELECT * FROM information_schema.processlist WHERE info IS NOT NULL;

• 保存输出结果供后续分析

2. 主动排查方向

• 应用侧：检查应用日志中SQL执行时间、锁等待时间
• 业务侧：梳理冲突SQL（如访问相同行/数据范围）

3. 主动优化措施

• SQL优化：减少慢sql、大事务、长事务，特别是多表join、子查询，能减少负载和锁阻塞的几率。
• 架构调整：对延迟敏感的业务禁用读写分离
• 任务调度优化：避免跑批。或者将跑批拆分时间段，而不是集中在几分钟内跑完，避免产生大量数据而从库同步不及时导致延迟(主库是多并发的，而从库只有一个线程写入。即便开了并发复制也不会有主库并发高)

立即查看更多mysql的相关内容

运维工作中遇到难题？立即提交工单。小亦平台工程师火速响应，助您快速修复故障!