📌 关键词：高可用数据库、数据库高可用方案、高可用数据库架构、数据库容灾、数据库主从切换、两地三中心、国产数据库
大家好！我是数据库小学妹 👋
上周和做运维的朋友聊天，他吐槽："前几天他们的生产数据库挂了，业务停了快两小时，老板问为什么没有高可用方案……"
说实话，很多团队在业务初期都顾不上高可用，觉得"数据库能跑就行"。等到真出了事，才发现手忙脚乱补方案的代价远比提前规划大得多。
今天就来聊聊数据库高可用架构怎么搭。不是一上来就搞最复杂的方案，而是从最简单的主从复制开始，一层一层往上加，每一层解决什么问题、踩什么坑，掰开了讲。
一、先搞清楚：高可用到底在保什么？
高可用的核心就两个指标，RPO和RTO。
RPO（Recovery Point Objective）是"能丢多少数据"。RPO=0意味着不允许丢任何一条数据，RPO=1小时意味着最多丢1小时的数据。
RTO（Recovery Time Objective）是"能停多久"。RTO=30分钟意味着故障后30分钟内业务必须恢复。
不同业务对这两个指标的要求差异很大。一个内部OA系统，停两小时问题不大；但银行的核心交易系统，停几分钟就是事故。搞高可用之前，先想清楚你的业务到底需要什么级别的保障，别一上来就上最贵的方案。
二、第一层：主从复制，最基础的保障
主从复制是高可用的起点。一台主库（Master）负责读写，一台或多台从库（Slave）实时同步主库的数据。主库挂了，从库上有数据副本，不至于丢数据。
大部分团队的第一套高可用方案都是从主从开始的，简单、好理解、上手快。
踩坑点
主从延迟是老大难。 从库重放binlog的速度跟不上主库写入的速度，延迟就产生了。业务高峰期延迟几秒甚至几十秒很常见。如果你的读请求路由到了从库，用户刚写完的数据可能读不到，客服电话就来了。有些数据库产品针对这个问题做了优化，比如KESKES用WAL日志并行回放技术，备库的日志应用速度能快不少，事务吞吐大概能提升一半，算是从产品层面缓解了延迟的老毛病。
手动切换太慢。 标准的主从复制不带自动故障转移。主库挂了，得DBA手动把从库提升为主库，再改应用的连接配置。整个过程少则十几分钟，多则半小时以上。很多团队都是在这个环节翻车的——不是不会操作，是半夜三点没人值班。
数据可能丢。 异步复制模式下，主库写完就返回成功，binlog还没来得及传到从库。如果这时候主库硬盘坏了，这部分数据就丢了。半同步复制能缓解这个问题，但会增加写入延迟。
三、第二层：故障自动切换，从人工到自动
手动切换太慢，那就让系统自己来。故障自动切换的核心是：主库挂了，系统能在几秒到几十秒内自动把从库提升为主库，应用几乎无感知。
MySQL方面，MGR（MySQL Group Replication）和Orchestrator是比较成熟的方案。商业数据库一般自带高可用组件。
踩坑点
脑裂是最危险的坑。 网络抖动的时候，集群可能误判主库"挂了"，把从库提升为新主库。但原来的主库其实还活着，两边同时写入，数据就乱了。防脑裂需要多数派投票机制，至少要三个节点。很多团队为了省成本只部署两个节点，结果在网络分区的时候吃了大亏。做得好的方案会把仲裁逻辑内置到集群本身，不需要额外搭第三方仲裁组件。比如KESKES的高可用集群用的是自仲裁、自选主协议，2N+1容错，网关仲裁保证任何故障场景都不会脑裂，部署上少操不少心。
切换不是万能的。 自动切换能处理数据库进程崩溃、服务器宕机这些场景，但如果是存储层出问题（比如磁盘满了、IO卡死），切换可能不生效，因为新主库用的还是同一套存储。
连接池要配合改。 数据库切换了，应用的连接池不一定能自动感知。如果连接池没有做故障检测和自动重连，切换完了应用还是连着旧主库的地址，照样报错。这个问题的解法之一是VIP漂移：集群切换时把虚拟IP自动绑到新主节点上，应用连的是VIP而不是物理地址，切换全程不用改连接配置。KESKES的集群就支持这个能力，配合自仲裁机制，整套切换流程对应用基本透明。
四、第三层：同城双活，跨机房的保障
单机房的高可用有个硬伤：机房级别的故障（断电、空调坏了、网络中断）一来，主从都在同一个机房里，一起挂。
同城双活是在同城部署两个机房，各有一套数据库集群，数据实时同步。一个机房出问题，另一个机房能接管业务。
踩坑点
跨机房延迟。 同城机房之间的网络延迟一般在1-5毫秒，听起来不多，但对于高并发写入场景，每笔事务都多几毫秒的延迟，累积起来吞吐量会明显下降。
数据一致性怎么保证。 同步复制保证了一致性，但性能损耗大；异步复制性能好，但有丢数据的风险。这个取舍没有标准答案，得看业务能接受什么。现在有些产品提供了一种折中方案，比如KESKES的"最大可用"模式：正常情况下走全同步复制保证数据零丢失，一旦同步链路异常就自动降级为异步，优先保住业务连续性，等链路恢复再切回全同步。比起非此即彼的选择，这种自适应的策略在实际生产里更务实。
流量怎么切。 平时两个机房各跑一部分业务，出了故障要把流量全切到一个机房。DNS切换慢（分钟级），负载均衡切换快（秒级），但配置复杂。切的过程中正在执行的事务怎么办，切完之后数据怎么追平，每一步都要提前演练。
五、第四层：两地三中心，最高级别的保障
同城双活防的是机房级故障，但防不了城市级灾难（地震、洪水、大面积停电）。两地三中心是在两个城市部署三个数据中心：同城两个（一主一备，同步复制）、异地一个（异步复制）。
这是金融、能源、政务这些关键行业的标配方案。
踩坑点
成本高得离谱。 三套数据中心的硬件、带宽、运维人力，不是一般企业能承受的。很多中型企业上了两地三中心之后发现，光运维成本就吃掉了大部分预算。
异地延迟没法绕。 跨城市的网络延迟少则十几毫秒，多则上百毫秒。异步复制意味着异地中心的数据是滞后的，真出了城市级灾难，丢几分钟到几小时的数据是常态。
演练比建设更重要。 两地三中心搭好了不演练，等于没搭。切换流程、数据追赶、业务验证，每一步都要定期真刀真枪地练。我见过有企业花了大价钱搭好两地三中心，三年没演练过一次，真出事的时候切不过去。
六、KESKES的高可用方案
上面四层是通用的架构演进思路，具体到国产数据库怎么落地，KESKES的做法值得看看。
KES的高可用方案是按需叠加的。最基础的是主备集群，一主一备或者一主多备，同步复制保证数据不丢。往上叠加读写分离，主库负责写、备库负责读，吞吐量跟着提升。再往上是共享存储集群（KingbaseES RAC），多个节点共享同一份存储，所有节点同时对外提供读写服务，可以做到RPO=0、RTO小于30秒，甚至小于10秒。
这套方案在实际项目里跑得怎么样？
运营商领域，某大型运营商的一级BOSS枢纽系统连接了全国31个省的BOSS系统，部署了六套KES高可用集群，可用性做到了99.999%以上，故障切换不到30秒。海南移动的O域核心故障管理系统用KES搭了同城双中心容灾，专门应对台风等极端天气，系统可用性达99.999%，响应能力到了毫秒级。
金融领域，绍兴银行的信贷风险管理系统采用KES的读写分离集群加异构双轨并行架构，兼顾了高并发和高安全。中国大地保险的核心系统验证了国产数据库在保险核心业务上的高可用能力，已经有20多个业务系统完成了升级。
KES还有一个比较实用的特点：集中式和分布式用的是同一套内核。企业可以先用主备集群起步，后面业务涨了再叠加读写分离或者共享存储集群，不用换产品、不用改代码。对于不想一步到位上复杂方案的团队来说，这种渐进式的路径比较稳妥。
七、怎么选？先回答两个问题
你的业务能停多久？
几分钟都停不了：至少要到第三层（同城双活），配合自动故障切换。银行、支付、运营商的核心系统基本是这个级别。
停一两个小时能接受：第二层（自动故障切换）就够了。大部分互联网业务、企业内部系统在这个区间。
停半天一天问题不大：第一层（主从复制）加上定期备份就行。开发测试环境、内部管理系统适用。
你的预算和运维能力到哪一层？
高可用的每一层都在加成本和复杂度。主从复制多一台服务器就行，两地三中心要三套数据中心加专线加专职运维团队。别超出自己的运维能力硬上，搭了管不了比不搭更危险。
总结
数据库高可用不是一步到位的事。主从复制解决数据副本问题，自动切换解决人工操作慢的问题，同城双活解决机房级故障，两地三中心解决城市级灾难。每一层都有对应的代价，选错了要么浪费钱，要么保不住。
如果你用的是国产数据库，KESKES的渐进式高可用方案可以关注一下。从主备集群到读写分离再到共享存储集群，按需叠加，不用换产品。在运营商和金融行业的核心系统上，99.999%的可用性和秒级切换已经跑出来了。
搞高可用最怕两件事：一是不搞，觉得不会出事；二是搞了不练，觉得搭好就行。提前规划、定期演练，比出事之后补方案划算得多。
我是数据库小学妹，大家在数据库高可用架构搭建中，有没有遇到过什么坑？欢迎评论区聊聊~
本文基于技术学习和实践经验撰写，旨在分享数据库高可用架构的搭建思路。
