各位好，我是路远。

去年给一个制造业客户做数据库架构评审。他们的核心业务系统跑在单机Oracle上，数据量不大，大概两百个G。但业务方要求全年可用性不低于99.99%。

单机架构，99.99%，这两个条件放一起就是个伪命题。一台机器挂了，整个系统就停了。全年停机时间不能超过53分钟，单机根本做不到。

客户问我怎么改。我说方案有好几种，但不是每种都适合你。选错了，要么花了钱没解决问题，要么运维复杂度直接把团队压垮。

今天把主从复制、共享存储集群、分布式拆开讲。每种方案解决什么问题，适合什么场景，坑在哪。最后给个选型决策框架，各位可以直接对照自己的业务来选。

先搞清楚：三种方案解决的是不同问题

很多兄弟把高可用当成一个概念。其实主从复制、共享存储集群、分布式解决的是完全不同的问题。

主从复制解决的是"主挂了谁来接"，核心是故障切换。共享存储集群解决的是"一台机器扛不住怎么办"，多节点分担负载，故障秒级转移。分布式解决的是"数据太大一台放不下"，把数据拆开，分而治之。

选方案之前，先搞清楚瓶颈在哪。怕宕机、怕扛不住、数据量太大，解法完全不一样。

一张表看清楚：

维度	主从复制	共享存储集群	分布式
故障切换时间	秒级~分钟级	秒级以内	秒级（取决于副本数）
数据一致性	取决于同步模式	强一致（共享存储）	最终一致或强一致
资源利用率	从库平时闲置	所有节点均可服务	所有节点均可服务
运维复杂度	低	中	高
适用数据量	TB以内	TB级	TB~PB级
成本区间	低	中	高

【建议配图：三种架构的拓扑对比图，左侧主从、中间共享存储、右侧分布式分片】

主从复制：最成熟，但有天花板

主从复制是用得最多的高可用方案。原理简单，主库写入，从库同步。主库挂了，从库顶上。

Oracle时代的Data Guard，MySQL的主从复制，国产数据库的主备方案，走的都是这条路子。

优势是成熟、简单、好维护。大部分DBA都能搞定。出了问题排查路径清晰，从日志到复制延迟到切换状态，都有成熟的工具链。

但天花板也很明显：

• 从库只负责同步，平时不承担业务。资源浪费。
• 切换有时间窗口。主库挂了到从库接管，中间有几十秒到几分钟的中断。
• 读写没分离。所有请求都打到主库上，主库压力大了，从库帮不上忙。

还有一个容易忽略的问题。同步复制能保证数据零丢失，但写入性能会打折扣。我之前在一个金融项目里，同步复制模式下主库TPS直接掉了三成。后来改成半同步，高峰期用异步，才把性能拉回来。

# PostgreSQL/KES 同步复制关键参数示意
synchronous_standby_names = 'node2'   # 指定同步从库
synchronous_commit = on               # on=同步，remote_write=半同步

选主从复制，同步还是异步，这个得根据业务容忍度来定。核心指标就两个：

• RPO（数据丢失容忍度）：要求零丢失就用同步复制，容忍秒级丢失用异步
• RTO（中断时间容忍度）：主从切换一般15~30秒，配自动failover可压到10秒以内

金仓KES的主备集群方案在这个层面做得扎实。支持同步复制，数据零丢失。故障切换在30秒以内。对于大部分中等规模的业务，这个方案性价比很高。

共享存储集群：Oracle RAC的思路，国产库也能做

各位做Oracle出身的应该都熟悉RAC。多个实例共享同一份存储。任何一个节点挂了，其他节点自动接管。业务几乎无感知。

这是共享存储集群的核心思路。多节点、共享数据、自动故障转移。业务连接到集群的虚拟IP，底层哪个节点响应对应用完全透明。

相比主从复制，优势很明显：

• 所有节点都能处理请求，不浪费资源
• 故障切换更快，数据就在共享存储上，不用等同步
• 扩展相对简单，加一个节点就能分担压力

但限制也很明显。共享存储是单点——存储挂了，所有节点都完蛋。所以存储本身必须做冗余（RAID 10 + 双控制器是基本配置）。另外，节点之间的高速互联网络是关键。延迟高了，集群性能会断崖式下降。

对做过Oracle迁移的兄弟来说，这一点太重要了。我之前有个项目，从RAC迁到一个只支持主从的国产库。连接方式全部推翻，负载均衡策略重写，故障转移逻辑改了一遍。光这个改造就花了三个月，业务还中断了两次。

不是换个数据库那么简单。整个应用架构都得动。

金仓KES支持共享存储集群部署。这在国产数据库里是比较少见的能力。多数国产库只支持主从。从RAC迁过来，架构层面不需要做大调整，应用端基本不用改。光这一项，在信创项目里就能省下几个月的工期。

关键参数参考：

指标	建议值	说明
存储类型	全闪存阵列	IOPS不低于5万，延迟亚毫秒级
节点间互联	10Gbps以上	延迟控制在1ms以内
故障切换时间	5秒以内	远快于主从复制的15~30秒
存储层冗余	RAID 10 + 双控	有条件做存储双活

【建议配图：共享存储集群架构图，展示多节点+共享存储+VIP的拓扑】

分布式：数据量到了才需要考虑

分布式数据库把数据拆成多个分片，分布在不同节点上。每个分片可以有多个副本。

适合的场景很明确：单机存不下，或者单机的写入性能扛不住。比如几亿条记录的订单表，每天几千万笔交易。

但分布式不是万能药。跨节点查询比单机慢，一条涉及多个分片的JOIN，网络往返开销就吃掉大半延迟。分布式事务也难处理，两阶段提交的协调开销不小。更麻烦的是运维，监控告警、数据一致性、分片策略，每个都是坑。

我之前见过一个项目，数据量其实没到必须分布式的程度。老板听了厂商的方案演示，觉得分布式听起来很厉害，直接拍板上了。结果DBA团队从3个人扩到8个人。光是监控告警就搞了两个月。分片键选错了，按用户ID哈希，结果大客户的订单集中在几个分片上，数据倾斜严重，有些节点CPU打满，有些还很空闲。后面想改分片键，停了一天业务才迁移完。

说白了，没到瓶颈别上分布式。

还有一个中间选项容易被忽略——读写分离。读多写少的场景，加几个从节点做读写分流。比直接上分布式稳得多，复杂度低一个量级。

数据主权和自主可控这两个点，在分布式架构里更关键。数据分散在多个节点上，底层架构必须是可信的，数据不出域。信创场景下，这一点是硬要求。

金仓KES也支持分布式部署。从主备集群到共享存储集群再到分布式，用的是同一套内核。这意味着业务量增长的时候，可以逐步升级架构，不用换产品。对长期的技术投入来说，这个路径很重要。

选型决策框架

选高可用方案，搞清楚五个问题就够了。

回到开头那个制造业客户。两百个G的数据，单机完全够。瓶颈是怕宕机。我最初想的是主从复制，便宜好维护。后来仔细算了笔账，99.99%意味着全年停机不能超过53分钟，主从切换最快也要十几秒，加上故障检测的时间，一年切换两三次就超标了。最后建议共享存储集群，两个节点互为备份。

各位在做选型的时候，也可以用同样的思路。

第一个问题：数据量多大？ 几十G到几百G，单机完全够用。到了TB级别，考虑分库分表或者分布式。

第二个问题：能接受多长的中断？ 能接受几分钟，主从复制够了。要求秒级切换，考虑共享存储集群。要求零中断，得上多活架构。

第三个问题：团队运维能力怎么样？ 主从复制大部分DBA都能搞定。共享存储集群需要有经验的运维。分布式对团队的要求更高，DBA团队至少要扩充一倍。

第四个问题：未来两年业务增长预期？ 如果数据量预计翻三倍以上，现在就得规划分布式。增长平稳的话，先用共享存储集群，后续再升级。别等架构撑不住了再临时换，迁移成本比选型成本高十倍。

第五个问题：从Oracle迁移过来，架构改动有多大？ 如果原来是RAC架构，迁到只支持主从的国产库，改造成本很高。KES支持共享存储集群，在这个场景下有天然优势。

【建议配图：选型决策流程图，从数据量→中断容忍→运维能力→增长预期→迁移兼容性，逐步收敛到方案推荐】

场景	推荐方案	关键考量
数据量小，怕宕机	主从复制	成本低，运维简单
数据量中等，要求秒级切换	共享存储集群	资源利用率高，切换快
Oracle RAC迁移	共享存储集群	架构兼容，改造少
读多写少	读写分离	中间方案，复杂度低
数据量大，写入密集	分布式	需评估团队能力

避坑清单

高可用不等于零故障。监控得配，备份得做，演练得跑，一个都不能少。以下是按方案分类的避坑点。

主从复制常见坑：

• 切换脚本半年没跑过，真出事的时候手忙脚乱。切换测试要在业务低峰期做，每季度至少演练一次。
• 复制延迟监控必须配告警。延迟超过阈值（比如5秒），从库数据就是过期的，读到的数据可能是错的。
• 同步和异步模式要根据业务选择。金融场景用同步，数据零丢失。一般业务用异步，性能更好。不是所有场景都需要强一致性。

共享存储集群常见坑：

• 为了省钱用低端存储。存储IO延迟一高，集群性能比单机还难受。全闪存是基本要求。
• 节点间互联网络带宽不够。10Gbps起步，有条件上25Gbps。网络是集群的生命线。
• 存储本身的冗余被忽略。RAID 10 + 双控制器是最低配置。存储挂了，整个集群都完蛋。

分布式常见坑：

• 分片键选错。一旦数据倾斜，后面调整的成本很大。上线前用真实数据做压测验证。
• 运维团队规模没跟上。分布式不是上了就完事，监控告警、故障恢复、扩缩容样样都需要人。

通用坑：

• 从Oracle迁移到国产库，架构选型要提前做。别等迁移做到一半才发现目标数据库不支持原来的架构模式。KES在Oracle兼容性上做得扎实，共享存储集群方案能省掉大量改造工作。
• 高可用架构上了之后，监控必须跟上。主从复制的复制延迟、共享存储的IO吞吐、分布式的分片负载，每一项都得有告警。我之前就栽过一次——共享存储集群上线后没配IO监控，结果存储控制器故障，IO延迟从0.5毫秒飙到200毫秒，业务卡了半小时才发现。没监控的高可用就是瞎子过河。

---

做了十五年数据库，没有一种架构能解决所有问题。选方案的核心就一条：匹配业务需求。

另外说个现实问题。数据安全法和个人信息保护法落地之后，信创项目越来越多。数据库选型不只是技术决策了，自主可控、数据主权这些因素必须提前考虑。从Oracle RAC一路走过来，共享存储集群在中大型业务里用得很多。金仓KES支持这种架构，迁移过来不用推翻原来的架构设计，换个产品就能跑。国产替代背景下，这一点确实省心。

各位在做高可用方案选型的时候，先搞清楚自己的瓶颈在哪。再决定上什么架构。不要反过来为了用某个技术而硬上。

架构选错了，后面改的代价比一开始选对要大得多。

各位做信创迁移选了什么方案？评论区聊聊，互相学习。我是路远，咱们下篇见。