2.3 主备、集群与分布式形态

2.3 主备、集群与分布式形态

本节摘要：openGauss 的部署形态是一条演进阶梯：一主一备解决可用性，一主多备加备机可读扩展读能力与容灾半径，分布式与资源池化解决单机容量与写入上限。形态选择的本质，是在"复杂度预算"里买对应级别的能力。

先给定义：三种形态各指什么

交付文档里这三个词经常混着用，先把定义钉死。一主一备：两台实例互为镜像，主机写、备机同步回放，主机故障时备机接管——它解决的是"坏了怎么办"，不解决"不够用怎么办"。一主多备：一台主机带多台备机，备机可配置为可读，承担报表与只读流量；配合 CM 组件做仲裁与自动切换，可用性等级再上一档。分布式形态：数据按分片规则水平拆到多个数据节点，由协调节点统一收发查询，解决单机写不进、存不下的规模问题；资源池化则是把计算与存储解耦的下一步演进。三者是叠加关系而非并列关系：分布式形态的每个数据节点内部，依然是主备结构。

上图中三条虚线是理解形态的关键：无论哪种形态，CM 组件都在拓扑之外做仲裁、切换与健康监控。把"数据库进程"和"集群管理进程"分开看，很多怪问题会变得好解释——比如备机被反复拉起，先查的往往是 CM 的仲裁记录而不是数据库日志。

形态一：一主一备，可用性的地基

交付项目里百分之八十的形态都是它。工作原理一句话：主机把 WAL 日志实时传给备机，备机回放，保持数据一致；同步模式下主机提交要等备机确认收到日志，保证不丢已提交事务。这个模式的花费也很直白——每次提交多了一个网络往返加备机落盘的等待，峰值写延迟由最慢的备机决定。第 5 章会专门演练搭建与切换，这里先记住两个交付要点：同步备机必须与主机同机房低延迟部署，跨机房做异步容灾而不是同步；备机参数与主机保持一致，尤其内存相关参数，否则切换后性能悬崖。

形态二：一主多备，读扩展与多副本

当报表、导出、审计查询开始影响主库，一主多备登场。核心增量是两个：多副本让数据的安全性从"两份"变"N 份"，机架级甚至机房级故障可容忍；备机可读把只读流量导出去。它的隐形成本是路由：应用侧要区分读写连接串，或引入代理层做读写分离，事务内的一致性读仍然要回主机。我们在交付中的经验规则：备机数量两台起步才有意义——一台同步保不丢、一台异步扛只读，只剩一台时要么牺牲不丢、要么牺牲只读，二选一很被动。

形态三：分布式与资源池化，规模的上限

单表过 TB、单机写入打满、存储扩容受限时，才进入这个话题。分布式形态把数据按哈希或范围切片，分布在多个数据节点，协调节点负责 SQL 改写与结果汇聚。收益是容量与吞吐近乎线性扩展；代价是一张清单的复杂度：分布式事务的两阶段提交（第 3 章 3.5 节）、跨节点的执行计划与数据倾斜、扩容时的数据重分布。资源池化则把存储层抽出来池化共享，计算节点无状态化，弹性扩缩更接近云的形态。选型判断句：数据量与写入量没有顶到单机天花板时，不要为"未来可能"预支分布式的复杂度——集中式主备扛不住的那一天，分布式路线随时可以启程，但反过来拆掉分布式换回集中式几乎不可能。

完整决策案例：从单机到一主多备的升级

背景：某物流平台运单库，单机主备运行半年后，报表查询在业务高峰把缓冲区命中率拖到八成，主库接口抖动。操作过程：第一步确认瓶颈在只读流量——按会话归类，报表占了四成连接与六成 IO；第二步评估拆库与加备机两条路，报表与业务共享大表关联，拆库成本高，选加备机；第三步扩容一台异步可读备机，应用侧报表连接串切到备机；第四步设告警：备机回放延迟超过三十秒自动通知，报表侧自动降级。结果：主库命中率回到九成八以上，报表高峰不再影响交易。解读：这个案例的形态决策依据不是数据量（不到两百 GB），而是负载混合度——读流量占比过半时，一主多备是性价比最高的下一步。变式：如果报表与业务几乎无表关联，正确选择是把报表库独立出去，用逻辑复制喂给它，物理备机的复杂度都省了。

CM 组件的职责清单与误判案例

既然 CM 在拓扑之外做仲裁，就把它的职责边界列全：健康探测（周期性检查各节点进程与复制状态）、仲裁决策（多源信息交叉判断谁是真故障）、自动切换（实例级故障时提升备机）、告警上报（切换事件的完整记录）。误判案例：某项目备机反复重启，值班怀疑数据库进程崩溃，查了一圈内核日志无果；最后翻开 CM 的事件记录，发现是 CM 的探测脚本对某个监控端口的超时阈值配置过严，把健康的备机误判为失联而反复拉起。结论写进了交接文档：切换与重启类异常，第一站查 CM 事件记录，第二站才是数据库日志——仲裁系统有自己的视角与配置，它可能先于你做决定。

形态评审的三个必答题

形态方案上评审会，请准备好这三问的答案。一问数据规模与增长曲线：一年后的数据量与写入峰值决定了集中式的天花板距离，规模答案要给曲线不要给单点。二问可用性承诺：RPO 与 RTO 的业务口径是什么（第 5 章的框架），它决定备机数量与同步级别。三问复杂度预算：团队的分布式运维经验有几成、出了分区类问题谁来兜底——诚实回答这一问，能避免一半的过度设计。三问都答得清楚，形态选择基本只剩一个候选；三问都含糊，任何形态都会在后期变成争吵的来源。

FAQ

备机能当热备测试环境用吗？

不建议。备机上的写操作被禁止，但重型查询会吃掉回放线程的 IO 与 CPU，拖累主备延迟（5.1 有专节分析）。要测试环境就用独立资源，别打备机的主意。

以后扩备机，现有应用要改吗？

不需要改连接逻辑，但只读流量要不要分流到新备机，由应用的路由配置决定。扩备机前先确认应用侧有没有读写分离的预留能力——没有的话，新备机只增加数据冗余，不增加读吞吐。

集中式什么时候必须让位给分布式？

两个硬信号：单机存储装不下或扩容成本失控；写入峰值超出单机日志系统的持续带宽。出现任一信号再启动分布式评估，用第 3 章 3.5 的两个量化指标做可行性判断。

补一个视角：形态演进的历史逻辑

把形态阶梯放进数据库行业的历史里看，会发现它复刻了行业四十年的演进路径：先有集中式（单机），可用性需求催生主备复制，读扩展催生多副本，容量天花板倒逼分库分表与分布式，运维复杂度再倒逼池化与云化。openGauss 用一条产品路线浓缩了这段历史，交付团队因此有个独特优势：你不需要经历行业演进的全过程，只需要理解每一级阶梯的因果——是什么问题让上一级形态不够用，这个问题的答案就是升级时机与升级理由。答辩时能讲出这条历史逻辑的人，与只会念产品手册的人，给评审团的信心完全不同。

本节要点回顾

• 定义钉死：一主一备管可用，一主多备加读扩展，分布式管规模，三者可叠加；
• CM 组件在拓扑外：仲裁、切换、监控是它的职责，怪问题先查仲裁记录；
• 同步备机同机房：跨机房走异步容灾，不要让提交延迟被物理距离绑架；
• 备机两台起步：一台同步一台异步，仲裁与读扩展才有腾挪空间；
• 不为未来预支复杂度：集中式到分布式的升级通道是通的，反向几乎不可行。

形态定了，接下来两章深入内核地基：数据到底以什么结构躺在盘上（第 3 章），查询计划是怎么被选出来的（第 4 章）。