Stolon实现云原生环境下的PostgreSQL高可用架构概述

• 文章信息 - Author: 李俊才(jcLee95)
  Visit me at CSDN: https://jclee95.blog.csdn.net
  My WebSite ：http://thispage.tech/
  Email: 291148484@163.com.
  Shenzhen China
  Address of this article: https://blog.csdn.net/qq_28550263/article/details/158209946
  HuaWei: https://bbs.huaweicloud.com/blogs/474242

[1. 引言](#1. 引言)

[1.1 传统主流传统高可用技术方案](#1.1 传统主流传统高可用技术方案)

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

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

[1.1.1 Heartbeat + CRM / RHCS](#1.1.1 Heartbeat + CRM / RHCS)

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

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

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

[1.1.2 Corosync + Pacemaker](#1.1.2 Corosync + Pacemaker)

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

[1.2 传统方案的强依赖与关键机制](#1.2 传统方案的强依赖与关键机制)

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

[1.2.1 必须依赖共享存储](#1.2.1 必须依赖共享存储)

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

[1.2.1 必须配置 Fencing / STONITH](#1.2.1 必须配置 Fencing / STONITH)

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

[1.3 传统方案在云环境前的天然缺陷](#1.3 传统方案在云环境前的天然缺陷)

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

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

[2.1 云基础设施的本质特性](#2.1 云基础设施的本质特性)

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

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

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

[2.2 云原生高可用设计思路的核心转变](#2.2 云原生高可用设计思路的核心转变)

1. 从"追求硬件不宕机"转向"接受故障并自动自愈"

   不再投入成本追求绝对可靠的硬件，而是接受节点会挂、网络会断、存储会飘，通过软件架构实现故障屏蔽。

2. 从"共享存储"转向"无共享架构 Shared-Nothing"

   每个节点拥有独立本地存储，数据通过数据库原生复制机制在节点间同步，不再依赖中心化存储设备。

3. 从"静态配置集群"转向"动态发现 + 集中式存储维护状态"

   集群拓扑、角色、地址不再写死在配置文件中，而是存放在 etcd、Consul 这类高可用键值存储中，组件自动发现、自动更新。

4. 从"VIP 漂移"转向"服务发现 + 代理路由"

   不再依赖固定虚拟IP，而是通过统一入口代理，实现对客户端透明的主库切换。

[3. 云IaaS环境自建PostgreSQL高可用的技术难点](#3. 云IaaS环境自建PostgreSQL高可用的技术难点)

[3.1 存储层面无法复用传统模式](#3.1 存储层面无法复用传统模式)

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

[3.1.1 块存储多节点共享限制：无法实现集群共用](#3.1.1 块存储多节点共享限制：无法实现集群共用)

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

[3.1.2 跨可用区（AZ）共享成本极高：可用性与成本矛盾](#3.1.2 跨可用区（AZ）共享成本极高：可用性与成本矛盾)

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

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

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

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

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

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

[3.2 Fencing / STONITH 难以自动化落地](#3.2 Fencing / STONITH 难以自动化落地)

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

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

[3.3 网络环境与传统数据中心完全不同](#3.3 网络环境与传统数据中心完全不同)

1. 多播基本不可用

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

2. 节点IP不固定

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

3. VIP 漂移无法标准化

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

[3.4 传统PostgreSQL高可用工具适配性差](#3.4 传统PostgreSQL高可用工具适配性差)

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

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

[4. 云原生PostgreSQL高可用的优化方向](#4. 云原生PostgreSQL高可用的优化方向)

[4.1 借鉴NoSQL的无共享架构](#4.1 借鉴NoSQL的无共享架构)

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

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

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

[4.2 云原生高可用必须解决的核心问题](#4.2 云原生高可用必须解决的核心问题)

1. 自动故障检测与自动故障转移

   主库宕机后，系统能自动选举新主库，无需人工干预。

2. 网络分区容错

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

3. 数据一致性保证

   切换过程中不丢数据、不覆盖数据、不产生双主。

4. 对应用透明

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

5. 动态扩缩容

   支持快速增加、删除从库，不影响业务。

[5. Stolon架构与核心工作机制](#5. Stolon架构与核心工作机制)

[5.1 Stolon要解决的核心问题](#5.1 Stolon要解决的核心问题)

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

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

[5.2 Stolon三大核心组件](#5.2 Stolon三大核心组件)

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

[5.2.1 Keeper（守护者）](#5.2.1 Keeper（守护者）)

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

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

[5.2.2 Sentinel（哨兵）](#5.2.2 Sentinel（哨兵）)

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

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

[5.2.3 Proxy（代理）](#5.2.3 Proxy（代理）)

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

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

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

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

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

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

[5.3 组件协作与高可用流程](#5.3 组件协作与高可用流程)

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

[5.3.1 正常运行时的组件协作流程](#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 故障切换时的组件协作流程（核心场景）](#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 强制断开（避免客户端继续写入旧主库），新请求直接路由至新主库；
   • 业务客户端仅需重新发起连接（或依赖连接池自动重连），无需修改任何配置，实现无感知切换。

以一主一备为例：
状态存储 业务客户端 Proxy Sentinel(节点2) Sentinel(节点1) Keeper(从库) Keeper(主库) PostgreSQL(从库) PostgreSQL(主库) 状态存储 业务客户端 Proxy Sentinel(节点2) Sentinel(节点1) Keeper(从库) Keeper(主库) PostgreSQL(从库) PostgreSQL(主库) ========== 第一阶段：正常运行时协作 ========== 多Sentinel基于状态存储 维护一致的集群全局视图 定期刷新（默认秒级），保证路由最新 ========== 第二阶段：主库故障切换 ========== 超过阈值后，Sentinel判定主库不可用 需超过半数Sentinel确认，触发切换 筛选规则：健康+复制延迟最低 优先同步复制完成的从库 感知自身已被标记为「从库」 上报状态（角色=主、健康、PG-M的WAL位点、节点IP） 上报状态（角色=从、健康、PG-S复制延迟、节点IP） 监听并拉取所有Keeper状态 监听并拉取所有Keeper状态 拉取当前合法主库Keeper地址（Keeper-M） 发起读写请求 路由请求至主库Keeper 转发请求至PostgreSQL主库 返回请求结果 回传结果给客户端 流复制同步WAL日志 监控复制进度 更新PG-S的复制延迟/已应用WAL位点 故障（节点宕机/网络断）→心跳超时（默认30s）→停止上报 检测到Keeper-M心跳超时 检测到Keeper-M心跳超时 竞争故障切换决策权（分布式锁） 竞争分布式锁（失败，放弃决策） 授予Leader决策权 读取所有从库Keeper状态 写入期望状态（Keeper-S晋升为主库） 监听并感知「晋升主库」的期望状态 停止复制进程→执行pg_promote()→开启写入权限 更新自身状态（角色=主、PG-S新WAL位点） 故障恢复后拉取集群期望状态 停止写入→清理无效数据→重置复制关系 连接新主库Keeper-S对应的PG实例 基于最新WAL位点增量同步数据 拉取新主库地址（Keeper-S） 强制断开与旧主库的连接（防双写） 连接池自动重连/客户端重新发起请求 路由新请求至新主库Keeper 转发请求至新主库PostgreSQL 返回请求结果 回传结果给客户端 Stolon 核心组件交互时序图（正常运行 + 故障切换）

[5.3.3 协作核心原则](#5.3.3 协作核心原则)

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

以下是状态示意图：
全局状态存储
Stolon Sentinel层
Stolon Keeper层
Stolon Proxy层
负载均衡/Service层
业务访问层
流复制同步
流复制同步
上报状态
上报状态
上报状态
监听状态/竞争决策权
监听状态/竞争决策权
获取主库地址
获取主库地址
监控到主库故障
确认故障/选举Leader
推送晋升新主库指令
晋升为主库/更新状态
通知切换路由
通知切换路由
强制断开旧主库连接
路由至新主库
重新同步新主库
业务客户端/应用
业务客户端/应用
负载均衡/K8s Service
Proxy
Proxy
Keeper (PostgreSQL master)
Keeper (PostgreSQL standby)
Keeper (PostgreSQL standby)
Sentinel
Sentinel
etcd/Consul/K8s ConfigMap

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

[5.4 高可用与一致性保证机制](#5.4 高可用与一致性保证机制)

1. 全局唯一集群视图

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

2. Sentinel 选主机制

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

3. 故障自动转移流程

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

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

[5.5 Stolon 典型部署架构](#5.5 Stolon 典型部署架构)

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

[5.5.1 Kubernetes 环境部署架构](#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 环境部署建议](#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命令行管理工具](#6. stolonctl命令行管理工具)

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

[6.1 基本工作方式](#6.1 基本工作方式)

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

[6.2 主要功能](#6.2 主要功能)

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

[6.3 云原生适配性](#6.3 云原生适配性)

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

[6.4 常用命令及使用场景](#6.4 常用命令及使用场景)

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

命令	作用	典型使用场景
status	展示集群当前全局状态、主库信息、keeper 节点健康与角色	日常巡检、故障排查首命令
clusterdata	输出完整集群拓扑，包含所有 keeper、sentinel、proxy 状态	集群结构审计、复制关系验证
init	初始化新集群，指定初始配置（如 PG 参数、初始主库数量）	全新集群部署、环境搭建
failover	手动触发主从切换，指定目标 keeper 或自动选举	计划性主库下线、容灾演练
update	动态更新集群全局配置（如 PG 参数、复制策略）	性能调优、配置热更新
configure	调整 Stolon 组件自身配置（如哨兵监控间隔、代理超时）	集群性能优化、稳定性调参

[6.4.1 基础状态查看（status/clusterdata）](#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）](#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）](#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 环境常用执行方式](#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. 总结](#7. 总结)

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

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