mysql如何查看主从复制状态_mysql监控与诊断

SHOW SLAVE STATUSG须在MySQL客户端执行，关键看Slave_IO_Running、Slave_SQL_Running是否为Yes及Seconds_Behind_Master是否稳定≤3；GTID模式下重启需谨慎，延迟持续>60秒须干预。

SHOW SLAVE STATUSG 必须在 mysql 客户端里执行

直接在 linux shell 输入 SHOW SLAVE STATUSG 会报错 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 STATUSG 输出中，只看这三个字段就能快速判断复制是否健康：

• 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 缺乏告警阈值。一旦延迟悄然累积数小时，故障恢复时的数据追平成本会陡增。