Vastbase G100高可用组件横向对比与故障验证实录

做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这类轻量方案最大的问题就在这，后面我会用实测数据说话。

2. Vastbase G100高可用组件的三条技术路线

我在验证前调研了一圈，目前围绕Vastbase G100的高可用落地方式，大体可以归成三条路线：官方配套的集群管理组件、Keepalived加虚IP加脚本化切换、基于分布式协调组件做选主。三者思路完全不同，业界都有实际使用案例，但适用边界差异很大。

2.1 路线一：官方集群管理组件

Vastbase G100作为企业级数据库，产品线通常会配套一套集群管理组件，我在不同版本里见过叫法不完全一样，有的交付形态里叫CM模块，有的叫集群管理工具，具体以官方手册为准，但干的事是同一类：集群心跳、节点状态管理、主备自动切换、虚IP管理，有的还带统一管理页面。

这类组件的最大优势是切换逻辑和数据库内核配合得比较深，比如提升备库之前会先检查日志回放位点、结束残留事务、在必要的时候做资源锁处理。这些细节是外部脚本很难完全复刻的。官方组件的劣势也明显，就是部署和配置相对重，对节点数量、网络、时钟都有严格要求，小规模环境会嫌它烦。

2.2 路线二：Keepalived加虚IP加脚本化切换

这条路线应该是目前中小团队最熟悉的方案。Keepalived负责在主备节点之间漂移一个虚IP，数据库层面用自定义脚本完成“检查主库是否存活、把备库提升为主库、通知应用切换”等动作。架构上组件很少，理解起来直观，出了问题也容易排查。

但这条路线把所有高可用逻辑都压在了脚本上。脚本写得好不好，直接决定切换成不成功。多数团队的脚本只覆盖了“主库进程死掉”这一种场景，一旦遇到网络分区、主库节点Hang住、备库回放落后等复杂情况，脚本就会暴露出大量盲区。而且Keepalived本身不参与数据库选主，虚IP漂移和数据库提升动作是两条独立逻辑，配合不好就会出现“IP已经飘走但数据库没有起来”的中间状态。

2.3 路线三：分布式协调组件做选主

第三条路线是用etcd、Consul这类分布式协调组件来做节点竞选和租约管理。思路是把“谁是主库”这件事交给协调组件裁决，脚本监听协调组件的结果，再执行对应数据库操作。相比Keepalived，它天然具备多数派仲裁能力，脑裂防护更强；相比官方组件，它更灵活，可以自己定义切换策略和扩展逻辑。

代价同样明显：需要自己写大量胶水代码，还要把Vastbase G100的数据库状态、复制状态、恢复状态全部纳入检测维度，否则协调组件只能看到“节点活着”，看不到“数据库已经不可写”，选出来的主可能是个残缺节点。

这三条路线我都搭建过验证环境，下面是整体对比表格：

3. 我在验证环境里做的横向对比：指标和场景设计

对比高可用组件，最怕的就是凭感觉。我在自己的测试环境里搭了一套专门用于Vastbase G100故障演练的集群，把三条路线分别部署上去，用同一组故障场景反复打，记录同一组指标，最后才得出了相对可信的结论。

3.1 验证环境的搭建过程

我准备了三台虚拟机，配置都是4核8G内存，系统盘和数据盘分开，数据盘单独挂载到 /vastbase_data 目录。三台节点分别命名为node1、node2、node3，其中node1计划为主库，node2为备库，node3主要作为仲裁节点，同时也可以承担备库角色。

环境准备阶段最容易被忽略的是时间同步。我用chrony统一了三台机器的系统时间，并设置了本地区域时钟源。为什么必须做这一步？因为心跳超时、日志时间戳、切换顺序的判断全都依赖时间，一旦主备时钟偏差超过几百毫秒，高可用组件的判定就会变得不可靠，甚至出现备库比主库时间还“超前”的诡异现象。

主备复制配置这里不多展开，核心动作是主库开启日志复制相关参数并设置最大发送进程数，备库配置从主库拉取WAL的连接信息，然后通过备份恢复方式把备库拉起。常见的内核状态查看SQL在Vastbase G100里依然可用，比如查询复制状态可以看到主库有几个备库连接、备库回放了哪个日志位置。我每次做故障注入前都会先确认主备同步处于正常状态，避免把“初始状态不同步”误判成“组件切换失败”。

3.2 故障注入场景不是随便杀进程那么简单

我把验证场景分成四类，尽量覆盖生产环境最容易遇到的真实故障。

第一类是主库进程异常退出。直接在node1上执行kill -9杀掉数据库主进程，模拟最典型的主库宕机。这个场景主要考验组件的故障发现速度和切换速度。

第二类是主备网络分区。用iptables在node1上DROP掉与node2之间的数据包，模拟物理断网或交换机故障。这个场景和第一类的本质区别是，主库进程实际还活着，只是备库联系不上它。很多组件在场景二里会犯严重的决策错误。

第三类是备库日志回放延迟。人为在备库上制造磁盘压力，或者暂时停掉备库的恢复线程，让备库落后主库一大截，然后观察组件是否还会无脑把这个备库提升为主库。这个场景主要考验RPO意识。

第四类是虚IP异常。关闭主库所在节点的VIP网卡，模拟应用层地址漂移失败。这类故障虽然听起来是网络的事，但实测中它会把高可用组件的“执行环节”打得措手不及。

每类场景我都重复执行了至少五轮，记录中位数和最大偏差，不拿单次结果当结论。因为数据库高可用切换存在时序波动，一轮跑得快不代表稳定，多轮跑下来才能看到真实水平。

3.3 RTO和RPO的记录口径必须统一

做验证之前，我先定了指标口径，否则数据根本没法横向比较。

RTO我定义为：从故障注入的时刻开始，到业务写事务重新成功的那一刻结束。这个时间段包含故障发现、选主决策、备库提升、VIP漂移、应用重连的全部时间。很多人统计RTO只算数据库进程恢复的时间，这样会把应用的感知丢在一边，是不诚实的统计方式。

RPO我定义为：切换完成后，新主库缺失的日志覆盖时间跨度。具体做法是在主库上持续写入带有时间戳的测试数据，切换完成后去新主库查询最后一条记录的时间戳，再和故障注入前的写入时间做对比，差值就是RPO的近似值。这个值越接近零越好，实际验证中它往往取决于同步复制配置和备库回放速度，而不是单纯由高可用组件决定。

统一指标口径之后，三类组件的差距变得非常清晰，下面是我整理后的实测结论。

4. 实测结论：三类组件的差距比想象中大

我不打算在这里给具体厂商版本打广告，只陈述我在同一个环境里用同一套场景打出来的相对表现。整体结论是：官方组件最稳、Keepalived方案最险、分布式协调组件最灵活也最容易出幺蛾子。

4.1 官方集群管理组件：切换最稳，但配置要求严苛

官方组件在场景一和场景三中的表现最好。主库进程被杀掉之后，故障检测时间在秒级，备库提升之前会先检查日志回放位置，确认没有明显落后才执行切换，整个过程基本不需要人工干预。场景三的备库延迟测试里，官方组件会给出延迟告警，并且延迟过大时不会强行提升备库，这个保护机制非常重要。

它的问题主要出现在配置阶段。节点数量、主机名、时钟同步、网络端口都得按规范来，稍有偏差组件可能直接无法启动，或者启动后不参与仲裁。我第一轮部署就因为node3的防火墙没放行组件端口，导致仲裁一直缺票，切换失败。这类问题在使用文档里通常有写，但很容易被忽略。

4.2 Keepalived加脚本：胜在简单，但脑裂和盲区很致命

Keepalived方案在场景一中表现不错。主库进程挂掉后，Keepalived检测到服务不可用，虚IP漂移到备库，脚本再去执行备库提升，整个RTO中位数能控制在十几秒到几十秒范围，对于小型系统来说勉强够用。

但它在场景二的网络分区测试里几乎裸奔。我模拟主备网络隔离后，备库认为主库失联，触发脚本提升自己为主库；而主库实际还活着，依然持有虚IP原地址，两边同时可写，形成典型双主脑裂。这个状态极其危险，因为Vastbase的WAL日志此时已经被两边分叉，人工介入时很难无损合并。Keepalived本身的设计目标只是虚IP高可用，它根本没有数据库选主的仲裁能力，指望它防脑裂属于期望错位。

4.3 通用协调组件：弹性最好，但需要自己排的雷最多

用etcd这类协调组件做选主，脑裂防护设计得好很多。我在node1、node2、node3三个节点上都部署了协调组件，通过租约机制选主，只有拿到多数派节点的租约，脚本才允许执行备库提升动作。实测网络分区场景里，node2联系不上node1但能联系上node3，它拿到多数派认可后提升为新主，而node1虽然不知道node2发生了什么，但因为它拿不到多数派租约，被强制降级，不会发生双主。

这套方案的坑不在这，而在于“节点存活”和“数据库可用”之间的巨大鸿沟。协调组件只能告诉你节点进程是否活着，至于数据库是否处于可写状态、复制是否正常、日志回放是否堵住，都需要自己写探针去感知。我第一次适配时只检查了数据库进程是否存在，结果主库遭遇磁盘满导致不可写，协调组件却认为主库很健康，压根不触发切换。后来把所有状态探针写完，这个方案才勉强达到可用水平。

三类组件的实测相对结果汇总如下：

5. 验证过程中最容易翻车的几个细节

这一节是全篇最想让同行看到的部分。高可用组件的大部分问题不是出现在宣传的功能列表里，而是出现在验证过程的边边角角。

5.1 时间同步是所有判定成立的前提

我前面提过一次时钟同步，这里要再强调，因为它是实测中翻车概率最高的细节。有一次验证过程中，node2的系统时间比node1慢了近两秒，恰好主库故障发生在这两秒的窗口里，备库回放日志时时间戳判断全部错位，日志对比结果一塌糊涂，我一度以为是复制配置写错了。后来排查了一圈，发现就是时间偏移导致的。数据库高可用体系里，时间不是“尽量一致”而是“必须一致”，建议统一使用内部时钟源，并且把同步状态纳入监控告警。

5.2 切换脚本的幂等性：同一个故障被触发两次会怎样

Keepalived方案的切换脚本，我第一版写得非常“直白”：检测到主库失败就执行备库提升。问题出在一次演练中，脚本第一次执行到一半，虚IP还没完成漂移，我又触发了第二次检测，脚本再次执行提升命令，结果备库状态被搞乱，不得不人工重建。切换脚本必须考虑幂等性，也就是说，同一个故障连续触发多次，脚本应该只产生一次有效切换动作，后续触发应当安全退出。实现思路很简单，在脚本开头检查当前节点是否已经是主库、是否已经执行过提升、虚IP是否已经漂移到本节点，任一条件满足就直接退出。

5.3 备库日志延迟比你想象中更常见

生产环境里备库延迟几乎是常态，只是多数系统监控粒度太粗，根本看不到。我在验证时有意识地在备库上增加磁盘压力，结果备库日志回放延迟从正常状态的几百毫秒涨到几十秒，而此时主库还在持续高强度写入。这种情况下若发生切换，RPO会直接飙升。高可用组件如果在决策阶段不检查备库延迟，就相当于在不知道数据完整性底线的情况下做手术。这也是为什么我一直推荐至少把备库回放位点纳入告警和切换前置检查，无论你用的是哪条路线。

5.4 验证要主动制造“极端但不罕见”的网络分区

很多团队做切换演练，只会测主库进程被kill的场景。这种场景下主库是真的死了，不存在争议，组件也好做决策。但生产里更常见的网络抖动、交换机瞬间阻塞、长时间网络分区，主库进程其实还活着，此时才是高可用组件最容易被暴露问题的地方。我在验证方案里专门设计了网络分区场景，用iptables在节点间DROP数据包，持续几秒到几十秒，观察组件是否误判、是否脑裂、是否能自动恢复。实测中Keepalived方案在这个场景下表现最差，官方组件也有一次因为心跳参数设置太灵敏而出现误切换，后来调大了超时阈值才稳定。

5.5 自动切换失败后要有手动接管预案

无论组件多成熟，自动切换都有失败的可能。验证过程中我故意把切换脚本改成错误版本，模拟自动切换失败的情况，检查是否有清晰的告警和手动接管路径。结论是很多团队完全没有预案，自动切换一失败，所有人都陷入慌乱，临时查手册去执行建库脚本，浪费大量时间。我建议在验证阶段就把“自动切换失效时，如何手动提升备库、如何通知应用修改连接地址、如何恢复旧主库”写成标准操作步骤，并至少完整演练一次。

6. 落地选型：不同业务场景的建议

对比和验证的最终目的不是评出谁最好，而是找到最适合自己业务场景的方案。这里我根据实测经验，给几个我的选型参考。

6.1 核心生产系统：优先官方组件，不要为省事绕过

如果你的系统承载核心交易类业务，对RTO和RPO都有硬性要求，我的建议是老老实实采用官方交付的集群管理组件，按照官方规范配置节点、网络和时钟。它的配置过程确实繁琐，但换来的是切换流程更规范、脑裂防护更可靠、与数据库内核的配合更深入。真出故障时，多出的那些配置成本是完全值得的。

6.2 一般业务系统：Keepalived加严格检查脚本，配合人工确认

如果是中小型业务系统，RTO要求可以接受几十秒，团队人力有限，Keepalived加虚IP的方案依然有存在价值。但必须补上几个东西：备库延迟检查、切换脚本幂等保护、脑裂告警、半自动或人工确认机制。把自动切换限制在“主库确死”的单一场景内，其他复杂情况一律告警并等待人工介入，这样能最大程度避开脑裂风险。

6.3 开发测试与交付演示环境：脚本自动化就够

开发测试环境不需要上完整的高可用组件，主备加一套简单的状态检查和切换脚本足够。这类环境最重要的是能快速重置、快速演示，而不需要纠结RPO和脑裂。我自己在测试环境里甚至只用一个定时任务检查主库状态，发现异常就调用提升脚本，实用性完全够。

6.4 我的最终体会

做了这一轮Vastbase G100高可用组件对比与验证之后，我最大的感受是：高可用方案没有银弹，每一套组件都有自己的能力边界。官方组件强在稳定但配置重，Keepalived胜在简单但脑裂风险高，分布式协调组件最灵活但需要大量适配和排雷。真正决定高可用水平的不只是组件本身，还有你对它的理解深度、故障场景覆盖度、应急预案完整度。验证不是一次性的工作，环境变了、版本升级了、业务压力变了，都应该重新跑一轮故障注入。最后再分享一个小技巧：所有验证结论都写进团队文档，连同当时的故障截图、切换日志、指标数据一起留档，下次做架构评审时，这些材料比你口头说一百句都管用。