SHOW SLAVE STATUS\G须在MySQL客户端执行，关键看Slave_IO_Running、Slave_SQL_Running是否为Yes及Seconds_Behind_Master是否稳定≤3；GTID模式下重启需谨慎，延迟持续>60秒须干预。
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 缺乏告警阈值。一旦延迟悄然累积数小时，故障恢复时的数据追平成本会陡增。
