凌晨1点47分告警电话把我叫醒。某业务系统的数据库主库宕了应用侧写入超时但等我登录管理端一看高可用组件显示“一切正常”——因为它只做了TCP层面的健康检查数据库进程还活着只不过已经假死所有新写入全部卡在锁等待上。那一瞬间我意识到数据库高可用这件事真正的瓶颈从来不在复制软件本身而在于你对故障的认知是否足够细。这篇文章我想把这么多年折腾数据库高可用的核心经验一次性捋清楚。不吹某个组件多牛也不推销某种架构就从故障本身出发讲清楚高可用到底在防什么、复制链路有哪些暗坑、自动选主为什么难、拓扑怎么选、切换时有哪些要命的细节以及为什么定期演练比任何架构文档都管用。适合正在做数据库选型、维护生产集群的开发和运维同学也适合想系统理解“高可用”这三个字背后代价的技术负责人。1. 高可用不是“多挂几个节点”先定义需求再谈架构1.1 两个数字决定所有技术选型RTO与RPO很多团队一上来就问我“我们用双机热备还是上分布式数据库”这个问题根本没法定量回答因为连目标都没定义。做高可用之前必须先回答两个数字RTO恢复时间目标和RPO恢复点目标。RTO是业务能忍受系统中断多久RPO是业务能忍受丢多少数据。举个直观的例子支付系统的RPO基本是0一分钱都不能丢RTO是秒级到分钟级而一个内部报表系统RPO可以是小时级RTO甚至能到半天因为报表晚出几个钟头没人会跳脚。这两个数字一旦定下来架构其实就八九不离十了。RPO接近0意味着你必须要同步复制或强同步复制异步复制直接排除RTO要秒级意味着必须有自动切换不能靠人半夜爬起来看监控。我见过最典型的一个反面案例某项目把可用性目标定成了“99.99%”但实际用的是一台单机加一个异步从库主库挂了靠人工切换RTO按小时算——这个目标从架构上就不可能兑现纯粹是写PPT用的。1.2 高可用和备份是两码事别混为一谈有个经常被混淆的概念高可用不等于备份。高可用解决的是“正在发生的故障”——进程挂了、机器挂了、机房断电了系统要在短时间内恢复服务备份解决的是“数据被删了之后怎么找回来”——某天某条SQL写错where条件把整张表清空了这种场景高可用集群一点忙都帮不上你只能靠备份和binlog做时间点恢复。这两个东西是互补关系但同时做齐的团队少得可怜。我见过不止一次集群高可用做得漂漂亮亮主从切换演练也通过了结果某次线上误删数据从库把删除也同步过去了主从一起丢——这时候再牛的自动切换都是白搭。反过来说日常备份做得再勤也不代表你能在10分钟内把业务恢复起来因为恢复还有加载数据、追日志、校验一致性的一整套流程。所以高可用和备份的投入不是二选一。正确的姿势是先确保有可恢复的备份再去做自动切换否则切换得越快丢数据的风险暴露得越早。1.3 “可用性99.99%”到底意味着什么做技术的人有必要把账算清楚。99.99%的可用性意味着一年累积停机时间不超过52.6分钟。这52分钟是包含所有故障、切换、发布窗口的不是说一年有52分钟的余量随便花。单台服务器年故障率按1%算是很乐观的估计——但这意味着一年有87.6小时的不可用距离99.99%差了十万八千里。很多人直觉认为“挂两台机器可用性不就翻倍了”——这个直觉是错的因为高可用系统的可用性是串行链路主库要挂、切换要成功、新主库要能接管每一步都有失败概率。而且切换本身不是零时间的探测要时间、选主要时间、数据追平要时间这些时间都会算进停机里。这也是为什么我特别反感那些在PPT上写“可用性99.999%”的方案。你连自己的故障恢复时长都没实测过凭什么写这个数字99.999%意味着全年停机不超过5.26分钟很多团队做一次完整的故障切换演练都不止这个时间。先实测再定目标这才是工程态度。2. 复制链路高可用方案的共同地基也是最容易翻车的地方2.1 从日志到回放复制的基本链路不管你是用开源数据库自带的主从复制还是用分布式数据库的多副本协议核心思路都是一样的把主库产生的变更记录下来传到其他节点在其他节点上重新执行一遍。以常见的关系型数据库为例主库写二进制日志binlog从库开一个IO线程把日志拉过来写到自己的中继日志里再由SQL线程按顺序回放。两条线程各干各的活从库落后的原因就可能出在任意一环拉取慢了、回放慢了、或者两者都慢。理解这条链路对排查问题非常关键。很多人在从库延迟的时候只会看“延迟多少秒”却不知道延迟到底是在传输环节还是在回放环节。传输慢通常是网络或者主库IO问题回放慢则可能是从库硬件性能不足、有大事务、或者从库上跑了不该跑的查询把资源吃光了。2.2 异步复制的延迟陷阱半同步救不了所有场景异步复制最大的风险在于主库提交事务成功后日志还没传到从库主库直接宕机那这部分数据就丢了。RPO直接变成“未知”——可能是0可能是几秒钟的数据量完全取决于当时主从之间差了多少。半同步复制就是为了压缩这个窗口主库在提交事务之前至少要等一个从库确认收到日志才返回客户端成功。但这里有两个容易被忽视的坑。第一个坑是“收到”不等于“回放完”从库只是把日志写进了自己的中继日志还没apply到数据文件里。如果此时从库也挂了或者切主之后回放失败数据还是可能不一致。第二个坑更隐蔽半同步复制在主库等待从库确认期间所有写入都会被阻塞从库越慢主库的延迟越高。如果从库长时间无响应半同步会退化回异步模式——很多系统的半同步是“探测到从库掉线就自动降级”的降级那一刻RPO瞬间从“秒级窗口”变成“未知”而监控往往没告诉你这件事。我之前在一个系统上踩过这个坑半同步配置了但没监控“是否处于降级模式”。某段时间从库磁盘故障半同步悄悄退回异步主库一切正常谁都没注意到。等主库真的挂了数据丢了大概几十秒的量业务方完全不能接受——因为当初承诺的就是“最多丢一条”。2.3 双节点还是三节点多数派的直觉误区主备架构最常见的形态是两台机器一台主、一台备。问题来了当主库挂了备库要升为主库但它怎么确认主库真的挂了如果只是网络抖动备库联系不上主库就自己升主了然后原主库恢复后也在继续接受写入——两个节点同时都在写数据就分叉了。两节点系统防不了这种情况因为没有仲裁者。所以稍微严肃一点的高可用方案都会引入第三节点或者一个独立仲裁服务。选主要走多数派三节点里至少两个同意才能选出新主。这样即使一个节点和另一个失联它也不可能拿到多数票自然无法独自升主。但多数派方案的代价是可用性下降如果三个节点里挂了一个剩下的两个还能集齐多数票如果挂了两个剩下的那一个孤掌难鸣整个集群就没法定主了——系统确实没脑裂但它也不服务了。这就是分布式系统里那个经典的选择要强一致CP还是要高可用AP。对数据库这类有状态系统来说CP通常是底线宁肯短暂不可用也不能两个主一起写否则对账对到怀疑人生。3. 自动选主与脑裂高可用系统的真正分水岭3.1 为什么人工切换慢而自动切换难人工切换为什么慢不是因为人动作慢而是因为人在做决策前需要收集信息、评估风险。得先登录机器看进程、看负载、看复制延迟还要确认备份是否完整然后才会去执行切换动作。群里讨论一圈半小时就没了。账期敏感的业务根本等不起这个时间。自动切换的难点在于把人类这种“基于不完整信息做风险决策”的能力压缩成一套确定的算法。你要在几秒内判定“主库是彻底挂了还是只是慢”要决定“从库的延迟多少以内可以接受升主”还要处理“原主库的日志还没送完”这种谁都没法精确判断的边界情况。自动切换做得激进误切换的概率就高做得保守该切换的时候又切不动。这个度是每个高可用系统都要反复调的核心参数。3.2 隔离与租约防止两个节点都觉得自己是主防脑裂的思路大体上有两类一类是“谁能联系上多数派谁说了算”另一类是“拿到租约才有资格干活”。租约机制很像现实世界里的工作证主库持有一张有效期内的证件定期去仲裁中心续期。网络分区一旦发生备库和仲裁中心之间的通道如果还通着备库会等主库的租约过期然后才申请新租约升主。主库因为联系不上仲裁中心续不了约自己的工作证过期以后它就知道自己不再是法定主库了会主动停止接受写入。这样两边就不会同时认为自己是主的。但在生产环境里租约有一个经典漏洞如果主库的租约有效期设置过长那么分区发生时备库要等租约超时才能接管RTO就被拉长了如果设得太短网络稍微抖一下主库就续不上约被强制降级引发不必要的切换。租约时长的调优必须结合你实际的网络状况没有通用的推荐值。另一路更暴力的思路是隔离fencing切换前先把旧主节点的网络断开或者直接强制关机确保它不可能再接受写入。从技术上来说先隔离再接管比单纯靠租约更保险但操作门槛也更高——因为你得有办法对那个“疑似故障”的节点做强制操作而它可能正处于一种很诡异的状态。3.3 一个典型的脑裂案例网络分区下的双写我把之前处理过的一个案例简化一下帮助理解脑裂的实际危害。某系统是经典的主从复制加自动切换切换脚本会检测主库进程是否存活。那天下午机房的网络设备出现间歇性丢包主库和从库之间的网络中断了但从库到应用服务器的网络还通着。自动切换脚本判断主库“不可达”就把从库升成了新主。但问题是原主库进程根本没挂它只是和从库失联了。原主库继续接受应用服务器的写入新主也在接受写入。等到网络恢复两边开始同步日志冲突数据哗啦啦一片。那一整天开发团队都在对数据、找差异最后实在理不清楚的只能按业务日志人工回滚。这个案例里切换脚本的决策条件只有一条——“主库是否可达”却没有做链路隔离也没有确认旧主的进程状态。真实环境的故障往往是复合的网络抖动触发切换切换动作本身又放大了故障。所以我现在给团队定的规矩是任何自动切换方案必须把“确认旧主已经不能写”作为一个强制前置步骤而不是可选项。4. 落地拓扑怎么选从主备、读写分离到多活4.1 主备架构最朴素也可能最可靠但别让备库吃灰主备架构是最常见的高可用形态。一主一备备库实时同步主库的数据但不承接读流量。主库挂了备库顶上。它的最大优点是简单切换路径清晰几乎没有脑裂风险前提是你要做好“确认旧主已死”这一环。但主备架构有两个常被忽视的维护要求。第一备库必须定期做数据校验否则你根本不知道备库的数据是不是已经悄悄地不一致了。很多团队备库建好之后三年不碰等要切换的时候才发现备库的复制早就断了主备已经差了半个月的数据。第二备库要不要承载读流量要想清楚。我见过一些团队为了“不浪费”备库的资源把报表查询之类的只读业务放到备库结果某次报表任务把备库CPU打满复制回放跟不上主备延迟飙到几千秒。真到切换的时候备库追平数据的时间长得让人绝望。4.2 读写分离读扩展的手段不是高可用的护身符读写分离是主备架构的自然延伸主库处理写入多个从库分摊读流量。适合读多写少、对一致性要求不苛刻的业务。这里最经典的问题是“刚写入就读不到”。写了一笔订单刷新页面订单不见了——因为请求被路由到了还没同步完的从库。解决思路有几个关键接口强制走主库、写入后短暂地按用户维度把读请求固定到主库、或者业务层做标记用版本号判断数据是否已同步。没有银弹得按业务场景组合着用。另外要提醒的是读写分离提升的是读扩展能力而不是可用性。从库也是单点挂一个从库如果你没有及时把流量摘掉应用就会报错。主库挂了从库虽然可以顶上但你依然要经历切换流程。所以不要以为上了读写分离就“高可用”了它只是多了几个备选节点真正的切换逻辑还是那套。4.3 多活的诱惑与代价不是所有业务都撑得起双活、多活的吸引力在于“两个机房都在干活资源不浪费挂了还能互相接管”。但仔细拆解一下代价是实打实的。同城双活两个机房之间的网络延迟大概在1-2毫秒这个延迟对多数业务可以接受所以可以在数据库层做双向同步或者让应用按单元划分流量。但跨地域的多活就不是了网络往返延迟几十毫秒起步强同步根本做不了只能用异步复制一旦灾难发生数据丢失量是“秒级”的而且跨机房数据冲突的解决复杂度爆炸。我见过最务实的多活方案是单元化按用户维度把流量切到不同机房每个机房只写自己的那份数据跨机房的用户数据通过异步消息对账。这种架构对业务改造的要求很高不是从运维侧配置一个双向同步就能搞定的。如果你的业务还没到那个规模老实做“同机房高可用异地域容灾备份”性价比高得多。4.4 分布式数据库给了新选项但选型要克制新一代分布式数据库把复制、自动选主、切换这些都做到了引擎内部多副本、多数派协议、应用连接的是集群入口主库挂了它自己选新主。对应用来说确实省心很多。但分布式数据库不是免费的午餐。写放大、分布式事务开销、对网络延迟的敏感都是要吸走一部分性能的。选型的时候要做充分的压测和故障注入测试尤其要观察它在网络抖动下的行为。我见过有团队为了“省事”迁到分布式数据库结果业务场景其实是纯单机就能撑住的读多写少白白付出了两三倍的硬件成本和更高的运维复杂度。选型要克制先想清楚你的痛点到底是单机撑不住、还是需要自动切换、还是需要跨地域容灾——不同的痛点对应完全不同的解法。5. 切换流程中的工程细节决定高可用能否兑现5.1 健康探测TCP通不等于是活的高可用组件怎么判断一个数据库节点是健康的最偷懒的办法是测TCP端口端口通就认为活着。但这个办法有个巨大的漏洞端口通不代表数据库能干活。进程可能还在但线程池耗尽了每个连接都卡在等待上也可能是磁盘满了所有写入挂起还可能是某个大事务把行锁吃住后续写入全部排队。TCP探测对这些场景一律“眼瞎”。往上一个层次是用轻量查询做探活比如执行“SELECT 1”。但“SELECT 1”也有局限——它不经过事务、不写日志一旦触发的是写入相关的问题它照样表现正常。更严谨的做法是设计一个能反映核心业务写入链路的探活语句比如往一张心跳表里插入一条记录并读取回来。但是探活语句也不能做得太重。之前有个项目的高可用组件探活逻辑复杂到每秒钟做一次插入加查询加删除结果数据库负载被监控本身拉高还引发了又一次故障——高可用组件把自己搞成了故障源讽刺至极。健康检查的频度和深度要找到一个平衡点既要能发现假死又不能成为新的负担。5.2 流量切换的三种姿势各有各的坑探测到主库故障之后怎么把连接切到新主上常见有三条路。第一是VIP漂移把虚拟IP从旧主挪到新主应用连接的是VIP不用改配置。这是最简单的方式但有一个常见的坑交换机或客户端的ARP缓存不会立刻更新切换后可能一部分流量还在往旧IP上打。需要在切换后主动发送 gratuitous ARP并且观察一段时间才能确认整个网络层的收敛。第二是DNS切换把域名解析指向新主。问题在于DNS有TTL缓存客户端可能还在用旧IP连接旧主重试机制做得不好的应用直接报错。适合能容忍分钟级切换延迟的场景。第三是通过连接层/中间件代理应用只连代理代理背后维护真实的主从关系主库切换后代理自动把写流量转到新主。这种方式对应用最透明但代价是代理本身成了新的关键组件——如果代理挂了呢所以代理必须要做集群这又引入了一层复杂度。实际项目中我会优先建议VIP或者代理方案。DNS方案除非业务对切换时间不敏感否则别作为主切换通道。5.3 数据追平与补偿切换后最容易被忽略的一步自动切换完成后业务恢复了很多团队就觉得万事大吉。但真正的麻烦刚刚开始旧主恢复之后怎么办如果旧主只是进程崩溃磁盘还在它的日志里可能还有一部分没有传给从库的数据。直接把旧主重新挂回集群很可能导致数据冲突。正确做法是把旧主设置为一个新节点先让它从新主补齐日志并且做一轮数据校验确认两边一致以后再恢复它的读写或者干脆把它降级为从库。这个过程在切换后的高负载期做起来非常痛苦因为新主本身还在扛业务流量。更麻烦的是数据补偿。切换期间应用为了重试可能重复提交了一些请求旧主上写入了一部分、新主上也写入了一部分两边都需要人工梳理。这就凸显了业务层幂等设计的重要性如果请求本身带了幂等键数据库层做唯一约束那么切来切去都不会产生重复数据。高可用从来不只是数据库层的事应用层配合好切换才真的安全。6. 定期演练与故障复盘高可用唯一可靠的落地方式6.1 故障注入要分级别演练不能走过场我见过最没用的演练是这样的运维提前写好方案挑业务最低峰把流程公告天下然后按脚本一步步执行就像演戏。全程无意外自然也就暴露不了问题。这种演练唯一的意义是让汇报PPT上多一行“已进行双节点切换演练”。有效的演练应该分几个层次从温和到暴力慢慢加码先做进程级故障注入直接kill主库进程再做网络级故障注入用工具切断主库的网络链路最后做资源型故障注入把磁盘灌满、触发海量慢查询。关键是演练的时候不要提前太久通知参与者让值班的人像处理真实故障一样去面对。只有当你真正被人从睡梦中叫醒手忙脚乱地打开电脑去处理的时候你才会发现文档里那些“步骤详实”的操作手册在压力下有多难读。6.2 复盘不要只问“为什么挂”更问“为什么没兜住”故障复盘最常见的错误是花80%的精力去讨论“数据库为什么还活着的时候突然挂了”却只留20%的时间讨论“为什么高可用体系没有在第一时间把损失控制住”。任何数据库都会挂。硬件会坏软件有bug人为操作会失误。高可用的价值不在于让数据库永远不会挂而在于挂了以后系统还能不能继续服务、数据还能不能保持一致、多久能恢复。所以复盘的时候先问三个问题从故障发生到切换决策完成花了多久这个时间花在哪里哪些等待是不必要的切换之后数据有没有丢失如果有是哪一层设计导致的我经历过最值回票价的一次复盘就是发现切换之后新版应用连接新主库竟然报权限错误——因为新主库的账号权限和旧主库差了一个配置项。这个问题如果在演练里不暴露线上真实发生的时候可能比数据库挂掉本身还要致命。6.3 一点个人经验关于复杂度做了这么多年高可用相关的事情我最大的体会就是复杂度是最大的敌人。一个方案如果能用双节点加确定性脚本解决就不要为了“先进”去上三节点共识集群能用一个成熟的开源复制方案搞定就不要自己写一套同步逻辑。高可用系统的每一个组件本身都是一个故障点。高可用组件挂了的概率比数据库挂了的概率要低但并不是零。所以任何高可用方案都一定要考虑“如果高可用组件自己挂了怎么办”这个退路。最基本的退路是所有数据库节点本身的配置要一致关键时刻可以退化成人工切换而且人工切换的步骤一定要写在非常显眼的地方不能藏在一个六个月没人打开过的文档里。最后再分享一个细节记得定期检查你的备份是否能真正的恢复。第一次演练恢复备份的时候我最深的感触是——无论高可用方案做得多完美如果你连一个干净可靠的备份都没有所有的自动切换都是空中楼阁。把这些基础的功课做好高可用才不是一句口号。