贵萌兄做Vastbase G100高可用组件横向验证这件事，最开始是因为一次生产事故复盘。那套系统用一主一备加Keepalived，理论上切换时间也就是几十秒的事，结果由于备库日志回放延迟被忽略、切换脚本又没有幂等保护，整个恢复过程硬生生折腾了快二十分钟。业务侧反复问“到底什么时候能恢复”，而数据库侧能做的只有一遍遍手工检查状态。那次之后我定了一条规矩：任何高可用组件都不能只看宣传页，拿到同一套环境里按故障场景逐项打，把检测机制、切换动作、脑裂防护全部跑一遍，再谈能不能上生产。
这篇内容就是围绕Vastbase G100高可用组件对比与验证整理的完整记录，适合正在选型或准备做切换演练的DBA、运维工程师和架构师参考。我会先把高可用组件到底在管什么讲清楚，再拆解几条主流技术路线，然后给出我实际搭建的验证环境、压测场景、指标口径和最终结论，最后是把我在验证过程中踩过的坑逐一列出来。如果你也在为国产数据库的主备切换方案纠结，这篇应该能帮你少走不少弯路。
1. 先搞清楚一件事：高可用组件到底在管什么
很多团队在聊高可用时，第一个想到的就是主备复制。Vastbase G100的主备节点之间通过WAL日志流复制保持数据同步，这确实是高可用的地基，但它只解决“数据怎么到备库”的问题，并不解决“主库挂了之后业务怎么恢复”的问题。把复制和高可用混为一谈，是很多切换事故的根源。
1.1 复制是高可用的地基，但不是高可用本身
Vastbase G100基于openGauss内核，主库把产生的WAL日志连续发送给备库，备库接收并回放这些日志，从而保持与主库一致。这套机制保证了在正常情况下，备库拥有接近实时的数据副本。但请注意，这里的“正常情况”四个字很关键。如果主库进程被kill掉，或者主备之间的网络出现分区，复制通道就会中断，备库并不会自动变成新主库。
谁来决定备库什么时候可以提升、谁去提升、提升之后业务流量怎么切过去？这才是高可用组件要做的事。复制通道只是一个传输管道，高可用组件才是那个在故障发生时做决策的大脑。很多半懂不懂的方案文档会把两者混在一起写，实际验证时就会发现，复制正常并不代表高可用能力正常，这两件事必须分开评估。
1.2 高可用组件接管的是三件事：探测、决策、执行
一台高可用组件，本质上只做三件事。第一是探测，也就是持续检查主库和备库是否活着。探测手段一般有几种，比如心跳包检测、数据库进程状态检查、SQL探测或者WAL接收状态检查。第二是决策，也就是收到“主库疑似不可用”的信号后，判断是不是真的需要切换、由哪个备库接替、当前是否满足切换条件。第三是执行，包括虚IP漂移、把目标备库提升为新主库、把旧主库踢出集群或者降级为只读节点。
这三个环节任何一个做得不彻底，切换都会出问题。比如探测只依赖心跳包，主库还没死但网络抖动时，备库可能误判主库故障而触发切换，结果造成双主；再比如决策阶段不检查备库日志回放位置，直接把一个落后很远的备库提上来，业务恢复了但数据丢失一大批，这就是典型的RPO失控。所以做组件对比时，不能只看“能不能切换”，而要看它在探测、决策、执行三个环节分别做了什么、做得有多细。
1.3 判断组件好坏的第一个标准：它有没有机会左右脑裂
分布式系统里，脑裂是最经典也最危险的问题。放到数据库场景里，脑裂就是主备同时认为自己是主库，两边都接受写入，最后数据分叉，想合并都合不回来。判断一个高可用组件是否可靠，首先要看它有没有脑裂防护机制。
脑裂防护通常靠仲裁节点或多数派投票实现。三节点集群中，任何一个节点想提升自己为主库，必须拿到多数派（至少两个节点）的认可；两节点集群没有仲裁者，网络一抖动就可能两边各执一词。Vastbase G100的复制机制本身没有太多决策能力，它只能忠实地执行指令，所以在高可用组件对比中，仲裁设计几乎决定了整个方案的安全上限。Keepalived这类轻量方案最大的问题就在这，后面我会用实测数据说话。