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