1. 引言

1.1 传统主流传统高可用技术方案

在传统的基础设施（物理机、虚拟化数据中心）等非云基础设施中，PostgreSQL 的高可用技术方案会用到 heartbeat，heartbeat 加上 crm，rhcs，还有就是 coreosync 配合 pacemaker，这些技术都是需要共享存储的，对然后还需要仔细的配置 fencing 或者说 stonith 来防止数据的不一致。

具体来说这些 PostgreSQL 高可用架构长期依赖中心化集群管理 + 共享存储的模式，核心技术栈主要分为两类：

1.1.1 Heartbeat + CRM / RHCS

Heartbeat 是早期经典的集群通信组件，主要提供节点间的心跳探测、节点状态维护功能，用于判断节点是否存活。

CRM（Cluster Resource Manager） 或 RHCS（Red Hat Cluster Suite） 则负责对 PostgreSQL 进程、虚拟IP、存储等资源进行统一调度与管理。当主节点故障时，整套系统会将服务整体漂移到备节点，实现服务恢复。

这套方案部署相对简单，但在大规模、高可靠性要求场景下稳定性有限，已逐步被更现代的架构替代。

1.1.2 Corosync + Pacemaker

这是传统架构中最主流、最成熟的高可用组合。Corosync 负责集群内部通信、成员关系管理、消息有序传输，相比 Heartbeat 提供了更可靠的消息机制与节点管理能力。Pacemaker 作为集群资源管理核心，负责故障检测、资源约束、故障自动切换与恢复。整套系统可以实现秒级故障检测，并支持复杂的资源依赖关系管理，是传统企业级 PostgreSQL 高可用的标准方案。

1.2 传统方案的强依赖与关键机制

传统高可用方案存在两个不可缺少的强约束。

1.2.1 必须依赖共享存储

所有集群节点必须挂载同一套共享存储设备，典型如 SAN、iSCSI 等集中式存储。PostgreSQL 的数据文件、WAL 日志全部存放在共享存储上，主从切换本质只是“服务进程在不同节点间切换”，数据本身并不需要在节点间复制。这种模式简化了数据一致性，但严重依赖底层硬件可靠性。

1.2.1 必须配置 Fencing / STONITH

为了避免“脑裂”（网络分裂导致多节点同时认为自己是主库）引发数据覆盖与损坏，传统集群必须启用Fencing（隔离） 或 STONITH（Shoot The Other Node In The Head） 机制。其核心作用是：当节点异常时，强制将该节点从集群中隔离，或直接通过电源管理、存储控制器切断其对数据的访问权限，确保同一时刻只有一个节点能写入数据。

1.3 传统方案在云环境前的天然缺陷

传统架构设计假设底层硬件、网络、电源是相对可靠的，通过昂贵硬件换取稳定性。但这种思路在云环境中完全不适用：共享存储难以实现、IP 动态变化、节点随时销毁重建、多播被禁用，直接迁移传统方案会导致集群不稳定、切换不可控、数据一致性无法保障。

2. 云原生环境对数据库高可用的设计思路转变

2.1 云基础设施的本质特性

云环境（IaaS、容器、Kubernetes）彻底改变了基础设施的可靠性模型：

• 节点不再是“永久存在”的，而是临时、弹性、可销毁重建的；
• 计算、存储、网络完全解耦，单部件故障是常态，而非异常；
• 官方不承诺硬件永不宕机，而是通过架构冗余 + 自动自愈实现高可用；
• 网络不可靠，可能出现网络分区、延迟波动、连接中断。

这意味着：任何依赖固定IP、固定硬件、共享存储的传统集群方案，在云里都会水土不服。

2.2 云原生高可用设计思路的核心转变

1. 从“追求硬件不宕机”转向“接受故障并自动自愈”
   不再投入成本追求绝对可靠的硬件，而是接受节点会挂、网络会断、存储会飘，通过软件架构实现故障屏蔽。

2. 从“共享存储”转向“无共享架构 Shared-Nothing”
   每个节点拥有独立本地存储，数据通过数据库原生复制机制在节点间同步，不再依赖中心化存储设备。

3. 从“静态配置集群”转向“动态发现 + 集中式存储维护状态”
   集群拓扑、角色、地址不再写死在配置文件中，而是存放在 etcd、Consul 这类高可用键值存储中，组件自动发现、自动更新。

4. 从“VIP 漂移”转向“服务发现 + 代理路由”
   不再依赖固定虚拟IP，而是通过统一入口代理，实现对客户端透明的主库切换。

3. 云IaaS环境自建PostgreSQL高可用的技术难点

3.1 存储层面无法复用传统模式

传统数据库高可用方案中“共享存储+主从切换”的核心逻辑，在主流云等云原生环境下完全失效，根源在于主流云厂商块存储的天然限制与传统SAN存储的特性冲突。

3.1.1 块存储多节点共享限制：无法实现集群共用

云厂商的弹性云服务器（ECS）云硬盘、阿里云的云盘（包括ESSD、SSD云盘等）均为单节点绑定设计，一个块存储实例同一时间仅能挂载至一台虚拟机/ECS，无法像传统SAN存储那样支持多节点并发读写。这意味着PostgreSQL主库与备库无法共用同一份存储资源，主从切换时无法通过“切换存储挂载点”快速接管数据，直接打破了传统模式的核心逻辑。即使华为云提供“共享云硬盘”功能（仅适配专属分布式存储DSS场景），也需额外部署专属存储集群，且仅支持特定集群应用，无法直接复用为数据库共享存储。

3.1.2 跨可用区（AZ）共享成本极高：可用性与成本矛盾

云厂商如华为云、阿里云等的块存储均与可用区（AZ）强绑定：华为云ECS云硬盘、阿里云云盘的数据冗余存储在同一AZ内，跨AZ访问需通过公网或专线传输，不仅存在较高的网络延迟（影响数据库同步性能），还会产生高额的跨AZ流量费用与数据迁移成本。例如华为云跨AZ访问OBS存储时，外网流出流量需按GB计费，若数据库数据量达到TB级，跨AZ共享的月度成本将显著增加。而传统SAN存储可通过光纤网络实现跨机房低延迟共享，这一优势在云块存储中完全无法体现。

3.1.3 共享存储替代方案复杂度高：运维成本剧增

若强行追求传统共享存储的效果，需在华为云、阿里云等云环境中自行部署Ceph、GlusterFS等分布式存储集群，或采用云专属分布式存储DSS、云文件存储NAS（如CPFS）。但这类方案存在明显弊端：

• DSS需独占物理存储资源，初始部署成本高；
• NAS虽支持多节点共享，但IO性能难以匹配数据库高并发需求，且需额外配置权限控制与数据同步策略。

更关键的是，分布式存储集群的部署、扩容、故障排查需专业运维团队支撑，大幅增加了架构复杂度与长期维护成本，与云原生“轻量化、低运维”的核心诉求背道而驰。

综上可见，云厂商提供的块存储特性直接宣判了传统 “共享存储+主从切换” 模式的死刑，倒逼高可用方案向 “分布式架构+数据异步同步” 转型——这也是Stolon架构在海康AGV系统中被采用的核心原因之一，通过Keeper组件实现数据实时同步，无需依赖共享存储即可完成主从切换与集群重构。

3.2 Fencing / STONITH 难以自动化落地

在云环境中，传统电源管理方式失效，Fencing 只能通过调用云厂商 API 实现：强制关机、卸载磁盘、禁用网卡等。但存在以下问题：

• 云 API 调用存在权限、网络、限流风险，无法保证100%可靠；
• 异常场景下（如控制平面故障），隔离机制可能失效；
• 无法做到完全自动化，很多场景仍需要人工介入，存在数据丢失风险。

3.3 网络环境与传统数据中心完全不同

1. 多播基本不可用
   传统集群大量依赖多播进行心跳广播与成员发现，但云厂商VPC环境默认禁用多播，集群只能改用单播通信，配置复杂度、耦合度大幅提升。

2. 节点IP不固定
   在弹性伸缩、不可变基础设施中，节点重建后IP会发生变化，传统集群依赖固定IP配置，无法动态适应。

3. VIP 漂移无法标准化
   云环境没有原生支持的集群VIP，必须通过脚本绑定/解绑弹性公网IP，流程繁琐、无统一标准，切换可靠性依赖脚本质量。

3.4 传统PostgreSQL高可用工具适配性差

常见的 repmgr、governor 等工具，在云环境中存在明显短板：

• 依赖固定IP、静态配置，无法适应动态拓扑；
• 主从切换后，无法自动通知客户端更新连接；
• 网络分区时，无法强制断开旧主库连接，极易出现双主写入，导致数据丢失与数据不一致；
• 缺乏全局集群视图，容易出现决策冲突。

4. 云原生PostgreSQL高可用的优化方向

4.1 借鉴NoSQL的无共享架构

云原生PostgreSQL高可用，不再走传统共享存储路线，而是直接借鉴 NoSQL 成熟的 Shared-Nothing 架构：

• 所有节点完全对等，无硬件绑定；
• 每个节点使用本地存储；
• 利用 PostgreSQL 原生流复制实现主从数据同步；
• 支持同步复制、异步复制灵活配置。

这种模式不依赖任何特殊硬件，完全适配云环境。

4.2 云原生高可用必须解决的核心问题

1. 自动故障检测与自动故障转移
   主库宕机后，系统能自动选举新主库，无需人工干预。

2. 网络分区容错
   在网络分裂时，保证只有一个主库可写，避免脑裂。

3. 数据一致性保证
   切换过程中不丢数据、不覆盖数据、不产生双主。

4. 对应用透明
   主库切换时，应用不需要修改配置、不需要重启，连接自动路由到新主库。

5. 动态扩缩容
   支持快速增加、删除从库，不影响业务。

5. Stolon架构与核心工作机制

5.1 Stolon要解决的核心问题

Stolon 是专门为云原生、容器、Kubernetes 环境设计的 PostgreSQL 高可用方案，核心解决三大问题：

1. 让 PostgreSQL 真正具备云原生化高可用能力，适配动态IP、弹性节点、不可变基础设施；
2. 在网络分区、节点宕机等异常场景下，严格保证数据一致性，杜绝双主；
3. 极大简化集群部署、维护、切换、扩容流程，实现分钟级集群搭建。

5.2 Stolon三大核心组件

Stolon 采用组件化、无中心化决策架构，由三大核心组件构成完整系统。

5.2.1 Keeper（守护者）

Keeper 是PostgreSQL 实例的生命周期管理者，与 PostgreSQL 实例一一对应（即每个数据库节点部署一个 Keeper 实例），是直接管控 PostgreSQL 生命周期与数据同步的核心组件，也是 Stolon 落地 “无共享架构” 的关键载体。

• 管理 PostgreSQL 启动、停止、配置更新；
• 从集中式存储中获取集群视图；
• 强制让本地 PostgreSQL 状态与集群期望状态保持一致；
• 执行主从切换、复制重建、数据同步等操作。

5.2.2 Sentinel（哨兵）

Sentinel 是集群的监控大脑与决策中心，负责全局状态感知与高可用决策，采用多副本分布式运行，无单点故障。

• 自动发现所有 Keeper 节点；
• 监控节点健康状态、复制延迟；
• 基于全局视图计算最优集群拓扑；
• 在主库故障时发起自动切换；
• 多 Sentinel 之间通过选主避免决策冲突。

5.2.3 Proxy（代理）

首先说明为什么要使用Proxy，也就是为什么要高出代理这个东西来。

由于 stolon 在默认情况下优先考虑一致性而非可用性，因此客户端需要连接到当前集群选举出的主节点，并与未当选的节点断开连接。

例如，如果你连接到当前当选的主节点，随后集群（由于任何合理原因，如网络分区）选举出一个新的主节点，为了实现一致性，客户端需要与旧主节点断开连接（否则它会向旧主节点写入数据，而这些数据在重新同步时将会丢失）。如图所示：

这就是 stolon 代理的作用。可见，Proxy 是面向业务应用的 统一访问入口与流量网关，提供透明路由与脑裂防护能力，是客户端的接入点。

• 所有客户端请求必须经过 Proxy；
• 保证请求只路由到当前合法主库；
• 主库切换时，强制断开旧主库的所有连接，防止双写；
• 对应用完全透明，实现无感知切换。

【Note】：目前，Proxy会将所有请求重定向到主节点。有一个关于将代理也用于备用节点的功能请求，但它在优先级列表中排名较低。

5.3 组件协作与高可用流程

Stolon 整套系统的核心协作基础是 “全局状态存储（etcd/Consul/K8s ConfigMap）”——所有组件不直接点对点通信，而是通过读写状态存储同步信息、执行决策，确保在动态云环境下的一致性与可靠性。以下从“正常运行时协作”“故障切换时协作”两个维度，详细拆解组件交互逻辑：

5.3.1 正常运行时的组件协作流程

当 Stolon 集群处于稳定状态时，三大组件与状态存储形成闭环协作，维持集群正常运转：

1. 状态上报与同步：
   • 每个 Keeper 定期（默认10秒）向状态存储上报本地 PostgreSQL 实例的状态：包括角色（主/从）、健康状态、复制进度（WAL 位点）、节点 IP 等；
   • 所有 Sentinel 实时监听状态存储中的 Keeper 状态数据，动态更新本地维护的“集群全局视图”；
   • Proxy 定期从状态存储中获取当前主库 Keeper 的地址，确保流量路由规则最新。
2. 决策与执行闭环：
   • Sentinel 基于全局视图持续校验集群状态是否符合“期望拓扑”（如主库正常、从库同步延迟在阈值内），若无需调整则维持现状；
   • 若管理员通过 stolonctl 更新集群配置（如修改 PG 参数），配置会先写入状态存储，Keeper 监听并感知变化后，自动重启 PostgreSQL 实例应用新配置；
   • Proxy 仅接收客户端的读写请求，并严格路由至状态存储中标记的“合法主库”，从库仅允许通过主库同步数据，不直接接收客户端请求。
3. 数据同步链路：
   • 主库 Keeper 管理的 PostgreSQL 实例通过原生流复制，将 WAL 日志实时同步至所有从库 Keeper 对应的实例；
   • 从库 Keeper 定期将同步进度（已接收/已应用的 WAL 位点）上报至状态存储，Sentinel 据此监控复制延迟，为故障切换时的“最优从库选择”提供依据。

5.3.2 故障切换时的组件协作流程（核心场景）

当主库 Keeper 故障（如节点宕机、网络中断）时，Stolon 自动触发故障转移，全程无需人工干预，具体流程如下：

1. 故障检测：
   • 主库 Keeper 因故障停止上报状态，Sentinel 监听状态存储发现“主库 Keeper 心跳超时”（默认超时阈值30秒，可配置）；
   • 多个 Sentinel 通过状态存储共享故障信息，避免单一 Sentinel 误判（需超过半数 Sentinel 确认故障）。
2. 决策选举：
   • 多个 Sentinel 通过状态存储的分布式锁竞争“决策权”，仅选举出1个 Leader 负责执行故障切换（避免多决策冲突）；
   • Sentinel Leader 从状态存储中读取所有从库 Keeper 的状态，筛选出“健康且复制延迟最低”的从库作为候选主库（优先选择同步复制完成的从库，确保数据不丢失）；
   • Sentinel Leader 将“候选主库晋升为主库”的决策写入状态存储，更新集群“期望状态”。
3. 角色切换与数据恢复：
   • 候选主库的 Keeper 监听状态存储，感知到“晋升主库”的期望状态后，执行以下操作：停止从库复制进程、提升为独立主库、开启写入权限；
   • 其他从库 Keeper 感知到主库变更后，自动断开与旧主库的连接，重新连接新主库，基于最新 WAL 位点同步数据（支持增量同步，减少切换耗时）；
   • 若旧主库后续恢复正常，其 Keeper 会从状态存储中读取“已被降级为从库”的期望状态，自动清理本地无效数据，重新作为从库连接新主库同步数据，避免双主冲突。
4. 流量切换：
   • Proxy 定期从状态存储中获取新主库的地址，更新路由规则；
   • 对于已建立的旧主库连接，Proxy 强制断开（避免客户端继续写入旧主库），新请求直接路由至新主库；
   • 业务客户端仅需重新发起连接（或依赖连接池自动重连），无需修改任何配置，实现无感知切换。

5.3.3 协作核心原则

1. 无中心化通信：组件间通过状态存储间接交互，避免点对点连接的网络依赖，适配云环境动态拓扑；
2. 状态驱动执行：所有组件的行为均由“状态存储中的期望状态”驱动，确保行为一致；
3. 决策幂等性：即使多个 Sentinel 同时触发决策，状态存储的原子性操作也能保证最终仅执行一次有效切换，避免重复操作；
4. 数据优先：故障切换时优先选择数据最完整的从库晋升主库，确保数据不丢失。

以下是状态示意图：

通过以上流程可见，Stolon 组件协作的核心是“以状态存储为中枢，以数据一致性为优先级”，既适配云环境的动态特性，又能通过标准化流程确保故障切换的可靠性与数据安全性。

5.4 高可用与一致性保证机制

1. 全局唯一集群视图
   所有状态、拓扑、角色都存放在 etcd/Consul 中，Sentinel 基于全局信息做决策，避免局部判断错误。

2. Sentinel 选主机制
   多个 Sentinel 之间通过分布式锁选主，只有 leader 有权执行切换决策，避免多节点同时触发切换。

3. 故障自动转移流程

• Sentinel 检测到主库 Keeper 失联；
• 检查所有从库的复制位置、健康状态；
• 选择最优节点晋升为新主库；
• 更新集群视图到 etcd；
• Keeper 执行角色切换；
• Proxy 感知变化，切断旧主库连接，将流量导向新主库。

1. 强一致性保证
   在任何网络分区下，Stolon 只会维护一个可写主库。旧主库即使恢复正常，也会被强制降级为只读或从库，直到同步完成，彻底杜绝双主写入。

5.5 Stolon 典型部署架构

Stolon 针对云原生环境设计了标准化的部署模式，核心遵循“无中心、多副本、高可用”原则，不同环境下的典型架构如下：

5.5.1 Kubernetes 环境部署架构

在 Kubernetes 集群中，Stolon 组件通过 StatefulSet + Service 部署，利用 K8s 原生能力保障组件高可用：

1. 组件部署形态：
   • 【Keeper】：以 StatefulSet 部署（每个实例绑定独立 PVC 存储 PostgreSQL 数据），建议至少 3 副本（1 主 2 从）；
   • 【Sentinel】：以 Deployment 部署，至少 2 副本（避免决策中心单点故障）；
   • 【Proxy】：以 Deployment 部署，通过 ClusterIP/NodePort/Ingress 对外提供服务，支持弹性扩缩容；
   • 【后端状态存储】：优先使用 K8s 内置 ConfigMap/Secret 存储集群状态（轻量场景），或独立部署 etcd 集群 / Consul等组件。
2. 网络与访问：
   • 所有组件通过 K8s Service 发现彼此，无需固定 IP；
   • 应用仅需连接 Proxy 的 Service 地址，无需感知主库切换。
3. 核心部署原则
   • Sentinel 多副本：至少 2 个副本，避免决策中心单点，保障故障切换决策的可靠性；
   • Keeper 跨可用区：主从节点分布在不同 AZ，提升容灾能力；
   • Proxy 无状态：支持水平扩缩容，应对业务流量波动；
   • 后端存储高可用：etcd/Consul 至少 3 节点，或复用 K8s 高可用配置存储，避免状态存储单点。
4. 部署架构图示
   • 一个典型部署架构如图所示。
     

     注，官方给的一个示意图是这样：
     

5.5.2 公有云 IaaS 环境部署建议

如果是在 AWS/阿里云/华为云等等公有云 IaaS 环境中， Stolon 部署遵循 “跨可用区、去中心化” 原则：

1. 节点分布：Keeper/Sentinel/Proxy 节点分散部署在至少 2 个可用区（AZ），避免单 AZ 故障导致集群不可用；
2. 存储：每个 Keeper 节点绑定云厂商块存储（如 EBS/云盘），通过 PostgreSQL 流复制同步数据；
3. 后端存储：部署 3 节点 etcd 集群（跨 AZ），用于存储集群状态；
4. 访问层：Proxy 节点前置负载均衡（如 ELB/ALB），对外提供统一访问入口，负载均衡自动剔除故障 Proxy 节点。

6. stolonctl命令行管理工具

stolonctl 是 Stolon 集群的统一命令行管理客户端，用于对整个 PostgreSQL 高可用集群进行配置、查看、控制与运维操作，是管理员与 Stolon 集群交互的主要入口。

6.1 基本工作方式

stolonctl 不直接连接 PostgreSQL，而是通过与集群的后端存储（etcd、Consul 或 Kubernetes）交互，获取并修改集群全局状态。使用时需要指定集群名称、存储类型以及存储访问地址，也支持通过环境变量来简化重复参数的输入，让运维命令更简洁、便于脚本化执行。

6.2 主要功能

• 查看集群整体状态、各节点角色与健康状况；
• 执行手动主从切换（failover），用于计划内维护或故障演练；
• 初始化集群、更新全局配置与 PostgreSQL 运行参数；
• 查看集群拓扑结构、复制关系与当前集群视图。

6.3 云原生适配性

在 Kubernetes 等容器环境中，stolonctl 可以直接利用 Pod 内的权限或 kubeconfig 配置访问集群状态，支持在 Pod 内部执行或通过 kubectl 临时运行，与云原生环境、自动化运维体系无缝结合，满足弹性、动态、不可变基础设施下的管理需求。

6.4 常用命令及使用场景

stolonctl 的核心命令覆盖集群运维全流程，以下为生产环境最常用的命令集合，可直接用于脚本与日常操作：

6.4.1 基础状态查看（status/clusterdata）

# 查看集群核心状态（etcdv3 后端示例）
$ stolonctl --cluster-name=stolon-cluster --store-backend=etcdv3 --store-endpoints=http://etcd-0:2379 status

# 查看完整集群拓扑详情
$ stolonctl --cluster-name=stolon-cluster --store-backend=etcdv3 --store-endpoints=http://etcd-0:2379 clusterdata

6.4.2 集群初始化与配置更新（init/update）

# 初始化集群，设置最大连接数
$ stolonctl --cluster-name=stolon-cluster --store-backend=etcdv3 --store-endpoints=http://etcd-0:2379 init --cluster-spec='{"pgParameters": {"max_connections": "2000"}}'

# 动态更新共享缓冲区配置
$ stolonctl --cluster-name=stolon-cluster --store-backend=etcdv3 --store-endpoints=http://etcd-0:2379 update --cluster-spec='{"pgParameters": {"shared_buffers": "4GB"}}'

6.4.3 手动故障切换（failover）

# 先获取目标 keeper 名称
$ stolonctl --cluster-name=stolon-cluster --store-backend=etcdv3 --store-endpoints=http://etcd-0:2379 status | grep "keeper"

# 手动切换至指定从库
$ stolonctl --cluster-name=stolon-cluster --store-backend=etcdv3 --store-endpoints=http://etcd-0:2379 failover --keeper=keeper-1721680321-0

6.4.4 Kubernetes 环境常用执行方式

# 在 Proxy Pod 内执行
$ kubectl exec -it stolon-proxy-7f986d7c4b-2xqzl -- stolonctl --cluster-name=kube-stolon --store-backend=kubernetes --kube-resource-kind=configmap status

# 临时创建 stolonctl Pod 执行
$ kubectl run -it stolonctl-temp --image=sorintlab/stolon:v0.17.0-pg14 --restart=Never --rm -- /usr/local/bin/stolonctl --cluster-name=kube-stolon --store-backend=kubernetes --kube-resource-kind=configmap status

7. 总结

传统基础设施下的 PostgreSQL 高可用依赖共享存储、Corosync/Pacemaker 与 Fencing 机制，在云环境中面临存储不共享、IP 动态变化、网络受限、自动化困难等一系列无法回避的问题。直接迁移传统方案不仅复杂度极高，而且无法保证数据一致性与高可用可靠性。

云原生架构思路则转向 Shared-Nothing 无共享模式，基于 PostgreSQL 原生流复制实现数据冗余，通过服务发现与集中式存储管理集群状态。Stolon 正是这一思路的成熟落地实现，通过 Keeper、Sentinel、Proxy 三大核心组件协同工作，配合 etcd 实现全局一致的集群管理，能够在动态、不可靠的云环境中完成自动故障检测、自动主从切换、强制脑裂防护、应用透明路由。