数据库主备还是双活，差别在切换那几秒

主备和双活的差别，真不在架构图画得漂不漂亮。监控大屏上永远是两条绿线，出事那几秒才见真章——数据库主备还是双活差别在切换那几秒，这句像绕口令的话，恰恰是选型时最该先问的一句。机器多画两台不稀奇，切换窗口里业务是抖一下还是直接趴下，才决定这套架构值不值那个钱。

数据库主备还是双活差别在切换那几秒，差的是这三样

我把这事拆成三样：断多久、丢不丢、扛不扛得住。断多久是 RTO，从主库咽气到应用重新能写，中间隔着健康检查的判定、VIP 漂移、从库提升、连接池重建，每一环都吃时间。丢不丢是 RPO，同步复制还是异步复制，差的那点延迟平时看不出来，切换那一秒就是几笔订单的区别。扛不扛得住最容易被忽略——原来两台机器分着干的活，现在全压一台，CPU、连接数、慢查询一起冒头，你切过去了，可服务是半死的。

主备切换那几秒，业务端感受到的是什么

站在业务这边，切换从来不是数据库内部的事。连接池里那批已经建好的连接不会自己知道主库换人了，它们继续往老地址发写请求，报错、超时、重试，重试再砸到还没站稳的新主上，一套连环。长事务更麻烦，切的时候正在跑的那些要么回滚要么悬着，回滚完了日志里一片红。所以我一直觉得，切换预案里必须写清楚应用层怎么配合：连接池要么整体重启要么配好校验，重试要有上限，写接口最好做成幂等，不然一次切换能顺手给你造出一批重复数据。

双活不是没有切换，是把切换摊到了平时

双活听着像是没有切换，其实它把切换的成本挪到每一天。两边都能写，就得处理冲突：自增主键撞车、唯一索引打架、同一个手机号在两台机器上被同时注册。为了这些事你要加分段 ID、要定写入归属、要做定期的一致性校验，还得防脑裂——网络一抖两边都以为对方死了，各自升格当主，那场面比单点故障难收拾多了。机房之间那条链路延迟也会实打实落到事务提交上，越远越明显。

钱也是这么花出去的。主备的钱花在一次性的硬件和定期的演练上，双活的钱花在链路、在中间件、在写冲突的代码改造、在每个月的对账脚本上。规模不大、写入不密集的业务，硬上双活大概率是自己给自己找活干。反过来，跨地域、读多写少、可用性要求咬着牙不放的场景，读写分离再加双活副本才划算。这里没有标准答案，只有你愿意为那几秒付多少。

切过去之后谁来扛量，画图的时候就得写死

不少切换失败不是败在数据库，是败在没人算过新主的上限。原来两台机器各扛一半连接，切完一台顶两倍；缓冲池不够、慢查询堆起来、连接数打满，前端看到的是能连上但特别慢，这比直接报错还难查。画架构图的时候就把这些写死在文档里：切过去之后预期多少并发、连接数上限调到多少、哪些非核心功能先关掉降级。这些话不落在纸上，出事那晚没人敢拍板。

切换脚本里最容易漏的几行

切换脚本我见过写得最敷衍的版本，就两行：停老库、升新主。缺的东西能列一长串——从库是不是真追上来了（延迟没消就切等于主动丢数据）、只读属性有没有清、复制关系怎么重建、应用配置或者 VIP 什么时候指向新地址、缓存里那些旧数据要不要清掉、老主恢复之后是降级当从还是先隔离观察。还有切回：新主也出问题的时候，你敢不敢切回去，条件是什么，得提前写死，别在现场临时讨论。

演练这件事，频率比方案本身重要。半年不练一次的切换脚本，真到用的时候大概率卡在某个权限或者某个路径上。演练也不用搞得多正式，挑个低峰时段把流程完整走一遍，把每一步的耗时记下来，看看那几秒到底花在哪儿。顺手把值班的人换一换，让没写过脚本的人照着文档操作一次——文档里那些只有作者自己看得懂的省略，就是这么被翻出来的。

一套能照着走的检查清单

自己对着过一遍：切换由谁决定、判定条件是什么（别用一句感觉不行了就切）；RTO 和 RPO 有没有明确数字并且应用方点头认下；新主的容量余量够不够；连接池、缓存、重试、幂等这几处应用侧改动做了没有；回滚条件和切回步骤写没写；演练记录和耗时留没留档；监控里有没有专门盯复制延迟和老库状态的告警。这几条缺两条以上，就别在评审会上说自己这套算高可用。

回到那句话——数据库主备还是双活差别在切换那几秒，选型的时候别只盯着架构图上的箭头看。先问自己一个问题：那几秒里，业务是能容忍转圈，还是必须无感？答案清楚了，方案基本也就定了。至于买到什么程度的高可用，市面价钱差得挺远，具体规格和计费还是以服务商官方页面说明为准，别拿别人家的报价单往自己的场景上套。