分离故障域
通过反亲和性将实例分散到不同工作节点，并在支持的情况下跨可用区部署。为恢复预留容量。
RUK-COM / 托管数据库集群
让数据持续流动。
让业务持续运行。
面向关键企业系统的数据库集群。根据需求设计复制、故障转移及恢复，并由 Ruk-Com 专家从架构设计支持到实际恢复。
重点方案 / CLOUDNATIVEPG
通过 CloudNativePG 在 Kubernetes 上运行 PostgreSQL
CloudNativePG
CNCF Sandbox 项目
探索架构并模拟故障转移
8
数据库引擎
16
集群架构
4
可交互的生命周期状态
K8s
CloudNativePG 方案
+
KUBERNETES + CLOUDNATIVEPG
Kubernetes 上的 PostgreSQL。
为生产环境设计。
这是我们为希望通过 Kubernetes API 管理 PostgreSQL 的团队推荐的方式。CloudNativePG 负责集群生命周期、流复制及故障转移，同时保持 PostgreSQL 数据路径清晰。
Kubernetes + CloudNativePG
Kubernetes 上的 PostgreSQL，具有独立的写入/读取服务及 WAL 复制。Operator 管理生命周期及故障转移；可选的 PgBouncer 提供连接池，而专用 PVC、备份及 PITR 分别承担不同职责。
应用程序
选择读取/写入端点
已准备就绪
Kubernetes API
集群 CRD · 主 Lease
已准备就绪
PgBouncer 连接池
可选 · 高可用连接池
已准备就绪
CloudNativePG Operator
同步 · 健康状态 · 角色
已准备就绪
cluster-rw
服务 → 当前主节点
已准备就绪
cluster-ro
服务 → 已就绪副本
已准备就绪
主节点 · Pod 1
工作节点 A · 读取/写入
已准备就绪
副本 A · Pod 2
工作节点 B · 仅读
已准备就绪
副本 B · Pod 3
工作节点 C · 仅读
已准备就绪
PVC 1
专用持久化卷
已准备就绪
PVC 2
专用持久化卷
已准备就绪
PVC 3
专用持久化卷
已准备就绪
Barman 云侧车
主节点 Pod 内部 · 逻辑详情
已准备就绪
对象存储
基础备份 + WAL 归档
已准备就绪
新恢复集群
PITR 工作流 · 按需
已准备就绪
写请求
读取结果
复制
监控 / 控制
恢复 / 同步
PVC 挂载
写入表示请求进入数据库。读取表示结果返回客户端；SELECT 请求沿相反方向传输。
写入操作通过 PgBouncer → cluster-rw → 主节点。副本读取结果通过 cluster-ro 返回。主节点直接将 WAL 日志流式传输到副本节点，每个 Pod 都有独立的 PVC。
架构详情及参考
可选的 PgBouncer 位于 cluster-rw 之前。cluster-ro 选择副本；图中未绘出的 cluster-r 允许从所有实例读取。Operator/API 构成控制平面，并非 SQL 路径。PITR 会创建独立的新集群，而不是执行故障转移。红色表示进入数据库的写入请求；绿色表示返回客户端的读取结果，SELECT 请求沿相反方向传输。琥珀色表示复制，蓝色虚线表示监控/控制。为便于阅读，Barman 作为逻辑阶段单独显示；在本例中，它作为 sidecar 运行于被选作备份源的当前主 Pod 内，而不是独立的备份服务器。
来源文档 ↗当前状态下的连接
- 应用程序 → PgBouncer 连接池 · 写请求
- PgBouncer 连接池 → cluster-rw · 写请求
- cluster-rw → 主节点 · Pod 1 · 写请求
- 主节点 · Pod 1 → cluster-rw · 读取结果
- cluster-rw → PgBouncer 连接池 · 读取结果
- PgBouncer 连接池 → 应用程序 · 读取结果
- cluster-ro → 应用程序 · 读取结果
- CloudNativePG Operator → Kubernetes API · 集群/租约同步
- CloudNativePG Operator → cluster-rw · 跟随已选举的主节点
- CloudNativePG Operator → cluster-ro · 就绪副本成员关系
- 副本 A · Pod 2 → cluster-ro · 读取结果
- 主节点 · Pod 1 → 副本 A · Pod 2 · WAL 流式传输
- 副本 B · Pod 3 → cluster-ro · 读取结果
- 主节点 · Pod 1 → 副本 B · Pod 3 · WAL 流式传输
- 主节点 · Pod 1 → PVC 1 · 专用 PVC 挂载
- 副本 A · Pod 2 → PVC 2 · 专用 PVC 挂载
- 副本 B · Pod 3 → PVC 3 · 专用 PVC 挂载
- 主节点 · Pod 1 → Barman 云侧车 · 基础备份 / WAL 源
- Barman 云侧车 → 对象存储 · 备份 + WAL 归档
- 对象存储 → 新恢复集群 · 时间点恢复（PITR）· 恢复到新集群
Operator 负责管理。
SQL 流向数据库。
客户端通过以下端点写入： cluster-rw 通过以下端点读取副本： cluster-ro. cluster-r 从所有就绪实例读取。请根据数据实时性需求选择端点；需要连接池时可添加 PgBouncer。
备份 + WAL。
恢复到新集群。
使用 Barman Cloud 插件，将基础备份及 WAL 归档保存到对象存储。执行 PITR 恢复到新集群，并在切换客户端前验证数据。
连接 Ruk-Com 对象存储 →
01
选择恢复时间点
02
恢复基础备份
03
重放 WAL
04
验证新集群
生产环境检查清单
K8s 上 PostgreSQL 的最佳实践
每个实例配置独立 PVC
验证 IOPS、延迟、WAL 预留空间及 CSI 扩容支持。每个实例维护自己的数据卷。
根据 RPO 选择同步策略
异步复制更灵活。同步复制及故障转移法定人数机制涉及延迟与可用性之间的取舍。
TLS + NetworkPolicy
遵循最小权限原则，将密钥及证书管理与数据库备份分开。
监控 WAL 及备份
通过指标和日志跟踪复制延迟、保留的 WAL、归档及备份，并配备可执行的告警和运维手册。
上线前进行演练
测试主备切换、恢复及重连。设置资源请求和 PDB；PDB 无法防止硬件故障。
PITR 需要可用的基础备份、连续至目标时间点的 WAL，以及可访问的凭据和密钥。同步策略并不意味着在所有情况下都能保证零数据丢失。
选择数据库
不同引擎，不同的弹性路径。
选择引擎和模式，模拟故障、角色切换及重新加入，并区分客户端、复制和恢复路径。
MySQL
MariaDB
Percona
PostgreSQL
MongoDB
Redis
Couchbase
OpenSearch
MySQL 主-主
客户端通过两个 ProxySQL 节点发送 SQL。两个主节点均接受写入并交换二进制日志，额外的从节点提供读取。
数据库客户端
读写操作
已准备就绪
ProxySQL 1
查询路由
已准备就绪
ProxySQL 2
查询路由
已准备就绪
主节点 1
读写操作
已准备就绪
主节点 2
读写操作
已准备就绪
额外副本 1
只读
已准备就绪
额外副本 2
只读
已准备就绪
写请求
读取结果
复制
恢复 / 同步
写入表示请求进入数据库。读取表示结果返回客户端；SELECT 请求沿相反方向传输。
现有两个主节点均提供写入；ProxySQL 路由读写请求，同时通过二进制日志进行复制。
架构详情及参考
默认有两个 ProxySQL 节点。虚线表示的额外节点在此扩展示例中已启用；图示数量并非部署的最低要求。红色表示进入数据库的写入请求；绿色表示返回客户端的读取结果，SELECT 请求沿相反方向传输。琥珀色表示复制，蓝色虚线表示监控/控制。读取路径仅作代表性展示，两个代理共享同一组按角色划分的后端池。
来源文档 ↗当前状态下的连接
- 数据库客户端 → ProxySQL 1 · 写请求
- ProxySQL 1 → 数据库客户端 · 读取结果
- 数据库客户端 → ProxySQL 2 · 写请求
- ProxySQL 2 → 数据库客户端 · 读取结果
- ProxySQL 1 → 主节点 1 · 写请求
- 主节点 1 → ProxySQL 1 · 读取结果
- ProxySQL 1 → 主节点 2 · 写请求
- 额外副本 1 → ProxySQL 1 · 读取结果
- ProxySQL 2 → 主节点 1 · 写请求
- ProxySQL 2 → 主节点 2 · 写请求
- 主节点 2 → ProxySQL 2 · 读取结果
- 额外副本 2 → ProxySQL 2 · 读取结果
- 主节点 1 → 主节点 2 · 二进制日志
- 主节点 2 → 主节点 1 · 二进制日志
- 主节点 1 → 额外副本 1 · 二进制日志
- 主节点 2 → 额外副本 2 · 二进制日志
MySQL 主-从
SQL 经过两个 ProxySQL 节点。一个主节点处理写入，从节点可处理读取。ProxySQL 健康路由不会自动提升主节点。
数据库客户端
读写操作
已准备就绪
ProxySQL 1
查询路由
已准备就绪
ProxySQL 2
查询路由
已准备就绪
主要导航
读写操作
已准备就绪
从节点
只读
已准备就绪
额外副本
只读
已准备就绪
写请求
读取结果
复制
恢复 / 同步
写入表示请求进入数据库。读取表示结果返回客户端；SELECT 请求沿相反方向传输。
一个主节点负责写入操作，并异步将二进制日志复制到从节点。ProxySQL 负责分发读取流量。
架构详情及参考
默认有两个 ProxySQL 节点。虚线表示的额外节点在此扩展示例中已启用；图示数量并非部署的最低要求。红色表示进入数据库的写入请求；绿色表示返回客户端的读取结果，SELECT 请求沿相反方向传输。琥珀色表示复制，蓝色虚线表示监控/控制。读取路径仅作代表性展示，两个代理共享同一组按角色划分的后端池。
来源文档 ↗当前状态下的连接
- 数据库客户端 → ProxySQL 1 · 写请求
- ProxySQL 1 → 数据库客户端 · 读取结果
- 数据库客户端 → ProxySQL 2 · 写请求
- ProxySQL 2 → 数据库客户端 · 读取结果
- ProxySQL 1 → 主要导航 · 写请求
- 主要导航 → ProxySQL 1 · 读取结果
- 额外副本 → ProxySQL 1 · 读取结果
- ProxySQL 2 → 主要导航 · 写请求
- 从节点 → ProxySQL 2 · 读取结果
- 主要导航 → 从节点 · 二进制日志
- 主要导航 → 额外副本 · 二进制日志
MariaDB 主-主
客户端通过两个 ProxySQL 节点发送 SQL。两个主节点均接受写入并交换二进制日志，额外的从节点提供读取。
数据库客户端
读写操作
已准备就绪
ProxySQL 1
查询路由
已准备就绪
ProxySQL 2
查询路由
已准备就绪
主节点 1
读写操作
已准备就绪
主节点 2
读写操作
已准备就绪
额外副本 1
只读
已准备就绪
额外副本 2
只读
已准备就绪
写请求
读取结果
复制
恢复 / 同步
写入表示请求进入数据库。读取表示结果返回客户端；SELECT 请求沿相反方向传输。
现有两个主节点均提供写入；ProxySQL 路由读写请求，同时通过二进制日志进行复制。
架构详情及参考
默认有两个 ProxySQL 节点。虚线表示的额外节点在此扩展示例中已启用；图示数量并非部署的最低要求。红色表示进入数据库的写入请求；绿色表示返回客户端的读取结果，SELECT 请求沿相反方向传输。琥珀色表示复制，蓝色虚线表示监控/控制。读取路径仅作代表性展示，两个代理共享同一组按角色划分的后端池。
来源文档 ↗当前状态下的连接
- 数据库客户端 → ProxySQL 1 · 写请求
- ProxySQL 1 → 数据库客户端 · 读取结果
- 数据库客户端 → ProxySQL 2 · 写请求
- ProxySQL 2 → 数据库客户端 · 读取结果
- ProxySQL 1 → 主节点 1 · 写请求
- 主节点 1 → ProxySQL 1 · 读取结果
- ProxySQL 1 → 主节点 2 · 写请求
- 额外副本 1 → ProxySQL 1 · 读取结果
- ProxySQL 2 → 主节点 1 · 写请求
- ProxySQL 2 → 主节点 2 · 写请求
- 主节点 2 → ProxySQL 2 · 读取结果
- 额外副本 2 → ProxySQL 2 · 读取结果
- 主节点 1 → 主节点 2 · 二进制日志
- 主节点 2 → 主节点 1 · 二进制日志
- 主节点 1 → 额外副本 1 · 二进制日志
- 主节点 2 → 额外副本 2 · 二进制日志
MariaDB 主-从
SQL 经过两个 ProxySQL 节点。一个主节点处理写入，从节点可处理读取。ProxySQL 健康路由不会自动提升主节点。
数据库客户端
读写操作
已准备就绪
ProxySQL 1
查询路由
已准备就绪
ProxySQL 2
查询路由
已准备就绪
主要导航
读写操作
已准备就绪
从节点
只读
已准备就绪
额外副本
只读
已准备就绪
写请求
读取结果
复制
恢复 / 同步
写入表示请求进入数据库。读取表示结果返回客户端；SELECT 请求沿相反方向传输。
一个主节点负责写入操作，并异步将二进制日志复制到从节点。ProxySQL 负责分发读取流量。
架构详情及参考
默认有两个 ProxySQL 节点。虚线表示的额外节点在此扩展示例中已启用；图示数量并非部署的最低要求。红色表示进入数据库的写入请求；绿色表示返回客户端的读取结果，SELECT 请求沿相反方向传输。琥珀色表示复制，蓝色虚线表示监控/控制。读取路径仅作代表性展示，两个代理共享同一组按角色划分的后端池。
来源文档 ↗当前状态下的连接
- 数据库客户端 → ProxySQL 1 · 写请求
- ProxySQL 1 → 数据库客户端 · 读取结果
- 数据库客户端 → ProxySQL 2 · 写请求
- ProxySQL 2 → 数据库客户端 · 读取结果
- ProxySQL 1 → 主要导航 · 写请求
- 主要导航 → ProxySQL 1 · 读取结果
- 额外副本 → ProxySQL 1 · 读取结果
- ProxySQL 2 → 主要导航 · 写请求
- 从节点 → ProxySQL 2 · 读取结果
- 主要导航 → 从节点 · 二进制日志
- 主要导航 → 额外副本 · 二进制日志
MariaDB Galera
客户端使用两个 ProxySQL 节点连接可写数据库节点。写入集认证在保留多数节点的组件中协调变更。
数据库客户端
读写操作
已准备就绪
ProxySQL 1
查询路由
已准备就绪
ProxySQL 2
查询路由
已准备就绪
主节点 1
认证写入集
已准备就绪
主节点 2
认证写入集
已准备就绪
主节点 3
认证写入集
已准备就绪
主节点 4
认证写入集
已准备就绪
写请求
读取结果
复制
恢复 / 同步
写入表示请求进入数据库。读取表示结果返回客户端；SELECT 请求沿相反方向传输。
所有四个示例节点均参与，包括可选的额外节点。写入集在可写节点之间复制。
架构详情及参考
默认有两个 ProxySQL 节点。虚线表示的额外节点在此扩展示例中已启用；图示数量并非部署的最低要求。红色表示进入数据库的写入请求；绿色表示返回客户端的读取结果，SELECT 请求沿相反方向传输。琥珀色表示复制，蓝色虚线表示监控/控制。读取路径仅作代表性展示，两个代理共享同一组按角色划分的后端池。复制路径表示组内写集交换，而非链式复制。
来源文档 ↗当前状态下的连接
- 数据库客户端 → ProxySQL 1 · 写请求
- ProxySQL 1 → 数据库客户端 · 读取结果
- 数据库客户端 → ProxySQL 2 · 写请求
- ProxySQL 2 → 数据库客户端 · 读取结果
- ProxySQL 1 → 主节点 1 · 写请求
- 主节点 1 → ProxySQL 1 · 读取结果
- ProxySQL 1 → 主节点 2 · 写请求
- ProxySQL 1 → 主节点 3 · 写请求
- 主节点 3 → ProxySQL 1 · 读取结果
- ProxySQL 1 → 主节点 4 · 写请求
- ProxySQL 2 → 主节点 1 · 写请求
- ProxySQL 2 → 主节点 2 · 写请求
- 主节点 2 → ProxySQL 2 · 读取结果
- ProxySQL 2 → 主节点 3 · 写请求
- ProxySQL 2 → 主节点 4 · 写请求
- 主节点 4 → ProxySQL 2 · 读取结果
- 主节点 1 → 主节点 2 · 组写入集
- 主节点 2 → 主节点 1 · 组写入集
- 主节点 2 → 主节点 3 · 组写入集
- 主节点 3 → 主节点 2 · 组写入集
- 主节点 3 → 主节点 4 · 组写入集
- 主节点 4 → 主节点 3 · 组写入集
Percona 主-主
客户端通过两个 ProxySQL 节点发送 SQL。两个主节点均接受写入并交换二进制日志，额外的从节点提供读取。
数据库客户端
读写操作
已准备就绪
ProxySQL 1
查询路由
已准备就绪
ProxySQL 2
查询路由
已准备就绪
主节点 1
读写操作
已准备就绪
主节点 2
读写操作
已准备就绪
额外副本 1
只读
已准备就绪
额外副本 2
只读
已准备就绪
写请求
读取结果
复制
恢复 / 同步
写入表示请求进入数据库。读取表示结果返回客户端；SELECT 请求沿相反方向传输。
现有两个主节点均提供写入；ProxySQL 路由读写请求，同时通过二进制日志进行复制。
架构详情及参考
默认有两个 ProxySQL 节点。虚线表示的额外节点在此扩展示例中已启用；图示数量并非部署的最低要求。红色表示进入数据库的写入请求；绿色表示返回客户端的读取结果，SELECT 请求沿相反方向传输。琥珀色表示复制，蓝色虚线表示监控/控制。读取路径仅作代表性展示，两个代理共享同一组按角色划分的后端池。
来源文档 ↗当前状态下的连接
- 数据库客户端 → ProxySQL 1 · 写请求
- ProxySQL 1 → 数据库客户端 · 读取结果
- 数据库客户端 → ProxySQL 2 · 写请求
- ProxySQL 2 → 数据库客户端 · 读取结果
- ProxySQL 1 → 主节点 1 · 写请求
- 主节点 1 → ProxySQL 1 · 读取结果
- ProxySQL 1 → 主节点 2 · 写请求
- 额外副本 1 → ProxySQL 1 · 读取结果
- ProxySQL 2 → 主节点 1 · 写请求
- ProxySQL 2 → 主节点 2 · 写请求
- 主节点 2 → ProxySQL 2 · 读取结果
- 额外副本 2 → ProxySQL 2 · 读取结果
- 主节点 1 → 主节点 2 · 二进制日志
- 主节点 2 → 主节点 1 · 二进制日志
- 主节点 1 → 额外副本 1 · 二进制日志
- 主节点 2 → 额外副本 2 · 二进制日志
Percona 主-从
SQL 经过两个 ProxySQL 节点。一个主节点处理写入，从节点可处理读取。ProxySQL 健康路由不会自动提升主节点。
数据库客户端
读写操作
已准备就绪
ProxySQL 1
查询路由
已准备就绪
ProxySQL 2
查询路由
已准备就绪
主要导航
读写操作
已准备就绪
从节点
只读
已准备就绪
额外副本
只读
已准备就绪
写请求
读取结果
复制
恢复 / 同步
写入表示请求进入数据库。读取表示结果返回客户端；SELECT 请求沿相反方向传输。
一个主节点负责写入操作，并异步将二进制日志复制到从节点。ProxySQL 负责分发读取流量。
架构详情及参考
默认有两个 ProxySQL 节点。虚线表示的额外节点在此扩展示例中已启用；图示数量并非部署的最低要求。红色表示进入数据库的写入请求；绿色表示返回客户端的读取结果，SELECT 请求沿相反方向传输。琥珀色表示复制，蓝色虚线表示监控/控制。读取路径仅作代表性展示，两个代理共享同一组按角色划分的后端池。
来源文档 ↗当前状态下的连接
- 数据库客户端 → ProxySQL 1 · 写请求
- ProxySQL 1 → 数据库客户端 · 读取结果
- 数据库客户端 → ProxySQL 2 · 写请求
- ProxySQL 2 → 数据库客户端 · 读取结果
- ProxySQL 1 → 主要导航 · 写请求
- 主要导航 → ProxySQL 1 · 读取结果
- 额外副本 → ProxySQL 1 · 读取结果
- ProxySQL 2 → 主要导航 · 写请求
- 从节点 → ProxySQL 2 · 读取结果
- 主要导航 → 从节点 · 二进制日志
- 主要导航 → 额外副本 · 二进制日志
Percona XtraDB
客户端使用两个 ProxySQL 节点连接可写数据库节点。写入集认证在保留多数节点的组件中协调变更。
数据库客户端
读写操作
已准备就绪
ProxySQL 1
查询路由
已准备就绪
ProxySQL 2
查询路由
已准备就绪
主节点 1
认证写入集
已准备就绪
主节点 2
认证写入集
已准备就绪
主节点 3
认证写入集
已准备就绪
主节点 4
认证写入集
已准备就绪
写请求
读取结果
复制
恢复 / 同步
写入表示请求进入数据库。读取表示结果返回客户端；SELECT 请求沿相反方向传输。
所有四个示例节点均参与，包括可选的额外节点。写入集在可写节点之间复制。
架构详情及参考
默认有两个 ProxySQL 节点。虚线表示的额外节点在此扩展示例中已启用；图示数量并非部署的最低要求。红色表示进入数据库的写入请求；绿色表示返回客户端的读取结果，SELECT 请求沿相反方向传输。琥珀色表示复制，蓝色虚线表示监控/控制。读取路径仅作代表性展示，两个代理共享同一组按角色划分的后端池。复制路径表示组内写集交换，而非链式复制。
来源文档 ↗当前状态下的连接
- 数据库客户端 → ProxySQL 1 · 写请求
- ProxySQL 1 → 数据库客户端 · 读取结果
- 数据库客户端 → ProxySQL 2 · 写请求
- ProxySQL 2 → 数据库客户端 · 读取结果
- ProxySQL 1 → 主节点 1 · 写请求
- 主节点 1 → ProxySQL 1 · 读取结果
- ProxySQL 1 → 主节点 2 · 写请求
- ProxySQL 1 → 主节点 3 · 写请求
- 主节点 3 → ProxySQL 1 · 读取结果
- ProxySQL 1 → 主节点 4 · 写请求
- ProxySQL 2 → 主节点 1 · 写请求
- ProxySQL 2 → 主节点 2 · 写请求
- 主节点 2 → ProxySQL 2 · 读取结果
- ProxySQL 2 → 主节点 3 · 写请求
- ProxySQL 2 → 主节点 4 · 写请求
- 主节点 4 → ProxySQL 2 · 读取结果
- 主节点 1 → 主节点 2 · 组写入集
- 主节点 2 → 主节点 1 · 组写入集
- 主节点 2 → 主节点 3 · 组写入集
- 主节点 3 → 主节点 2 · 组写入集
- 主节点 3 → 主节点 4 · 组写入集
- 主节点 4 → 主节点 3 · 组写入集
PostgreSQL 标准版
客户端直接连接 PostgreSQL：写入使用主节点，已配置的读取连接使用从节点。没有代理或自动故障转移管理器。
数据库客户端
读写操作
已准备就绪
主要导航
读写操作
已准备就绪
从节点
只读
已准备就绪
额外副本
只读
已准备就绪
写请求
读取结果
复制
恢复 / 同步
写入表示请求进入数据库。读取表示结果返回客户端；SELECT 请求沿相反方向传输。
主节点异步向从节点流式传输 WAL。查询遵循节点角色；虚线成员表示已启用的扩展示例。
架构详情及参考
一个主节点、一个从节点，以及一个可选的额外从节点。本例已启用虚线扩展节点。红色表示进入数据库的写入请求；绿色表示返回客户端的读取结果，SELECT 请求沿相反方向传输。琥珀色表示复制，蓝色虚线表示监控/控制。
来源文档 ↗当前状态下的连接
- 数据库客户端 → 主要导航 · 写请求
- 主要导航 → 数据库客户端 · 读取结果
- 从节点 → 数据库客户端 · 读取结果
- 额外副本 → 数据库客户端 · 读取结果
- 主要导航 → 从节点 · WAL
- 主要导航 → 额外副本 · WAL
PostgreSQL + Pgpool-II
客户端使用活跃的 Pgpool-II，并通过 Watchdog 与备用代理协调。写入到达主节点，从节点提供读取。Pgpool-II 监控数据库健康状况并管理故障转移。
数据库客户端
读写操作
已准备就绪
Pgpool 主用
读写路由
已准备就绪
Pgpool 备用
监控守护进程
已准备就绪
Pgpool 备用
监控守护进程
已准备就绪
主要导航
读写操作
已准备就绪
从节点
只读
已准备就绪
额外副本
只读
已准备就绪
写请求
读取结果
复制
监控 / 控制
恢复 / 同步
写入表示请求进入数据库。读取表示结果返回客户端；SELECT 请求沿相反方向传输。
主节点异步向从节点流式传输 WAL。查询遵循节点角色；虚线成员表示已启用的扩展示例。
架构详情及参考
一个活跃的 Pgpool-II 节点、两个可选备用节点，以及图示的三个数据库成员。WAL 复制为异步复制；此架构不是 Patroni。红色表示进入数据库的写入请求；绿色表示返回客户端的读取结果，SELECT 请求沿相反方向传输。琥珀色表示复制，蓝色虚线表示监控/控制。
来源文档 ↗当前状态下的连接
- 数据库客户端 → Pgpool 主用 · 写请求
- Pgpool 主用 → 数据库客户端 · 读取结果
- Pgpool 主用 → Pgpool 备用 · 监控守护进程
- Pgpool 备用 → Pgpool 主用 · 监控守护进程
- Pgpool 主用 → Pgpool 备用 · 监控守护进程
- Pgpool 备用 → Pgpool 主用 · 监控守护进程
- Pgpool 主用 → 主要导航 · 写请求
- 主要导航 → Pgpool 主用 · 读取结果
- 从节点 → Pgpool 主用 · 读取结果
- 额外副本 → Pgpool 主用 · 读取结果
- 主要导航 → 从节点 · WAL
- 主要导航 → 额外副本 · WAL
- Pgpool 主用 → 主要导航 · 监控/角色检查
- Pgpool 主用 → 从节点 · 监控/角色检查
- Pgpool 主用 → 额外副本 · 监控/角色检查
PostgreSQL 高可用性 · Patroni + HAProxy
HAProxy 将主节点写入端点与副本读取端点分离，并可选择为每个节点配置 PgBouncer 连接池。Patroni 通过 etcd 法定人数机制协调角色；PostgreSQL 直接在数据库节点之间流式传输 WAL。
应用程序
读写端点
已准备就绪
HAProxy/云负载均衡器
角色感知 SQL 路由
已准备就绪
PgBouncer 1
可选连接池
已准备就绪
PgBouncer 2
可选连接池
已准备就绪
PgBouncer 3
可选连接池
已准备就绪
PgBouncer 4
可选连接池
已准备就绪
副本 · 节点 1
PostgreSQL + Patroni
已准备就绪
主节点 · 节点 2
PostgreSQL + Patroni
已准备就绪
副本 · 节点 3
PostgreSQL + Patroni
已准备就绪
额外副本
PostgreSQL + Patroni
已准备就绪
etcd 1
DCS · 多数成员
已准备就绪
etcd 2
DCS · 多数成员
已准备就绪
etcd 3
DCS · 多数成员
已准备就绪
写请求
读取结果
复制
监控 / 控制
恢复 / 同步
写入表示请求进入数据库。读取表示结果返回客户端；SELECT 请求沿相反方向传输。
写入根据领导者锁路由至节点 2，副本提供读取结果。PgBouncer 提供连接池，WAL 则直接从主节点流向副本。
架构详情及参考
三个 PostgreSQL 节点及一个可选的横向扩展副本，配有三个 etcd 成员。PgBouncer 和 VIP 均为可选项。HAProxy 检查 Patroni 角色；etcd 不传输 SQL 或 WAL。此架构与 CloudNativePG 不同。红色表示进入数据库的写入请求；绿色表示返回客户端的读取结果，SELECT 请求沿相反方向传输。琥珀色表示复制，蓝色虚线表示监控/控制。
来源文档 ↗当前状态下的连接
- 应用程序 → HAProxy/云负载均衡器 · 写请求
- HAProxy/云负载均衡器 → 应用程序 · 读取结果
- HAProxy/云负载均衡器 → PgBouncer 2 · 写请求
- PgBouncer 2 → 主节点 · 节点 2 · 写请求
- 主节点 · 节点 2 → PgBouncer 2 · 读取结果
- PgBouncer 2 → HAProxy/云负载均衡器 · 读取结果
- 副本 · 节点 1 → PgBouncer 1 · 读取结果
- PgBouncer 1 → HAProxy/云负载均衡器 · 读取结果
- 主节点 · 节点 2 → 副本 · 节点 1 · WAL 流式传输
- 副本 · 节点 3 → PgBouncer 3 · 读取结果
- PgBouncer 3 → HAProxy/云负载均衡器 · 读取结果
- 主节点 · 节点 2 → 副本 · 节点 3 · WAL 流式传输
- 额外副本 → PgBouncer 4 · 读取结果
- PgBouncer 4 → HAProxy/云负载均衡器 · 读取结果
- 主节点 · 节点 2 → 额外副本 · WAL 流式传输
- HAProxy/云负载均衡器 → 主节点 · 节点 2 · /primary 健康检查
- 主节点 · 节点 2 → etcd 2 · Patroni · 主节点 / 成员状态
- HAProxy/云负载均衡器 → 副本 · 节点 1 · /replica?lag 健康检查
- 副本 · 节点 1 → etcd 1 · Patroni · 主节点 / 成员状态
- HAProxy/云负载均衡器 → 副本 · 节点 3 · /replica?lag 健康检查
- 副本 · 节点 3 → etcd 3 · Patroni · 主节点 / 成员状态
- HAProxy/云负载均衡器 → 额外副本 · /replica?lag 健康检查
- 额外副本 → etcd 3 · Patroni · 主节点 / 成员状态
- etcd 1 → etcd 2 · Raft 法定多数
- etcd 2 → etcd 3 · Raft 法定多数
MongoDB 副本集
驱动程序发现副本集成员，并将写操作发送到主节点。读操作默认使用主节点，或根据读偏好使用次节点。无需单独的代理组件。
MongoDB 驱动程序
副本集发现
已准备就绪
主要导航
写操作
已准备就绪
从节点 1
Oplog 副本
已准备就绪
从节点 2
Oplog 副本
已准备就绪
写请求
读取结果
复制
监控 / 控制
恢复 / 同步
写入表示请求进入数据库。读取表示结果返回客户端；SELECT 请求沿相反方向传输。
主节点将写入记录到 oplog，从节点异步复制。驱动根据角色及读取偏好选择目标。
架构详情及参考
三个存储数据的成员。选举需要多数投票；选举时间不构成 SLA，从节点读取也可能存在延迟。红色表示进入数据库的写入请求；绿色表示返回客户端的读取结果，SELECT 请求沿相反方向传输。琥珀色表示复制，蓝色虚线表示监控/控制。
来源文档 ↗当前状态下的连接
- MongoDB 驱动程序 → 主要导航 · 写请求
- 主要导航 → MongoDB 驱动程序 · 读取结果
- 从节点 1 → MongoDB 驱动程序 · 读结果 · secondaryPreferred
- 从节点 2 → MongoDB 驱动程序 · 读结果 · secondaryPreferred
- 主要导航 → 从节点 1 · Oplog
- 主要导航 → 从节点 2 · Oplog
- 从节点 1 → 从节点 2 · 心跳 / 投票
Redis 集群
集群感知客户端直接将命令发送到拥有每个哈希槽的主节点。每个主节点对应一个副本。该拓扑结构不使用代理或 Sentinel。
集群客户端
哈希槽路由
已准备就绪
主节点 1
分片 1
已准备就绪
副本 1
分片 1 复制
已准备就绪
主节点 2
分片 2
已准备就绪
副本 2
分片 2 复制
已准备就绪
主节点 3
分片 3
已准备就绪
副本 3
分片 3 复制
已准备就绪
写请求
读取结果
复制
监控 / 控制
恢复 / 同步
写入表示请求进入数据库。读取表示结果返回客户端；SELECT 请求沿相反方向传输。
三个分片将哈希槽进行划分。每个主节点负责其槽位，并异步复制到配对的副本。
架构详情及参考
三个主节点和三个副本，共六个节点。扩容通过增加成对节点并重新分片完成；异步复制可能在故障转移时丢失部分写入。红色表示进入数据库的写入请求；绿色表示返回客户端的读取结果，SELECT 请求沿相反方向传输。琥珀色表示复制，蓝色虚线表示监控/控制。
来源文档 ↗当前状态下的连接
- 集群客户端 → 主节点 1 · 写请求
- 主节点 1 → 集群客户端 · 读取结果
- 主节点 1 → 副本 1 · 异步复制
- 集群客户端 → 主节点 2 · 写请求
- 主节点 2 → 集群客户端 · 读取结果
- 主节点 2 → 副本 2 · 异步复制
- 集群客户端 → 主节点 3 · 写请求
- 主节点 3 → 集群客户端 · 读取结果
- 主节点 3 → 副本 3 · 异步复制
Couchbase 集群
SDK 使用 vBucket 映射直接路由。节点持有活跃和副本 vBucket。扩容通过重新平衡分配数据，不存在独立的查询代理。
Couchbase SDK
vBucket 路由
已准备就绪
Couchbase 1
主动 + 副本 vBuckets
已准备就绪
Couchbase 2
主动 + 副本 vBuckets
已准备就绪
Couchbase 3
主动 + 副本 vBuckets
已准备就绪
Couchbase 4
主动 + 副本 vBuckets
已准备就绪
写请求
读取结果
复制
恢复 / 同步
写入表示请求进入数据库。读取表示结果返回客户端；SELECT 请求沿相反方向传输。
SDK 根据 vBucket 映射路由，副本分区位于其他成员上。箭头表示分区放置，并不意味着每个节点均保存完整数据库副本。
架构详情及参考
参考图使用两个实线节点和两个虚线节点表示扩展，并非两节点部署基线。套餐默认三个节点，本例启用全部四个节点。请适当配置副本及故障转移。红色表示进入数据库的写入请求；绿色表示返回客户端的读取结果，SELECT 请求沿相反方向传输。琥珀色表示复制，蓝色虚线表示监控/控制。
来源文档 ↗当前状态下的连接
- Couchbase SDK → Couchbase 1 · 写请求
- Couchbase 1 → Couchbase SDK · 读取结果
- Couchbase SDK → Couchbase 2 · 写请求
- Couchbase 2 → Couchbase SDK · 读取结果
- Couchbase SDK → Couchbase 3 · 写请求
- Couchbase 3 → Couchbase SDK · 读取结果
- Couchbase SDK → Couchbase 4 · 写请求
- Couchbase 4 → Couchbase SDK · 读取结果
- Couchbase 1 → Couchbase 2 · vBuckets
- Couchbase 2 → Couchbase 3 · vBuckets
- Couchbase 3 → Couchbase 4 · vBuckets
- Couchbase 4 → Couchbase 1 · vBuckets
OpenSearch 集群
Beats 通过 Logstash 将数据发送至 OpenSearch，Dashboards 对其查询并可视化。本例将 OpenSearch 扩展为三个节点，以说明分片恢复，并非套餐的最低配置。
Beats
数据分发器
已准备就绪
Logstash
转换/摄入
已准备就绪
仪表盘
搜索/可视化
已准备就绪
OpenSearch 1
分片 A 主节点
已准备就绪
OpenSearch 2
分片 A 副本
已准备就绪
OpenSearch 3
其他分片
已准备就绪
写请求
读取结果
复制
恢复 / 同步
写入表示请求进入数据库。读取表示结果返回客户端；SELECT 请求沿相反方向传输。
Logstash 负责数据摄取，Dashboards 负责搜索。分片 A 的主分片位于节点 1，副本位于节点 2；节点 3 持有其他分片。
架构详情及参考
参考流程：Beats → Logstash → OpenSearch ← Dashboards。Logstash 和 Dashboards 均为可选项。分片 A 的位置仅作示意，并非全局数据库写入节点。红色表示进入数据库的写入请求；绿色表示返回客户端的读取结果，SELECT 请求沿相反方向传输。琥珀色表示复制，蓝色虚线表示监控/控制。
来源文档 ↗当前状态下的连接
- Beats → Logstash · 摄入事件
- Logstash → OpenSearch 1 · 索引文档
- Logstash → OpenSearch 3 · 索引文档
- OpenSearch 1 → 仪表盘 · 搜索结果
- OpenSearch 2 → 仪表盘 · 搜索结果
- OpenSearch 3 → 仪表盘 · 搜索结果
- OpenSearch 1 → OpenSearch 2 · 分片 A 副本
自动故障转移取决于拓扑、法定人数及配置。MySQL / MariaDB / Percona 的主从模式及标准 PostgreSQL，需要由运维人员提升主节点并调整路由。
可用性 + 可恢复性
保障可用性。
为恢复做好准备。
复制维护实时副本，备份则提供删除或非预期变更之前的恢复点。企业数据保护需要两者兼备。
匹配工作负载的复制方式
根据引擎、延迟、一致性及 RPO 需求，选择异步复制、流复制或基于法定人数的复制。
条件明确的故障转移
路由写入前，验证候选节点、法定人数及原主节点的隔离情况。测试客户端重连及重试行为。
能够验证的恢复能力
明确保留策略、恢复点及恢复演练。将备份与集群分开保存，并验证恢复后的数据可用。
重新加入 ≠ 就绪
节点返回 → 检查时间线 / 日志 → 追赶同步或重建 → 验证就绪状态 → 恢复流量
RUK-COM / 数据库运维
不止于集群部署。
覆盖数据全生命周期的专业能力。
根据系统的重要性确定服务范围及 SLA，涵盖性能、事件响应和恢复规划。
性能与可观测性
跟踪查询延迟、连接、复制延迟、慢查询、存储及备份结果，及早识别问题。
容量与扩展
为各引擎规划只读副本、连接池及存储增长，同时考虑 IOPS、WAL / binlog 及恢复预留空间。
将安全融入设计
设计私有连接、TLS 及基于角色的权限，使机密信息管理、补丁及审计实践符合您的政策。
专家事件支持
专家调查客户端连接、查询、代理、复制及底层基础设施。
维护与恢复演练
在生产环境变更前，测试主备切换、故障转移、恢复及回滚，并提供可重复使用的运维手册和结果记录。
Ruk-Com Agent + 专家
Agent 辅助汇总异常并确定调查优先级。访问及系统变更遵循约定的权限和流程。
评估 / 迁移 / 运维
有计划的迁移。
清晰的运维模式。
01
评估
审查引擎、版本、规模、扩展及 RPO / RTO。
交付成果
范围与系统目标
02
设计与演练
选择拓扑，并使用获授权的数据演练。
交付成果
架构与测试计划
03
同步与切换
验证数据，并根据迁移方式明确停止写入及回滚安排。
交付成果
验证与回滚计划
04
运维与改进
移交运维手册、监控、备份及容量计划。
交付成果
运维手册与运营计划
部署之前
在部署之前
明确数据库集群方案。
有高可用架构后，仍需要备份吗？
需要。删除或非预期变更可能复制到所有副本。应维护独立备份、适当的保留期限，并定期测试恢复。
所有模式都会自动提升主节点吗？
不会。有些模式依赖法定人数及健康检测，另一些需要手动提升主节点，尤其是此处参考的 MySQL 系列主从模式及标准 PostgreSQL 模式。
重新加入的节点能立即处理流量吗？
应先验证一致性及追赶同步状态。根据引擎及保留的历史记录，恢复可能使用 binlog、WAL、oplog、IST / SST 或重建。
可以预期怎样的 RPO / RTO？
根据各系统的同步策略、数据量、网络、备份及恢复方式，按照标准 99.9% SLA 定义并测试目标，同时明确范围及排除事项。
需要准备哪些信息？
请提供引擎及版本、数据量、读写工作负载、峰值连接数、扩展、安全需求及迁移窗口。
您的数据 / 我们的专业能力
从关键数据出发。
共同构建合适的集群。
与 Ruk-Com 讨论架构、迁移及托管服务范围。