小亦平臺會持續給大家科普一些運維過程中常見的問題解決案例，運維朋友們可以在常見問題及解決方案專欄查看更多案例

問題概述

• 告警事件：
  • 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的相關內容

運維工作中遇到難題？立即提交工單。小亦平臺工程師火速響應，助您快速修復故障!