答案：MySQL复制监控需关注线程状态、延迟时间、GTID一致性、binlog同步位置及错误日志。1. Slave_IO_Running和Slave_SQL_Running均应为Yes；2. Seconds_Behind_Master反映复制延迟，持续升高需排查性能或大事务问题；3. GTID模式下对比主从Executed_Gtid_Set确保一致性；4. 通过Master_Log_File、Read_Master_Log_Pos等字段判断同步进度；5. Last_Error、Last_IO_Error、Last_SQL_Error记录错误信息，结合监控工具设置告警提升系统稳定性。
MySQL复制是保障数据高可用和读写分离的重要机制，而监控复制状态对维护系统稳定至关重要。及时发现复制延迟、错误或中断，能有效避免数据不一致问题。以下是常见的MySQL复制监控指标及其解析。
1. 复制线程运行状态
检查复制相关的线程是否正常运行，是判断复制是否启动的基础。
关键指标：- Slave_IO_Running：IO线程是否正在运行，负责从主库拉取binlog。
- Slave_SQL_Running：SQL线程是否运行，负责在从库回放事件。
两者都应为“Yes”。若任一线程为“No”，说明复制已中断，需结合错误日志排查原因，如网络问题、权限不足或数据冲突。
2. 复制延迟（Seconds_Behind_Master）
这是最核心的监控指标，反映从库落后主库的时间。
Seconds_Behind_Master 表示从库SQL线程执行进度与接收到的最新binlog之间的秒数差。理想情况下该值接近0。持续升高可能由以下原因导致：
- 从库性能不足（CPU、I/O瓶颈）
- 主库写入压力大，产生大量binlog
- 大事务或长查询阻塞复制回放
注意：当复制停止或SQL线程未运行时，该值可能为NULL或0，不代表无延迟。
3. 主从GTID一致性（基于GTID复制时）
使用GTID复制时，可通过比较主从的已执行事务集判断一致性。
关键命令：
- 主库执行：
SHOW MASTER STATUS;查看Executed_Gtid_Set - 从库执行：
SHOW SLAVE STATUS\G查看Retrieved_Gtid_Set和Executed_Gtid_Set
从库的 Executed_Gtid_Set 应包含主库的全部GTID。若存在差异，说明复制有缺失或延迟。
4. Binlog接收与执行位置
通过文件名和位置信息可判断从库同步进度。
相关字段：- Master_Log_File：当前正在读取的主库binlog文件
- Read_Master_Log_Pos：IO线程读取到的位置
- Relay_Master_Log_File：SQL线程正在回放的主库binlog
- Exec_Master_Log_Pos：SQL线程执行到的位置
对比这些值的变化频率，可辅助判断复制是否停滞或缓慢。
5. 复制错误计数
记录复制过程中发生的错误次数，用于快速定位问题。
关键指标：- Last_Error：最近一次复制错误的具体信息
- Last_IO_Error：IO线程错误（如连接失败）
- Last_SQL_Error：SQL线程错误（如主键冲突）
- Slave_IO_Running_State：IO线程当前状态，如“Waiting for master to send event”
定期检查这些字段，特别是生产环境中自动跳过错误的配置需谨慎使用。
基本上就这些。合理配置监控工具（如Prometheus + MySQL Exporter、Zabbix或Percona Toolkit），结合上述指标设置告警，能大幅提升MySQL复制的可观测性和稳定性。
