数据库主库故障时，业务快速切换的核心在于“提前规划好切换路径并反复演练”，依赖高可用架构（如MHA、Orchestrator）实现秒级或分钟级自动/手动故障转移，配合Proxy或VIP漂移让应用无感知。
故障切换前必须做好的三件事
主库宕机后的每一秒都是钱,但现实是，多数团队的切换流程停留在文档里，真出事时手忙脚乱，要保证快速切换，功夫在平时。
把拓扑图贴在墙上
先问自己一个问题：你的从库在哪台机器上？中继日志有没有延迟？如果答不上来，那切换时大概率会丢数据或选错新主库。
实操建议：
- 用Orchestrator或脚本定期检测主从复制延迟,延迟超过阈值就告警
- 把数据库拓扑图打印出来贴在工位上,标注每个节点的IP、角色、机房
- 确认从库的
server_id、binlog_format、log_slave_updates参数配置正确
半同步复制必须打开
异步复制在高峰期可能丢几千条binlog,半同步复制（rpl_semi_sync_master_enabled=1）能保证至少一个从库收到binlog后才返回事务提交成功，多数情况下，这是数据零丢失和快速切换之间的最优解。
写一套能落地的切换脚本
别指望DBA半夜爬起来手敲CHANGE MASTER TO，业界成熟方案有：
- MHA：老牌方案，管理节点负责故障检测和failover，部署简单，但已停止更新
- Orchestrator：支持跨机房拓扑管理，能自动处理复杂切换，是目前社区活跃度较高的选择
- ProxySQL或HAProxy：前置代理层，通过探活机制自动摘除故障节点
关键点：脚本里要包含“先判断主库是否真的挂了，再选出数据最新的从库，然后补binlog，最后提升为新主”的完整逻辑，谁来做这个判断？行业内多数选择Orchestrator的recover命令，它内部实现了raft协议保证决策一致性。
数据库主库故障时业务如何快速切换：标准动作拆解
这里给出一个实际可操作的切换流程,适用于MySQL主从架构，假设你有1主2从，前置ProxySQL，且已启用Orchestrator。
第一步：30秒内确认故障根因
不要一上来就切换,先回答三个问题：
- 是主机宕机、网络分区还是MySQL进程假死？
- 从库延迟多少秒？延迟大不大？
- 是否有多机房容灾要求,需不需要切换机房？
通过ping、ssh
、mysqladmin status三步快速定位，如果SSH能连上但MySQL无响应，可以先尝试systemctl restart mysqld，快速重启有时比切换成本更低。
第二步：触发自动或手动切换
以Orchestrator为例：
orchestrator-client -c recover -i 192.168.1.10:3306
该命令会自动完成：
- 确认主库不可达
- 在所有从库中选出数据最完整的节点（通过比较
Exec_Master_Log_Pos） - 对新主库执行
STOP SLAVE; RESET SLAVE ALL; - 将其他从库重新指向新主库
ProxySQL端需要执行：
UPDATE mysql_servers SET status='OFFLINE_HARD' WHERE hostname='192.168.1.10'; LOAD MYSQL SERVERS TO RUNTIME;
此时业务流量会自动打到新主库上,整个过程在1分钟左右完成。
第三步：校验数据一致性
切换完成后不要急着庆祝,用pt-table-checksum对比新主库和从库的数据，看有没有差异，同时检查业务日志里有没有“connection refused”或“deadlock”报错。
注意：如果业务代码里做了读写分离（写库走主，读库走从），还需要检查从库是否配置了read_only=1，避免新主库被误写入。
MySQL主从切换方案哪个好：自研脚本与开源工具对比
很多团队纠结要不要自己写脚本,我的看法是：能用开源工具就用开源工具，自研脚本的坑多到超乎想象。
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| MHA | 部署简单，文档多 | 已停止维护，不支持GTID自动处理 | 老项目，中小规模 |
| Orchestrator | 支持跨机房/多租户，有Web UI | 学习曲线陡峭，依赖Raft集群 | 中大团队，复杂拓扑 |
| 自研脚本 | 完全贴合业务 | 开发和测试成本高，容易漏边界情况 | 对流程有极端定制化要求 |
行业共识认为：如果团队DBA人数少于2人，不要碰自研方案，直接用Orchestrator配合ProxySQL，这是目前综合成本最低的路径，网上关于“数据库高可用架构怎么选”的讨论里，这个组合的推荐度相当高。
自研脚本至少要覆盖哪几个场景
如果你还是决定自研,那么下面这些逻辑必须写进脚本里，缺一个都会出事故：
- 主库假死（进程在但响应超时）和真死（主机宕机）的区分
- 从库中继日志损坏时的强制提升方案
- 多个从库binlog点位不一致时的仲裁规则
- 切换完成后自动在从库上开启
read_only防止写入错乱
业务侧配合：切换不只是DBA的事
主库切换再快,如果业务代码不做配合，一样会“卡死”几分钟。
连接池要有超时和重试机制
很多业务故障的持续时间远超切换本身,原因在于应用连接池里的旧连接还在指向故障主库。务必确保连接池配置了连接存活检测（如Druid的testWhileIdle，HikariCP的connectionTimeout），并且在捕获到CommunicationsException时主动清理连接。
事务重试逻辑要前置
写库操作在切换瞬间会失败,业务代码里要有统一的异常拦截，遇到死锁或主键冲突时自动重试，业内专家指出，多数切换引发的“应用雪崩”其实源于重试风暴所有请求同时重试，打垮新主库，解决方案是给重试加随机退避时间，如100ms到500ms之间随机。
读多写少的业务可以临时降级
如果新主库的硬件配置明显低于老主库,可以考虑在切换后的前10分钟，把读流量全部导向从库，写流量限流50%，让新主库平稳度过缓冲期，这需要提前在网关层预留开关。
日常怎么演练才能真出事时不慌
季度一次“混沌演练”，这是底线，别只在测试环境玩，要直接在预发环境或低峰期的生产环境触发真实主库宕机。
具体演练清单
- 直接
poweroff一台主库，观察Orchestrator的判定和切换时间 - 拔掉主库网线,模拟网络分区，看会不会发生“脑裂”导致双主
- 在主库上疯狂写入数据制造延迟,然后在延迟期间触发切换，检查数据丢失量
- 切换完成后,手动将旧主库重新加入集群，验证数据补交逻辑
演练结束后必须输出一份报告,包含切换耗时、数据丢失行数、业务报错量。把报告发给业务方看，让他们知道“切不切换，切换多久”，是最有效的沟通方式。
常见的“切换伎俩”可能带来的错觉
有些人喜欢在看门狗里做“先杀进程再拉起”的假切，这不是真正的故障切换，真正的演练必须验证：
- 新旧主库的数据一致性
- 从库重新建立复制关系的成功率
- 应用连接池对旧连接的回收速度
- 监控告警是否能在一个周期内发出
数据库主库故障时业务如何快速切换：不同场景的差异化处理
上面讲的都是MySQL场景居多,不同数据库的故障切换逻辑差别很大，选错方案会直接导致切换时间拉长。
MySQL：用GTID简化一切
如果你还在用基于MASTER_LOG_FILE和MASTER_LOG_POS的传统复制，建议尽快升级到GTID模式，GTID模式下，从库重新指向新主库时不需要手动指定binlog文件名和位置点，Orchestrator和MHA的切换逻辑会简单很多，出错率也会下降不少。
Redis：必须有哨兵
Redis主从故障切换靠哨兵集群,难度比MySQL低一些，但要注意，哨兵部署数量必须是奇数且至少3个，否则无法形成多数派投票，切换时间通常控制在10秒以内。
PostgreSQL：使用Patroni
Patroni结合etcd或ZooKeeper实现强一致的高可用,切换精度比MySQL的异步复制方案更高，但运维复杂度也相应增加，如果对数据零丢失有硬性要求，只能选PostgreSQL的这种方案。
数据库主库故障不可怕,可怕的是没预案、没演练、没工具，核心思路就一句话：把切换变成一件不需要思考的事，自动化判断、自动化执行、自动化校验，人只做最终确认，这样才能做到真正的快速切换。
常见问题解答
数据库主库故障时业务如何快速切换，最容易被忽略的是哪一步？
最容易被忽略的是“切换后旧主库重新上线的处理”，许多人只关注故障时的迁移，却忽略了旧主库修复后如何安全地重新加入集群，如果旧主库的数据比新主库还旧，直接加回集群会导致数据回滚，正确做法是把旧主库当作一个新从库，先做全量备份然后重新初始化复制关系。
没有Orchestrator，手动切换需要哪几个步骤？
手动切换时,先锁定业务写入（可以用防火墙挡住写端口，或者关掉应用），然后在从库上执行STOP SLAVE; RESET SLAVE ALL;，接着把从库设为可写并记录其binlog坐标，最后把应用连接池指向新主库，再去其他从库上执行CHANGE MASTER TO，整个过程依赖人的判断，速度和质量无法与自动化工具相比，建议还是尽早部署开源工具。
云数据库自带的高可用和自建高可用哪个切换更快？
云厂商提供的RDS高可用通常能实现30秒内的自动切换,而且有SLA保障，但代价是数据和架构的封闭性，自建高可用则灵活可控，适合有独立机房或对数据主权有要求的团队，具体选哪个，取决于团队对“数据库高可用架构怎么选”这个问题的答案：追求省心选云，追求可控选自建。