MySQL 主从切换检查清单：故障发生时先看什么、切换前后查什么

主从切换看起来像 DBA 的事，但对应用研发也很重要。

因为一旦切换出问题，应用侧常见现象会很直接：

• 写入失败
• 读写分离路由异常
• 延迟变大
• 数据看起来不一致

先说结论

遇到主从切换相关问题，更稳的顺序通常是：

先确认当前角色和复制状态 -> 再确认延迟与数据完整性 -> 再确认应用连接配置和读写路由

再补一句更接近线上实战的话：

• 不要先切，先看有没有资格切
• 不要切完就走，要确认应用世界也跟着变了

一、先别急着切，先看现状

至少要先回答：

• 当前谁是主
• 当前谁是从
• 从库复制有没有停
• 延迟有多大

如果这些都没确认，就直接切换，风险会很大。

如果能查到，还应该尽量确认：

• 候选从库是否追平
• 当前是否有长事务
• 当前是否处在业务高峰

二、切换前最容易漏掉的三个风险

1. 候选从库其实并不新

如果复制延迟很高，切换上去就等于把业务切到一个“旧世界”。

2. 应用写连接有缓存

很多连接池、配置中心、代理中间件不会瞬时感知角色变化。

3. 读写分离规则没同步调整

库角色变了，但路由规则还按旧主旧从执行，结果会非常混乱。

三、应用侧最容易忽略什么

1. 配置中心里主库地址没同步

2. 连接池还连着旧地址

3. 读写分离中间件缓存了旧拓扑

4. 写后读关键链路没有强制回主

切换期间复制和拓扑都会抖，关键查询如果还放任走旧从库，异常会被放大。

四、切换前要特别看什么

1. 复制延迟

2. 是否还有未同步事务

3. 当前业务是否在高峰

4. 是否已经明确回滚路径

如果新主切上去后应用异常、数据校验不过，是否还能快速降级或重新指回旧链路。

五、切换后要立刻确认什么

1. 写请求是否正常

2. 读请求是否仍旧打到合理节点

3. 核心表数据是否一致

4. 主从关系是否重新建立

很多切换不是“切完就结束”，而是还要尽快恢复新的复制拓扑。

六、一个更实用的现场检查顺序

如果真的在线上遇到主从切换，我更推荐按这条顺序处理：

1. 看数据库当前角色与复制状态
2. 选候选节点，确认是否足够新
3. 做切换动作
4. 验证主写是否成功
5. 验证关键读是否命中正确节点
6. 验证核心表数据和业务链路
7. 收尾恢复复制拓扑和监控告警

这样能避免“数据库切好了，但应用还没醒过来”的情况。

七、什么时候研发一定要介入

如果系统里有下面这些设计，研发不能只等数据库层处理：

• 强依赖本地缓存的库地址
• 多数据源手工路由
• 写后立刻读的强一致场景

八、比临时处理更重要的是长期治理

更推荐逐步补：

• 明确主从切换流程
• 配置中心统一管理连接
• 发布前确认数据库拓扑依赖
• 关键业务加读写路由观测

还可以进一步补：

• 低峰演练切换
• 应用级主从切换 checklist
• 切换期间关键接口健康探针
• 写后读一致性兜底策略

一句话总结

主从切换最怕的不是切换本身，而是数据库角色已经变了，应用侧还按旧世界在运行。

所以真正稳的处理方式，一定是数据库状态和应用状态一起确认。