执行SHOW SLAVE STATUSG是检查mysql复制健康状况的唯一权威方法，需确认Slave_IO_Running和Slave_SQL_Running均为Yes、无Last_IO_Error/Last_SQL_Error、且Master_Log_File与Relay_Master_Log_File等日志位置持续推进。
直接执行 SHOW SLAVE STATUSG 查看核心状态
登录从库的 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 STATUSG，比对：
—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，比任何监控图表都管用。