读写分离如何延迟监控

本文目录导读：

1. 核心监控指标
2. 监控实现方法
3. 延迟告警与处理策略
4. 最佳实践建议

读写分离架构中,从库延迟是导致数据一致性问题（如“刚写入的数据读不到”）的核心原因，监控延迟并设置告警是保障业务稳定性的关键。

以下是针对延迟监控的系统性方案，涵盖指标、方法、工具和告警策略。

核心监控指标

需要明确监控哪些指标来反映延迟状态：

关键提醒：Seconds_Behind_Master 在某些情况下会失真（如主从时钟不同步、长事务、网络闪断后重连）。位点差（Read_Master_Log_Pos - Exec_Master_Log_Pos）结合Binlog大小估算，或使用GTID（全局事务标识符） 监控更为精确。

监控实现方法

方法1：数据库层内部监控（最基础）

通过定时执行 SHOW SLAVE STATUS 并解析输出。

示例脚本（Shell）：

#!/bin/bash
# 监控从库延迟
MYSQL_USER="monitor"
MYSQL_PASS="your_password"
MYSQL_HOST="slave_ip"
THRESHOLD=10  # 延迟超过10秒告警
LAG=$(mysql -u$MYSQL_USER -p$MYSQL_PASS -h$MYSQL_HOST -e "SHOW SLAVE STATUS\G" | grep "Seconds_Behind_Master" | awk '{print $2}')
if [ "$LAG" -gt "$THRESHOLD" ]; then
    echo "CRITICAL: Slave lag is ${LAG}s on ${MYSQL_HOST}"
    # 发送告警（如通过curl调用告警API）
fi

方法2：使用监控系统（Prometheus + Exporters，推荐）

这是生产环境最常用的方案,可以收集历史趋势并设置动态告警。

1. 部署 MySQL Exporter： 在每个从库节点上。
2. 配置 Prometheus： 抓取 Exporter 暴露的指标。
3. 关键指标（从 Exporter 中获取）：
   • mysql_slave_status_seconds_behind_master
   • mysql_slave_status_slave_io_running (值为1表示正常)
   • mysql_slave_status_slave_sql_running (值为1表示正常)
4. Grafana 面板： 可以可视化显示延迟曲线。

Prometheus 告警规则示例（YAML）：

groups:
- name: mysql_replication
  rules:
  - alert: MySQLReplicationLagHigh
    expr: mysql_slave_status_seconds_behind_master > 30
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "MySQL 从库延迟过高 (instance {{ $labels.instance }})"
      description: "从库 {{ $labels.instance }} 延迟已达 {{ $value }} 秒，超过 30 秒阈值。"

方法3：应用层逻辑监控（解决“已写入但查询不到”问题）

对于强一致性要求的场景，数据库延迟监控不够实时，需要在应用层做校验。

伪代码逻辑（Java/Python）：

// 用户在A服务写入数据后，返回主键ID
Long userId = userWriteService.createUser(request);
// 1. 异步记录“待验证”事件到Redis或MQ
pendingReadCheck.add(userId);
// 2. 当B服务读取数据时，先检查该ID是否刚被写入
if (pendingReadCheck.exists(userId)) {
    // 优先强制读主库
    user = readFromMaster(userId);
} else {
    // 正常读从库
    user = readFromSlave(userId);
}
// 3. 定期清理“待验证”事件（如写入后5秒自动移除）

延迟告警与处理策略

不能只监控不处理,必须建立明确的响应机制：

1. 分级告警：

   • 延迟 > 5秒（WARNING）： 发送工作群，观察趋势。
   • 延迟 > 30秒（CRITICAL）： 发短信/电话告警，触发自动化处理或人工介入。
   • 延迟持续增长不回落（如中继日志空间持续上升）： 可能是从库机器性能瓶颈（CPU、磁盘IO）或大事务阻塞。

2. 自动化降级策略：

   • 短期方案： 告警时自动摘除该从库，停止向其分发读流量（通过负载均衡器或DNS解析）。

     # 伪代码（告警回调）
     def on_slave_lag_alert(host):
         if lag > 60:
             remove_slave_from_load_balancer(host)  # 摘除
             send_alert_to_ops("Slave {} removed from LB due to high lag".format(host))

   • 预防方案： 对于无法接受延迟的业务（如支付、登录），写操作直接强制读主库，或在配置中心设置“写后读一致性”开关。

3. 根源排查脚本（应对高延迟）：

   • 检查 大事务：SHOW PROCESSLIST 中执行时间长的 UPDATE/DELETE。
   • 检查 从库性能瓶颈：SHOW ENGINE INNODB STATUS 查看是否有大量的 I/O 等待。
   • 检查 主从网络：ping 检测RTT（往返延迟），查看带宽使用。
   • 检查 从库配置：innodb_flush_log_at_trx_commit 是否为 2 或 2？sync_binlog 是否过高？

最佳实践建议

1. 不要只依赖 Seconds_Behind_Master： 结合 GTID（SELECT GTID_SUBSET('source_gtid_set', 'replica_gtid_set')）或者位点差进行二次验证。
2. 监控链路状态： 同时监控 Slave_IO_Running 和 Slave_SQL_Running，它们为 Yes 才代表复制正常，IO线程断开会造成延迟数值变成 NULL。
3. 设置多维告警： 延迟数值 + 延迟趋势（持续上升）+ 业务错误率（读不到数据导致的异常）。
4. 分布式缓存辅助： 对于多从库场景，可以考虑写入后同步写入缓存（如Redis），读请求先读缓存，缓存过期或没有缓存再读从库，这样能极大降低从库延迟对业务的影响。
5. 工具推荐：
   • Percona Toolkit: pt-heartbeat（最精确的主从延迟监控工具，它通过主库上定期更新一张心跳表，从库去读取该表的更新时间戳来计算延迟，不受时钟同步影响）。
   • Prometheus + MySQL Exporter + Grafana： 最流行的开源监控栈。

通过以上方案,你可以构建一个从基础指标到业务逻辑验证，再到自动化降级的完整延迟监控体系。