使用SHOW SLAVE STATUS命令可实时监控MySQL主从复制状态，重点关注Slave_IO_Running和Slave_SQL_Running线程状态及Seconds_Behind_Master延迟指标，结合Last_Error分析故障原因，建议通过自动化工具如Prometheus与Grafana实现持续监控与告警，确保数据一致性与系统稳定。
在 MySQL 主从复制环境中，监控复制状态是确保数据一致性和系统稳定的关键。你可以通过多种方式实时检查复制的运行情况，及时发现并解决问题。
查看复制线程状态
使用 SHOW SLAVE STATUS 命令可以获取从库复制的详细信息。这是最直接的方法。
SHOW SLAVE STATUS\G重点关注以下字段：
- Slave_IO_Running：显示 IO 线程是否正常连接主库并读取二进制日志
- Slave_SQL_Running：显示 SQL 线程是否能正确执行中继日志中的事件
- Last_Error 和 Last_IO_Error：记录最近发生的错误信息
- Seconds_Behind_Master：表示从库延迟主库的秒数，是衡量复制延迟的重要指标
检查复制延迟
Seconds_Behind_Master 字段反映当前复制延迟。如果该值持续增长，说明从库处理速度跟不上主库写入节奏。
注意：当 SQL 线程或 IO 线程未运行时，这个值可能为 NULL 或不准确。需结合其他状态判断。
你也可以通过对比主从的 GTID 集合（如使用 GTID 复制）来更精确地评估同步进度。
自动化监控建议
手动检查适合临时排查，生产环境建议设置自动监控机制：
- 编写脚本定期执行 SHOW SLAVE STATUS，解析关键字段并告警异常
- 使用 Prometheus + MySQL Exporter 收集复制指标，配合 Grafana 展示和 Alertmanager 告警
- 监控 Seconds_Behind_Master 超过阈值（如 60 秒）时触发通知
- 记录 Last_Error 内容，便于快速定位问题原因
常见问题识别
如果 Slave_IO_Running 为 No，通常是网络问题、用户权限不足或主库日志被清除导致。
若 Slave_SQL_Running 为 No，多因数据冲突、语句执行失败或表结构不一致。
遇到错误时，可根据 Last_Error 提示修复后，使用 START SLAVE 恢复复制。
基本上就这些。保持对复制状态的持续关注，能有效避免数据丢失和服务中断。
