怎么看主从复制是否真的在跑
最直接的办法就是进从库 MySQL 客户端，执行
SHOW SLAVE STATUS\G。别在 Linux shell 里敲这个命令——否则会报
bash: show: command not found。关键看三处：
Slave_IO_Running和
Slave_SQL_Running都得是
Yes；
Seconds_Behind_Master要么是
0，要么稳定在个位数（比如 1~3 秒）。如果这个值持续上涨，或者变成
NULL，说明复制线程已经停了。
延迟飙升时该查哪几行日志
延迟不是凭感觉，得靠证据定位。先看从库错误日志：
tail -f /var/log/mysql/error.log。常见线索包括：
Last_IO_Error（IO 线程连不上主库、权限不对、binlog 文件被删）、
Last_SQL_Error（SQL 线程执行某条语句失败，比如主库删了表但从库还留着触发器）。如果是 GTID 模式，还要比对
Retrieved_Gtid_Set和
Executed_Gtid_Set是否一致——不一致就说明有事件卡在 relay log 里没执行。
用 pt-table-checksum 校验数据是否真一致
SHOW SLAVE STATUS只能告诉你“线程在跑”，不能保证“数据没丢”。真正校验一致性得靠工具：
pt-table-checksum是 Percona 提供的成熟方案。它会在主库上分块计算校验和，再让从库回传结果对比。运行命令类似：
pt-table-checksum --host=master_host --user=user --password=pass --databases=test_db。注意：必须确保主从 binlog 格式一致（推荐
ROW），且从库开启
log_slave_updates（级联复制场景下尤其重要）。
监控告警不能只盯 Seconds_Behind_Master
单靠
Seconds_Behind_Master做告警容易误报。比如大事务正在执行时，这个值会突增几十秒，但其实是正常现象；而一旦 SQL 线程卡死，它可能长期停留在某个非零值不动，反而漏掉故障。更稳妥的做法是组合判断：
Slave_IO_Running = Yes+
Slave_SQL_Running = Yes+
Seconds_Behind_Master 。用 Prometheus + <a style="color:#f60; text-decoration:underline;" title="mysql" href="https://www.php.cn/zt/15713.html" target="_blank">mysql</a>d_exporter 采集这些指标，比写脚本轮询 <code>SHOW SLAVE STATUS更可靠。另外，
Relay_Log_Space如果持续增长，说明中继日志堆积，往往预示 SQL 线程已滞后或阻塞，这个字段常被忽略。
