监控MySQL主从复制需重点关注SHOW SLAVE STATUS中的Slave_IO_Running、Slave_SQL_Running状态及Seconds_Behind_Master延迟值，结合Last_SQL_Errno/Last_SQL_Error定位中断原因，并通过pt-heartbeat、Prometheus+Grafana实现自动化告警。
监控 MySQL 主从复制状态是保障数据一致性与高可用的关键环节，核心在于及时发现延迟、中断或错误。
查看主从复制整体状态
在从库上执行 SERVICE STATUS 命令可快速获取复制运行概况：
- SHOW SLAVE STATUS\G：重点观察 Slave_IO_Running 和 Slave_SQL_Running 是否均为 Yes；任一为 No 表示复制异常
- Seconds_Behind_Master 显示从库落后主库的秒数，值持续大于 0 或不断增长说明存在延迟
- Relay_Log_Pos 与 Master_Log_Pos 的差值变大，可能预示 SQL 线程处理缓慢
识别常见复制中断原因
当 Slave_SQL_Running = No 时，需结合错误日志定位问题：
- Last_SQL_Errno 和 Last_SQL_Error 字段直接显示最近 SQL 执行失败的错误码与信息（如 1062 主键冲突、1032 记录不存在）
- 典型场景包括：主库执行了从库缺失的表结构变更、人为在从库写入数据导致主键/唯一键冲突、网络中断后 relay log 损坏
- 临时跳过错误可使用 SET GLOBAL sql_slave_skip_counter = 1（仅限调试，生产慎用）
自动化监控与告警建议
依赖人工定时检查不可靠，推荐通过脚本或工具实现常态化监控：
- 编写简单 Shell/Python 脚本定期执行 SHOW SLAVE STATUS，提取关键字段并写入日志或推送至 Prometheus
- 用 pt-heartbeat（Percona Toolkit）在主库持续写入时间戳，从库比对延迟，比 Seconds_Behind_Master 更准确可靠
- 配置 Grafana + Prometheus 展示复制延迟趋势、IO/SQL 线程状态，并对 Seconds_Behind_Master > 60 或线程非 Running 状态触发企业微信/钉钉告警
补充检查项：主库与网络层面
从库状态正常不等于复制绝对健康，还需交叉验证：
- 主库执行 SHOW MASTER STATUS，确认 binlog 文件未被意外清理（expire_logs_days 设置是否合理）
- 检查从库到主库的网络连通性（telnet master_ip 3306）、用户权限（REPLICATION SLAVE 权限是否仍有效）
- 观察主库 SHOW PROCESSLIST 中是否有大量 Binlog Dump 连接，异常增多可能意味着从库频繁重连
