SHOW SLAVE STATUS\G 必须在 MySQL 客户端里执行
直接在 Linux shell 输入
SHOW SLAVE STATUS\G会报错
bash: show: command not found，因为这是 SQL 命令，不是系统命令。必须先登录 MySQL 客户端再运行。 本地部署：执行
mysql -uroot -p，输密码后进入 Docker 环境：先进容器
docker exec -it mysql_slave1 bash，再执行
mysql -uroot -p确认当前连接的是从库（
node1或
mysql-node2），不是主库
关键字段怎么看：三个核心状态缺一不可
SHOW SLAVE STATUS\G输出中，只看这三个字段就能快速判断复制是否健康：
Slave_IO_Running: Yes—— IO 线程正常，能连上主库并拉 binlog
Slave_SQL_Running: Yes—— SQL 线程正常，能解析 relay log 并执行
Seconds_Behind_Master: 0或稳定小值（如 1~3）—— 表示延迟基本可控；持续增长说明积压
只要其中任一为
No，或
Seconds_Behind_Master突然飙升，就代表同步中断或卡住。此时务必检查
Last_IO_Error和
Last_SQL_Error字段内容，它们是定位问题的第一线索。
STOP SLAVE; START SLAVE; 不是万能重启，GTID 下要更谨慎
当复制线程挂掉时，很多人习惯直接执行
STOP SLAVE; START SLAVE;，这在传统基于 position 的复制中通常有效。但在 GTID 模式下，如果错误源于事务冲突（比如从库已有某 GTID 对应的事务），盲目重启只会反复失败。 先查
Retrieved_Gtid_Set和
Executed_Gtid_Set是否一致，不一致说明有 gap 或跳过行为 跳过错误需手动设置
GTID_NEXT，例如：
SET GTID_NEXT='aabbccdd-eeff-1122-3344-5566778899aa:123'; BEGIN; COMMIT; SET GTID_NEXT='AUTOMATIC';跳过操作不可逆，仅限已确认无数据影响的场景（如重复建表、删空表等）
延迟大 ≠ 复制坏，但 Seconds_Behind_Master 长期 > 60 就该干预
Seconds_Behind_Master是估算值，受网络抖动、大事务、从库负载高等影响，偶尔跳到 5~10 秒属正常。但如果它长期维持在几十秒甚至几分钟以上，说明存在实质性瓶颈： 主库刚执行了一个耗时 UPDATE，从库串行回放中 —— 查
SHOW PROCESSLIST看 SQL 线程是否卡在某个语句 从库磁盘 I/O 慢或 CPU 跑满 —— 结合
top和
iostat -x 1看资源占用 开启了
sync_binlog=1或
innodb_flush_log_at_trx_commit=1但硬件跟不上 —— 这类配置保安全但拖慢回放速度
真正容易被忽略的是：很多团队只监控
Slave_IO_Running和
Slave_SQL_Running是不是 Yes，却对
Seconds_Behind_Master缺乏告警阈值。一旦延迟悄然累积数小时，故障恢复时的数据追平成本会陡增。
