以为滚动升级就不停机？PgBouncer 和 Praefect 没配负载均衡，升级直接断连

非高可用组件升级若未配置自动流量切换与健康检查，会直接导致服务显式中断，滚动升级无法避免停机。

非高可用组件升级会直接停机吗？滚动升级的“无停机”谎言

逐节点滚动升级并非万能钥匙，对于缺失负载均衡与探针的关键状态组件，升级必然引发服务中断而非无可见停机。

业界常把“逐节点滚动升级”当作服务不中断的万能钥匙，但事实往往比口号更骨感。GitLab 在多节点部署文档中曾宣称其架构实现了“有效无可见停机”。这句话听起来令人安心，却藏着一个常被忽略的前提：它仅适用于配置了外部负载均衡、健康检查（如 /-/readiness 探针）以及内部高可用机制的场景。一旦剥离这些条件，断言便不再成立。对于 PgBouncer、Praefect 这类未配置 HA 的关键状态组件，单独升级必然导致服务显式中断。

GitLab 的测试标准与真实前提

GitLab 的参考架构之所以能实现流量平滑接管，依赖的是外部负载均衡器在节点轮换时的实时调度能力，配合应用层探针确认节点就绪。这种机制的核心逻辑是：只有当 PgBouncer 和 Praefect 等组件自身已具备高可用能力时，流量切换才具备可行性。如果这些组件缺乏内部负载均衡或健康检查，它们就无法在升级期间自动剔除故障节点并重新分配连接。此时所谓的“滚动”，实际上是在单点故障面前强行推进，结果就是用户端直接感受到服务断开。

值得注意的是，许多运维团队在评估升级方案时，容易陷入一个概念陷阱：将“应用层”的无停机能力错误地等同于“全链路”的无停机能力。事实上，GitLab 官方材料并未披露具体的测试方法、样本量、持续时间或请求级错误率^[1]。没有这些数据，我们无法判断这是否意味着严格的零错误，或是仅仅因为测试期间的流量负载过低而未被触发异常。在未验证 SLA 的情况下，盲目相信“无停机”承诺，极易让运维团队低估风险。将“观察不到”等同于“不存在”，本质上是一种危险的认知偏差。真正的分水岭不在于应用代码是否重启，而在于数据平面（Data Plane）的状态同步组件是否具备了自动感知与切换的底层能力。

当 PgBouncer 和 Praefect 没有负载均衡时，升级会发生什么

当 PgBouncer 或 Praefect 缺乏内部负载均衡时，滚动升级实为单点硬重启，连接会被直接切断导致用户侧明确中断。

很多人以为只要逐节点滚动升级，服务就能永远在线。这个逻辑在应用层或许成立，一旦落到 PgBouncer 或 Praefect 这类关键状态组件上，结论就完全不同了。在非高可用架构中，这些组件往往就是唯一的流量入口或状态枢纽。如果它们没有配置内部负载均衡与 TCP 健康检查，所谓的“滚动”实际上就是单点硬重启。此时，流量无法自动切换到备用节点，连接会被直接切断，用户侧会看到明确的服务中断信号。

PgBouncer 升级时的连接风暴

PgBouncer 作为数据库连接池代理，其核心职责是维持长连接并复用资源。当你在非 HA 模式下对单个 PgBouncer 节点进行升级时，进程会立即终止。由于缺乏健康检查机制，客户端无法感知后端已不可用，依然会向该节点发送新的请求或重试旧请求。这就好比一个只有一条通道的收费站突然关闭，而司机的导航仪却没收到封路信息，结果就是车辆全部堵死在路口。这种缺乏感知的重试行为会瞬间演变成连接风暴，导致数据库连接耗尽，进而引发整个系统的雪崩式故障。

Praefect 状态同步的中断风险

Praefect 负责处理 Raft 共识机制下的状态同步，通常担任集群的 Leader 角色。在单节点升级场景中，Leader 所在的节点必须下线。对于高可用架构，系统会自动选举新 Leader 并完成流量切换；但在非 HA 架构下，若没有内部负载均衡兜底，整个集群将暂时失去写入能力。这就像一支球队的主力队长突然离场，且教练组没有提前安排替补指挥，全队进攻节奏瞬间瘫痪。这种因状态丢失导致的写入阻塞，属于典型的显式中断，任何依赖实时写入的业务都会在此刻停摆。

下表对比了两种架构在升级时的表现差异：

这种区别揭示了 HA 与非 HA 架构的本质分野：前者靠机制自动规避风险，后者则被动承受失效后果。

从风险消除到风险迁移：滚动升级的真实代价

滚动升级并未消除风险，而是将瞬间断连转化为剩余节点因无法扛住全部流量而引发的过载雪崩。

很多人误以为逐节点滚动升级彻底消灭了停机风险，其实只是把“瞬间断连”换成了“过载雪崩”。这种视角的转换揭示了更隐蔽的代价：系统不再担心单个节点下线，而是必须承受剩余节点在极短时间内扛住全部流量的压力。

GitLab 在其多节点 Linux 包部署文档中承认，所谓的“有效无可见停机”并非自动发生，而是建立在严格的架构前提之上。一旦关键组件如 PgBouncer 或 Praefect 缺失内部负载均衡与健康检查，流量切换机制就会失效，此时滚动升级不仅无法规避中断，反而会让服务显式中断成为必然。即便配置了 HA 组件，真正的考验才刚刚开始。

当第一个节点进入维护窗口，剩余节点的承载能力必须瞬间填补空缺。这不再是简单的容量叠加，而是对峰值吞吐的极限施压。如果剩余节点缺乏足够的冗余空间，或者跨版本兼容性存在隐患，流量切换就会迅速诱发连锁反应。原本可控的局部波动，可能演变成整个集群的雪崩。

为了看清这种风险转移的具体表现，我们可以对比两种场景下的实际后果：

数据表明，没有自动流量切换机制的滚动升级，本质上只是将潜在的崩溃风险推迟到了剩余节点过载的时刻。这种“延期支付”的策略在容量充足时看似有效，一旦遇到流量波峰或兼容性问题，代价往往比直接停机更为惨重。

判断能否真正避免升级期间服务中断的唯一标准，是确认是否配置了自动流量切换机制。若无此机制，所谓的“滚动升级”不过是给不稳定的系统披上了一层伪装的薄纱。

如何判断你的架构是否真的能“不停机升级”

架构能否不停机升级取决于关键组件是否启用 TCP 健康检查及是否有负载均衡器在节点轮换时接管流量。

很多人误以为只要执行逐节点滚动升级，服务就能永远在线。事实是，这种“无停机”承诺仅存在于特定配置下。若关键组件如 PgBouncer 或 Praefect 缺失内部负载均衡与健康检查，滚动升级只会将瞬时风险转化为显式中断。要验证你的架构是否具备真正的容错能力，需对照以下核心标准自查：首先确认状态组件是否启用了 TCP 健康检查；其次核实是否有内部负载均衡器在节点轮换时接管流量。

HA 与非 HA 架构升级表现对比

当架构设计不同，升级时的行为差异巨大。高可用（HA）架构通过自动切换机制屏蔽了单点故障，而非 HA 架构则会在升级瞬间切断连接。下表清晰展示了两种模式在升级过程中的实际表现：

如果未配置上述 HA 机制，切勿依赖滚动升级来规避维护窗口。非高可用组件升级会直接停机，这是由架构设计决定的必然结果。只有同时满足内部负载均衡和健康检查配置，才能确保升级过程不产生显式中断。

实操建议： 在计划升级前，不要仅凭经验判断，应先在预发环境模拟“拔线”操作。具体步骤如下：1. 在预发环境中，手动停止目标 PgBouncer 或 Praefect 节点进程；2. 立即使用监控工具（如 Prometheus 或自定义脚本）观测业务层的错误率曲线及 延迟变化；3. 重点检查是否有大量客户端重试导致的数据库连接池爆满。如果监控显示错误率在节点停止后呈指数级上升，说明你的架构缺乏有效的健康检查或流量切换机制，此时必须回滚升级计划，改为先搭建 HA 架构或申请正式停机窗口。

FAQ：关于滚动升级的常见疑问

Q: 如果我只升级应用代码，不动 PgBouncer 和 Praefect，会停机吗？ A: 如果你的应用层和数据库中间件之间没有健康的负载均衡层，即使只动应用，如果应用重启导致连接池重置，而中间件处于单点状态，依然可能引发短暂的连接风暴或服务中断。关键在于中间件是否具备“感知”和“切换”能力。

Q: “无可见停机”是不是意味着完全没有错误日志？ A: 不一定。官方文档中的“无可见停机”通常指用户端未感知到长时间不可用，但底层可能会产生少量的超时或重试错误。如果没有详细的监控数据，很难界定这是否属于“零错误”。

Q: 如何低成本实现类似 HA 的效果？ A: 对于小型系统，可以考虑引入轻量级的反向代理（如 Nginx）配合简单的 TCP 健康检查脚本，虽然不如商业负载均衡器强大，但能显著降低单点故障带来的升级风险。

参考来源

1. Upgrade a multi-node instance with zero downtime | GitLab Docs · https://docs.gitlab.com/update/zero_downtime/（A级）