直接执行 SHOW SLAVE STATUS\G
查看核心状态
登录从库的 MySQL 客户端后，唯一必须做的第一步就是运行这条命令。它不是“可选监控手段”，而是复制健康状况的唯一权威入口。
Slave_IO_Running和
Slave_SQL_Running必须同时为 Yes；任一为
No表示复制已中断，不能只看延迟值就判断“还在同步”
Seconds_Behind_Master为
0或个位数（如
3）属正常；若持续大于
60，说明从库追不上，但值为
NULL才真正危险——通常意味着 SQL 线程根本没启动或刚启动还没执行任何事件
Last_IO_Error和
Last_SQL_Error是排障第一线索，错误信息会直接告诉你连不上主库、权限拒绝、主键冲突还是表结构不一致
对比主从 binlog 位置确认是否真在推进
仅看
Seconds_Behind_Master容易被误导：该值依赖系统时间差计算，在时钟不同步、大事务回放中可能失真。更可靠的依据是日志坐标本身。 在主库执行
SHOW MASTER STATUS;，记下
File（如
mysql-bin.000042）和
Position（如
1987456） 在从库执行
SHOW SLAVE STATUS\G，比对：
—
Master_Log_File和
Read_Master_Log_Pos：反映 IO 线程拉到了哪（应接近主库最新位置）
—
Relay_Master_Log_File和
Exec_Master_Log_Pos：反映 SQL 线程执行到了哪（应逐步逼近前一组值） 若
Read_Master_Log_Pos长期不动，说明网络卡住或主库 dump 线程异常；若
Exec_Master_Log_Pos不动而
Read_Master_Log_Pos在涨，大概率是 SQL 线程卡在某条语句上（比如锁等待、DDL 阻塞）
查错误日志定位深层原因
SHOW SLAVE STATUS只显示最近一次错误，很多问题（如反复重连失败、GTID 冲突、relay log 损坏）需要翻原始日志才能看清上下文。 先确认日志路径：
SHOW VARIABLES LIKE 'log_error';典型命令：
tail -f /var/log/mysqld.log | grep -i "slave\|error\|retry"注意常见陷阱：
— 错误日志里出现
Could not find first log file name in binary log index file，往往是 relay log 路径配置错误或磁盘满导致写入失败
— 出现
Lost connection to MySQL server during query，要检查主从之间防火墙、max_allowed_packet 是否一致、网络抖动是否频繁
用 pt-table-checksum
验证数据是否真一致
线程跑着、延迟为 0，不代表数据没出错。人为修改从库、跳过错误、字符集不一致都可能导致“看起来正常，实际丢数据”。
该工具通过分块校验主从表的 CRC32 值，能精准定位到哪张表、哪一行不一致 运行前确保：— 主从
binlog_format = ROW（否则 checksum 事件无法被复制）
— 从库开启
log_slave_updates = ON（否则 checksum 结果不会同步到下游） 最简使用：
pt-table-checksum --host=slave_ip --user=root --password=xxx h=master_ip，结果中
Differences列非 0 即表示存在差异
别只盯着
Seconds_Behind_Master的数字跳动——它不报错、不告警、不反映数据偏差。真正关键的是三件事：两个线程是否活着、错误字段有没有内容、主从日志位置是否在同步推进。日常巡检时，把这三行输出设成终端 alias，比任何监控图表都管用。
