主从复制中断后如何快速定位 Seconds_Behind_Master
为 NULL 的原因
当
SHOW SLAVE STATUS\G中
Seconds_Behind_Master显示
NULL，基本可判定复制已停止，不是延迟大。常见原因有：
Slave_IO_Running或
Slave_SQL_Running为
No，需先查这两个字段。
Slave_IO_Running: No多因网络不通、主库 binlog 被清理、主库
server_id冲突或权限不足（复制用户缺失
REPLICATION SLAVE权限）
Slave_SQL_Running: No通常是 SQL 线程执行失败，如主从表结构不一致、唯一键冲突、误删从库数据导致
UPDATE/DELETE找不到行 注意
Relay_Log_File和
Relay_Log_Pos是否停滞不动——若不变，说明 IO 线程卡死；若持续变化但
Exec_Master_Log_Pos不变，则是 SQL 线程阻塞
跳过单条报错事件：用 SET GLOBAL sql_slave_skip_counter
还是 gtid_next
？
取决于是否启用 GTID。未启用 GTID 时，
SET GLOBAL sql_slave_skip_counter = 1可跳过当前 relay log 中下一条事件，但仅对基于位置的复制有效，且需先
STOP SLAVE；GTID 模式下该命令被禁用，必须用
SET GTID_NEXT+ 空事务方式绕过。 GTID 模式下跳过错误步骤：
STOP SLAVE→
SET GTID_NEXT = 'xxx-xxx-xxx:N'（N 是报错事务的 GTID 序号+1）→
BEGIN; COMMIT;→
SET GTID_NEXT = 'AUTOMATIC'→
START SLAVE跳过操作是临时补救，不能常态化使用；跳过后务必校验从库数据一致性，例如用
pt-table-checksum频繁需要跳过，说明主从环境存在结构性风险：比如主库执行了
DROP TABLE但从库该表被应用逻辑依赖，或主库开了
sql_log_bin=0导致某些变更未记入 binlog
手动故障转移时，如何安全提升从库为主库
核心原则：确保选中的从库已完全追平主库（
Seconds_Behind_Master = 0且
Slave_SQL_Running = Yes），再停主库写入、切换应用连接。不能只看 IO 线程状态。 执行前在候选从库上运行：
STOP SLAVE IO_THREAD，等
Seconds_Behind_Master变为 0 后再
STOP SLAVE，避免 relay log 中残留未执行事件 检查
SHOW MASTER STATUS输出的
File和
Position（或 GTID set），这是新主库的起点，后续其他从库需据此
CHANGE MASTER TO修改新主库配置：设
read_only = 0，确认
log_bin已开启（否则无法再作为主库提供 binlog），并更新应用连接地址 原主库恢复后，不要直接
START SLAVE—— 它可能已产生新写入，需先备份其 binlog、重放至新主库，再以新主库为源重建复制关系
为什么推荐用 orchestrator
或 MHA
而非纯脚本做自动故障转移
人工操作响应慢、易出错；而自动化工具的核心价值不在“切换快”，而在“判断准”和“闭环全”。比如
orchestrator会主动探测拓扑、识别中间节点、验证数据一致性，并支持优雅降级（如仅读服务不中断）。
MHA的
master_ip_failover脚本能自动挪动 VIP，但要求所有节点时间同步、SSH 免密通，且不兼容 MySQL 8.0+ 的默认认证插件（需显式设
default_authentication_plugin=mysql_native_password）
orchestrator支持 HTTP API 和 Web UI，故障时可人工干预暂停自动切换，比 cron +
mysqladmin ping类脚本更可控 所有自动方案都绕不开一个事实：网络分区（split-brain）时，工具可能误判主库宕机。因此必须配合仲裁节点（如 etcd 或外部 ping check）或强制多数派投票机制，否则高可用反而变成高风险
真正难的不是切主，而是切完之后怎么让其他从库跟上新主、怎么防止脑裂、怎么让应用无感重连。这些环节一旦漏掉一环，所谓高可用就只是幻觉。
