必须确认Seconds_Behind_Master=0且IO/SQL线程均运行中，再比对Read_Master_Log_Pos与主库Position完全一致；GTID模式下应使用WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS校验，而非仅依赖Seconds_Behind_Master。

确认从库已完全追平主库 binlog 位置

手动切换最常被跳过的一步：不检查 Seconds_Behind_Master 是否为 0，直接切就丢数据。它不是“看起来没延迟”，而是必须确认 IO 线程和 SQL 线程都已停稳、位点完全一致。

在原从库上执行 SHOW SLAVE STATUS\G，重点看：
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 0

再比对 Master_Host 对应的原主库上的 SHOW MASTER STATUS 输出，确保从库的 Read_Master_Log_Pos 和原主库的 Position 完全相等

• 如果 Seconds_Behind_Master 是 NULL，说明 SQL 线程已停止（比如刚执行过 STOP SLAVE），此时必须先 START SLAVE 等追平，再 STOP SLAVE
• GTID 模式下更可靠：在从库执行 SELECT WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS('xxx', 10)，返回 0 才表示指定 GTID 集合已执行完毕
• ROW 格式 binlog 下，Seconds_Behind_Master 可能“假归零”——建议配合 MASTER_POS_WAIT() 或 WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS() 强制校验

停写旧主并设为只读

切主不是“让新主上线”，而是“让旧主下线”。很多故障转移失败，是因为应用还在往旧主写，导致双写冲突或数据分裂。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

在原主库上执行：
SET GLOBAL read_only = ON（需 SUPER 权限）
立刻验证：SELECT @@read_only 返回 1 才算生效

• 更保险的做法是同时执行 FLUSH TABLES WITH READ LOCK，但该命令会阻塞所有 DML 和部分 DDL，仅建议在低峰期、且已确认无长事务时使用
• GTID 模式下，read_only = ON 并不能阻止拥有 SUPER 权限的用户写入，务必同步检查账号权限
• 别漏掉应用层：检查连接池是否启用 autoReconnect、DNS 缓存 TTL、负载均衡器后端健康检查逻辑，否则流量仍可能打到旧主 IP

将原从库提升为新主库

这步看似只是改个角色，实际核心是重置复制坐标——否则它仍认为自己是“从”，下次重启可能自动重连旧主、覆盖已有数据。

在原从库上执行：
STOP SLAVE
RESET SLAVE ALL（ALL 很关键，清除 master.info 文件和内存中所有主库元数据）
SET GLOBAL read_only = OFF

• 推荐紧接着执行 RESET MASTER：清空本地 binlog 并新建第一个文件，避免后续其他从库拉取到旧主残留的 binlog 名称，引发 Could not find first log file name in binary log index file 错误
• 若原从库启用了 log_slave_updates，升主后要确认是否仍需开启——新主需生成 binlog 供下游从库拉取，该参数必须为 ON
• 检查 server-id 是否唯一：新主的 server-id 不能与任何其他节点重复，否则会导致复制链路错乱

让其他从库指向新主库

老从库不改源，就会继续连旧主（已只读或宕机），表现为 Slave_IO_Running: No + Last_IO_Error 报连接拒绝或认证失败。

在每个待切换的从库上执行：
CHANGE MASTER TO MASTER_HOST='新主IP', MASTER_PORT=3306, MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_LOG_FILE='mysql-bin.000xxx', MASTER_LOG_POS=xxxxxx
START SLAVE

• 非 GTID 模式下，MASTER_LOG_FILE 和 MASTER_LOG_POS 必须来自新主的 SHOW MASTER STATUS 输出，不能复用旧主位点
• GTID 模式下可简化为 CHANGE MASTER TO MASTER_AUTO_POSITION = 1，但前提是所有节点 gtid_mode = ON 且 enforce_gtid_consistency = ON
• 切换后立即查 SHOW SLAVE STATUS\G，重点盯 Seconds_Behind_Master 是否持续增长——若卡在 Waiting for master to send event，大概率是网络不通或复制账号权限未同步到新主

真实环境里最容易被忽略的不是命令本身，而是「旧主是否真被拦住写入」和「新主 binlog 是否对下游可见」。这两点一出问题，整个切换就从高可用变成数据事故。