docs: add pg16 dr resource application doc #4
@ -138,6 +138,16 @@
|
||||
|
||||
## ✅ 最新完成任务 (持续更新)
|
||||
|
||||
### 📋 PostgreSQL 16 容灾资源申请专题
|
||||
|
||||
- [x] **完成 PostgreSQL 16 容灾与资源申请专题文档** ✅ (2026-03-24)
|
||||
- [x] 新增独立专题文档，支撑甲方资源申请 ✅
|
||||
- [x] 已补齐多种容灾形态及部署说明 ✅
|
||||
- [x] 已补齐主备资源比例与申请清单 ✅
|
||||
- [x] 已补齐网络、存储、切换与恢复要求 ✅
|
||||
- [x] 已补齐 PostgreSQL 代理架构、`HAProxy` / `PgBouncer` 配置样例与应用接入建议 ✅
|
||||
- [x] 已补齐计划切换、故障切换、回切、检查表与验证表 ✅
|
||||
|
||||
### 📋 010-bank-transfer-config 银行文件传输配置能力
|
||||
|
||||
- [x] **完成 `010-bank-transfer-config` 文档与 backend 闭环实现** ✅ (2026-03-24)
|
||||
|
||||
@ -0,0 +1,644 @@
|
||||
---
|
||||
doc_id: TC-07-PGSQL-DR
|
||||
doc_role: supplemental_document
|
||||
authority: secondary
|
||||
scope: PostgreSQL 16 容灾资源申请
|
||||
source_of_truth: false
|
||||
last_reviewed: 2026-03-24
|
||||
retrieval_priority: P1
|
||||
---
|
||||
|
||||
# 福建水务营收系统 PostgreSQL 16 容灾与资源申请说明
|
||||
|
||||
## 文档信息
|
||||
| 项目信息 | 详情 |
|
||||
|---------|------|
|
||||
| **项目名称** | 福建水务营收系统 |
|
||||
| **文档类型** | 技术专题说明 |
|
||||
| **专题用途** | 向甲方申请 PostgreSQL 16 容灾部署资源 |
|
||||
| **文档版本** | v1.0 |
|
||||
| **编写日期** | 2026-03-24 |
|
||||
| **文档状态** | ✅ 正式建议稿 |
|
||||
|
||||
## 目录
|
||||
|
||||
1. 编制目的
|
||||
2. 适用范围与说明
|
||||
3. 容灾建设目标
|
||||
4. 容灾形态说明
|
||||
5. 资源配比原则
|
||||
6. 推荐部署方案
|
||||
7. 甲方审批汇总表
|
||||
8. 详细资源申请清单
|
||||
9. 网络与存储要求
|
||||
10. 数据库代理与连接接入方案
|
||||
11. 部署实施说明
|
||||
12. 切换与恢复说明
|
||||
13. 切换实施细则
|
||||
14. 申请结论
|
||||
|
||||
## 编制目的
|
||||
|
||||
本文档用于说明福建水务营收系统采用 PostgreSQL 16 建设数据库高可用与灾难恢复能力时，所需的资源规模、部署形态、主备配比及实施要求，作为甲方进行服务器、存储、网络及运行环境审批的依据。
|
||||
|
||||
## 适用范围与说明
|
||||
|
||||
1. 本文档面向 PostgreSQL 16 数据库部署专题，重点说明容灾与资源申请口径。
|
||||
2. 本文档用于资源论证与部署申请，不替代数据库主文档和总体部署主文档。
|
||||
3. 文中关于备库资源比例、网络带宽、存储冗余和部署组合的建议，属于结合 PostgreSQL 16 流复制、热备与时间点恢复机制形成的工程实施建议。
|
||||
|
||||
## 容灾建设目标
|
||||
|
||||
PostgreSQL 16 容灾建设目标如下：
|
||||
|
||||
1. 在主库节点故障时，保障数据库能够快速切换并恢复服务。
|
||||
2. 在误操作、逻辑损坏、批量异常更新等场景下，保障系统具备时间点恢复能力。
|
||||
3. 在核心收费、账务、对账等业务场景中，尽量降低故障切换时的数据丢失风险。
|
||||
4. 在资源投入可控的前提下，为甲方提供可分阶段实施的多种建设形态。
|
||||
|
||||
## 容灾形态说明
|
||||
|
||||
结合 PostgreSQL 16 能力及甲方常见基础设施条件，建议按以下四种形态进行资源申请与部署评估。
|
||||
|
||||
### 形态一：单中心主备容灾
|
||||
|
||||
适用于预算有限、优先满足基础高可用能力的场景。
|
||||
|
||||
部署关系图：
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
APP[应用集群] --> PG1[(主库 Primary)]
|
||||
PG1 -->|流复制| PG2[(备库 Standby)]
|
||||
PG1 --> BK[备份归档存储]
|
||||
PG2 --> BK
|
||||
```
|
||||
|
||||
1. 主库与备库部署在同一机房或同一可用区。
|
||||
2. 备库可采用 `Warm Standby` 或 `Hot Standby`。
|
||||
3. 推荐采用异步复制；如网络稳定且事务一致性要求较高，也可采用同步复制。
|
||||
4. 该形态可解决单机故障问题，但不能覆盖机房级灾难。
|
||||
|
||||
### 形态二：同城双可用区主备容灾
|
||||
|
||||
适用于生产系统正式上线场景，兼顾高可用与较高的数据安全要求。
|
||||
|
||||
部署关系图：
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
subgraph AZ1[生产可用区 A]
|
||||
APP1[应用节点]
|
||||
PG1[(主库 Primary)]
|
||||
end
|
||||
subgraph AZ2[同城可用区 B]
|
||||
PG2[(同步备库 Standby)]
|
||||
end
|
||||
APP1 --> PG1
|
||||
PG1 -->|同步复制| PG2
|
||||
PG1 --> BK[备份归档存储]
|
||||
PG2 --> BK
|
||||
```
|
||||
|
||||
说明：
|
||||
|
||||
1. 主库与备库部署在同城不同机房或不同可用区。
|
||||
2. 推荐备库采用 `Hot Standby`，可承担只读查询与切换接管职责。
|
||||
3. 对收费、账务、实收确认等核心业务，宜优先评估同步复制。
|
||||
4. 该形态可覆盖单节点故障和单可用区故障，是生产环境优先推荐的基础方案。
|
||||
|
||||
### 形态三：同城双中心 + 异地灾备
|
||||
|
||||
适用于对连续运行能力要求较高，且需要同时覆盖机房级与区域级风险的场景。
|
||||
|
||||
部署关系图：
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
subgraph IDC1[生产中心]
|
||||
PG1[(主库 Primary)]
|
||||
end
|
||||
subgraph IDC2[同城灾备中心]
|
||||
PG2[(同步备库 Standby)]
|
||||
end
|
||||
subgraph IDC3[异地灾备中心]
|
||||
PG3[(异步灾备库 DR)]
|
||||
end
|
||||
PG1 -->|同步复制| PG2
|
||||
PG1 -->|异步复制| PG3
|
||||
PG1 --> BK[备份归档存储]
|
||||
PG2 --> BK
|
||||
PG3 --> BK
|
||||
```
|
||||
|
||||
说明：
|
||||
|
||||
1. 同城备库承担高可用切换职责。
|
||||
2. 异地灾备库承担区域级灾难恢复职责。
|
||||
3. 异地灾备一般采用异步复制，避免远距离链路对主业务写入性能造成明显影响。
|
||||
4. 该形态可满足高可用与灾备双重要求，适合作为甲方正式建设目标方案。
|
||||
|
||||
### 形态四：主备高可用 + 备份恢复型灾备
|
||||
|
||||
适用于暂不具备异地第三节点条件，但需要形成完整灾难恢复能力的场景。
|
||||
|
||||
部署关系图：
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
APP[应用集群] --> PG1[(主库 Primary)]
|
||||
PG1 -->|同步/异步复制| PG2[(同城备库 Standby)]
|
||||
PG1 -->|基础备份 + WAL 归档| OBJ[异地对象存储/异地备份库]
|
||||
PG2 -->|基础备份 + WAL 归档| OBJ
|
||||
```
|
||||
|
||||
说明：
|
||||
|
||||
1. 在线层保持主备双节点高可用。
|
||||
2. 异地侧不部署实时在线数据库实例，主要承载基础备份和 WAL 归档。
|
||||
3. 该形态投入低于三节点实时灾备，但恢复时间长于在线异地灾备库方案。
|
||||
4. 适用于二期或预算受限情况下的过渡方案。
|
||||
|
||||
## 资源配比原则
|
||||
|
||||
### 主备资源总体原则
|
||||
|
||||
1. 主库负责生产写入，CPU、内存、I/O、网络压力最大。
|
||||
2. 备库必须保存完整数据副本，因此备库存储容量原则上不得低于主库。
|
||||
3. 如备库承担实时切换接管职责，其 CPU 与内存不宜明显低于主库。
|
||||
4. 如备库仅承担异步灾备且不承载查询压力，可适当降低 CPU 与内存，但不应压缩存储容量和网络链路质量。
|
||||
|
||||
### 主备资源比例建议
|
||||
|
||||
| 备库角色 | 复制方式 | 是否承担读请求 | CPU 建议 | 内存建议 | 存储建议 | 适用说明 |
|
||||
|---|---|---|---|---|---|---|
|
||||
| 同步热备库 | 同步复制 | 是 | 不低于主库 100% | 不低于主库 100% | 不低于主库 100%，建议 120% | 生产正式切换节点，要求切换后立即承载全部业务 |
|
||||
| 同步温备库 | 同步复制 | 否 | 主库的 70% 至 100% | 主库的 70% 至 100% | 不低于主库 100%，建议 120% | 不承载查询，但需要较快接管生产流量 |
|
||||
| 异步热备库 | 异步复制 | 是 | 主库的 70% 至 100% | 主库的 70% 至 100% | 不低于主库 100%，建议 120% | 可承担报表查询或只读分析 |
|
||||
| 异步温备库 | 异步复制 | 否 | 主库的 50% 至 70% | 主库的 50% 至 70% | 不低于主库 100%，建议 120% | 仅承担容灾接管，不参与日常查询 |
|
||||
| 异地灾备库 | 异步复制 | 否 | 主库的 50% 左右 | 主库的 50% 至 70% | 不低于主库 100%，建议 120% | 主要用于区域级容灾恢复 |
|
||||
| 备份恢复节点 | PITR | 否 | 可不单独配置在线节点 | 可不单独配置在线节点 | 备份空间建议为主库有效数据量的 2 至 3 倍 | 用于误操作恢复和灾难后重建 |
|
||||
|
||||
### 资源配比说明
|
||||
|
||||
1. 备库存储不能按 CPU、内存比例缩减，原因是 PostgreSQL 备库需要保存完整数据文件、索引文件及 WAL 回放空间。
|
||||
2. 当备库承担 `Hot Standby` 查询或要求快速晋升为主库时，推荐按主库同规格申请。
|
||||
3. 当备库仅作为冷备或异步灾备节点时，可降低计算资源，但仍需预留恢复、回放和切换后的运行余量。
|
||||
|
||||
## 推荐部署方案
|
||||
|
||||
结合福建水务营收系统收费、账务、对账等核心业务连续性要求，建议分为三档申请方案。
|
||||
|
||||
### 方案 A：基础上线方案
|
||||
|
||||
1. 架构形态：单中心主备容灾。
|
||||
2. 节点组成：1 主库 + 1 备库 + 1 套备份归档存储。
|
||||
3. 复制方式：异步复制。
|
||||
4. 适用场景：预算受限、优先满足基本高可用要求。
|
||||
|
||||
### 方案 B：正式生产推荐方案
|
||||
|
||||
1. 架构形态：同城双可用区主备容灾。
|
||||
2. 节点组成：1 主库 + 1 同城热备库 + 1 套备份归档存储。
|
||||
3. 复制方式：核心业务优先评估同步复制。
|
||||
4. 适用场景：正式生产环境，要求故障切换后快速恢复业务。
|
||||
|
||||
### 方案 C：正式生产增强方案
|
||||
|
||||
1. 架构形态：同城双中心 + 异地灾备。
|
||||
2. 节点组成：1 主库 + 1 同城同步热备库 + 1 异地异步灾备库 + 1 套集中备份归档存储。
|
||||
3. 复制方式：同城同步复制，异地异步复制。
|
||||
4. 适用场景：甲方对连续运行、审计留痕、灾难恢复要求较高的正式建设项目。
|
||||
|
||||
本项目建议优先向甲方申请方案 B；如甲方同时要求区域级灾难恢复能力，建议直接申请方案 C。
|
||||
|
||||
## 甲方审批汇总表
|
||||
|
||||
以下汇总表用于甲方进行资源审批、预算评估和实施范围确认。建议优先按“方案 B：正式生产推荐方案”审批；如甲方同时要求区域级灾难恢复能力，可按“方案 C：正式生产增强方案”审批。
|
||||
|
||||
### 方案 A：基础上线方案审批汇总表
|
||||
|
||||
| 类别 | 资源项 | 数量 | 单项建议规格 | 审批说明 |
|
||||
|---|---|---:|---|---|
|
||||
| 服务器 | 主库服务器 | 1 台 | 16 核 CPU / 64 GB 内存 / 2 TB NVMe SSD | 承担全部生产写入 |
|
||||
| 服务器 | 备库服务器 | 1 台 | 12 至 16 核 CPU / 48 至 64 GB 内存 / 2 TB NVMe SSD | 承担主库故障接管 |
|
||||
| 服务器 | 管理与监控节点 | 1 台 | 8 核 CPU / 16 GB 内存 / 500 GB SSD | 部署监控、备份调度、巡检工具 |
|
||||
| 存储 | 备份归档存储 | 1 套 | 可用空间 4 TB 起 | 存放全量备份与 WAL 归档 |
|
||||
| 网络 | 主备复制链路 | 1 组 | 不低于 10 Gbps | 建议与业务访问链路隔离 |
|
||||
| 网络 | 业务接入地址 | 1 组 | 统一数据库代理地址 | 应用统一接入，不直连数据库 IP |
|
||||
| 软件 | PostgreSQL 16 | 2 套实例 | 主库 1 套，备库 1 套 | 构建基础主备容灾 |
|
||||
| 软件 | PgBouncer | 1 套 | 连接池代理 | 统一控制连接数 |
|
||||
| 软件 | HAProxy | 1 套 | 数据库入口代理 | 提供统一切换入口 |
|
||||
| 软件 | Patroni | 1 套 | 高可用管理组件 | 管理主备选举与切换 |
|
||||
|
||||
### 方案 B：正式生产推荐方案审批汇总表
|
||||
|
||||
| 类别 | 资源项 | 数量 | 单项建议规格 | 审批说明 |
|
||||
|---|---|---:|---|---|
|
||||
| 服务器 | 主库服务器 | 1 台 | 16 核 CPU / 64 GB 内存 / 2 TB NVMe SSD | 部署在生产可用区 |
|
||||
| 服务器 | 同城热备服务器 | 1 台 | 16 核 CPU / 64 GB 内存 / 2 TB NVMe SSD | 与主库同规格，承担正式接管 |
|
||||
| 服务器 | 管理与监控节点 | 1 台 | 8 核 CPU / 16 GB 内存 / 500 GB SSD | 部署监控、备份、巡检、告警 |
|
||||
| 存储 | 备份归档存储 | 1 套 | 可用空间 4 TB 至 6 TB | 存放备份、WAL、恢复校验副本 |
|
||||
| 网络 | 主备复制链路 | 1 组 | 不低于 10 Gbps | 同城低时延链路，适合同步复制 |
|
||||
| 网络 | 主备时延要求 | 1 项 | 建议低于 2 ms | 支撑主备同步与快速切换 |
|
||||
| 网络 | 业务接入地址 | 1 组 | 统一数据库代理地址 | 应用系统通过代理地址访问 |
|
||||
| 软件 | PostgreSQL 16 | 2 套实例 | 主库 1 套，热备库 1 套 | 构建正式生产主备体系 |
|
||||
| 软件 | PgBouncer | 1 套 | 连接池代理 | 控制连接数并稳定应用连接 |
|
||||
| 软件 | HAProxy | 1 套 | 数据库入口代理 | 承担统一读写入口切换 |
|
||||
| 软件 | Patroni | 1 套 | 高可用管理组件 | 管理主备状态、提升与故障切换 |
|
||||
|
||||
### 方案 C：正式生产增强方案审批汇总表
|
||||
|
||||
| 类别 | 资源项 | 数量 | 单项建议规格 | 审批说明 |
|
||||
|---|---|---:|---|---|
|
||||
| 服务器 | 主库服务器 | 1 台 | 16 核 CPU / 64 GB 内存 / 2 TB NVMe SSD | 部署在生产中心 |
|
||||
| 服务器 | 同城同步热备服务器 | 1 台 | 16 核 CPU / 64 GB 内存 / 2 TB NVMe SSD | 承担正式主备切换 |
|
||||
| 服务器 | 异地灾备服务器 | 1 台 | 8 至 12 核 CPU / 32 至 48 GB 内存 / 2 TB NVMe SSD | 承担区域级灾难恢复 |
|
||||
| 服务器 | 管理与监控节点 | 1 台 | 8 核 CPU / 16 GB 内存 / 500 GB SSD | 部署监控、备份、审计工具 |
|
||||
| 存储 | 集中备份归档存储 | 1 套 | 可用空间 6 TB 起 | 保存全量备份、WAL、演练副本 |
|
||||
| 网络 | 同城复制链路 | 1 组 | 不低于 10 Gbps | 保障同步复制稳定性 |
|
||||
| 网络 | 异地复制链路 | 1 组 | 专线或稳定 VPN | 保障异步复制与备份回传 |
|
||||
| 网络 | 业务接入地址 | 1 组 | 统一数据库代理地址 | 应用不直接访问数据库节点 |
|
||||
| 软件 | PostgreSQL 16 | 3 套实例 | 主库 1 套，同城热备 1 套，异地灾备 1 套 | 构建高可用与灾备双层体系 |
|
||||
| 软件 | PgBouncer | 1 套 | 连接池代理 | 稳定应用接入层 |
|
||||
| 软件 | HAProxy | 1 套 | 数据库入口代理 | 承担统一流量入口与切换 |
|
||||
| 软件 | Patroni | 1 套 | 高可用管理组件 | 管理主备状态与故障切换 |
|
||||
|
||||
### 审批建议结论
|
||||
|
||||
| 审批项 | 建议结论 | 说明 |
|
||||
|---|---|---|
|
||||
| 首选审批方案 | 方案 B | 兼顾资源投入、主备切换能力和正式生产可用性 |
|
||||
| 最低建设标准 | 不低于方案 A | 至少满足双节点主备与独立备份归档 |
|
||||
| 增强建设目标 | 方案 C | 适用于要求区域级灾难恢复的正式项目 |
|
||||
| 备库资源口径 | 存储不低于主库，热备计算资源宜等同主库 | 避免切换后承载不足 |
|
||||
| 接入方式 | 统一数据库代理地址 | 禁止应用直连数据库物理 IP |
|
||||
|
||||
## 详细资源申请清单
|
||||
|
||||
以下清单以单套生产系统为口径，作为资源申请参考基线。实际规模可根据并发量、数据量和保留周期进一步调整。
|
||||
|
||||
### 方案 A 资源申请清单
|
||||
|
||||
| 资源类型 | 数量 | 单节点建议配置 | 说明 |
|
||||
|---|---:|---|---|
|
||||
| 主库服务器 | 1 台 | 16 核 CPU / 64 GB 内存 / 2 TB NVMe SSD | 承担生产写入 |
|
||||
| 备库服务器 | 1 台 | 12 至 16 核 CPU / 48 至 64 GB 内存 / 2 TB NVMe SSD | 温备或热备均可 |
|
||||
| 备份存储 | 1 套 | 可用空间 4 TB 起 | 存放基础备份与 WAL 归档 |
|
||||
| 管理与监控节点 | 1 台 | 8 核 CPU / 16 GB 内存 / 500 GB SSD | 部署监控、备份调度、巡检工具 |
|
||||
|
||||
### 方案 B 资源申请清单
|
||||
|
||||
| 资源类型 | 数量 | 单节点建议配置 | 说明 |
|
||||
|---|---:|---|---|
|
||||
| 主库服务器 | 1 台 | 16 核 CPU / 64 GB 内存 / 2 TB NVMe SSD | 部署在生产可用区 |
|
||||
| 同城热备服务器 | 1 台 | 16 核 CPU / 64 GB 内存 / 2 TB NVMe SSD | 与主库同规格，承担热备与切换 |
|
||||
| 备份归档存储 | 1 套 | 可用空间 4 TB 至 6 TB | 存放基础备份、WAL、恢复校验副本 |
|
||||
| 管理与监控节点 | 1 台 | 8 核 CPU / 16 GB 内存 / 500 GB SSD | 部署监控、备份、连接代理等工具 |
|
||||
|
||||
### 方案 C 资源申请清单
|
||||
|
||||
| 资源类型 | 数量 | 单节点建议配置 | 说明 |
|
||||
|---|---:|---|---|
|
||||
| 主库服务器 | 1 台 | 16 核 CPU / 64 GB 内存 / 2 TB NVMe SSD | 部署在生产中心 |
|
||||
| 同城同步热备服务器 | 1 台 | 16 核 CPU / 64 GB 内存 / 2 TB NVMe SSD | 作为正式切换节点 |
|
||||
| 异地灾备服务器 | 1 台 | 8 至 12 核 CPU / 32 至 48 GB 内存 / 2 TB NVMe SSD | 用于区域级灾备恢复 |
|
||||
| 集中备份归档存储 | 1 套 | 可用空间 6 TB 起 | 统一保存全量备份与 WAL 归档 |
|
||||
| 管理与监控节点 | 1 台 | 8 核 CPU / 16 GB 内存 / 500 GB SSD | 部署监控、备份、审计工具 |
|
||||
|
||||
### 资源申请补充说明
|
||||
|
||||
1. 如甲方要求备库长期承担报表、统计或只读查询负载，备库应按主库同规格申请。
|
||||
2. 如数据库数据量预估超过 1 TB，建议主库与备库磁盘统一提升至 4 TB 起步。
|
||||
3. 如需要保留 30 日以上 WAL 归档或多周期全量备份，备份存储应按“在线数据量的 2 至 3 倍”进行规划。
|
||||
|
||||
## 网络与存储要求
|
||||
|
||||
### 网络要求
|
||||
|
||||
| 项目 | 建议要求 | 说明 |
|
||||
|---|---|---|
|
||||
| 主备网络带宽 | 不低于 10 Gbps | 保障流复制稳定性与切换效率 |
|
||||
| 同城主备时延 | 建议低于 2 ms | 适合同步复制 |
|
||||
| 异地主备链路 | 建议专线或稳定 VPN | 适合异步复制与备份回传 |
|
||||
| 复制链路隔离 | 建议与业务访问链路分离 | 降低复制抖动风险 |
|
||||
|
||||
### 存储要求
|
||||
|
||||
| 项目 | 建议要求 | 说明 |
|
||||
|---|---|---|
|
||||
| 主库存储 | NVMe SSD 或企业级 SSD | 保障 WAL 与随机 I/O 性能 |
|
||||
| 备库存储 | 不低于主库存储规格 | 保障回放与切换性能 |
|
||||
| 磁盘阵列 | RAID 10 优先 | 平衡可靠性与性能 |
|
||||
| 备份存储 | 独立于数据库数据盘 | 避免单点故障导致备份不可用 |
|
||||
|
||||
## 数据库代理与连接接入方案
|
||||
|
||||
### 建设目标
|
||||
|
||||
为避免应用系统直接连接数据库物理节点，并降低主备切换时应用侧配置变更成本，PostgreSQL 16 容灾体系宜配套建设数据库代理与连接接入层。
|
||||
|
||||
数据库代理层建设目标如下：
|
||||
|
||||
1. 为应用系统提供统一数据库访问地址。
|
||||
2. 在主备切换时避免逐台修改应用节点连接配置。
|
||||
3. 控制应用连接数，降低数据库连接管理压力。
|
||||
4. 为后续读写分离和只读查询扩展预留接入能力。
|
||||
|
||||
### 推荐组件组合
|
||||
|
||||
结合当前项目应用规模与运维复杂度控制要求，推荐采用以下组件组合：
|
||||
|
||||
1. `Patroni`：负责 PostgreSQL 主备状态管理、主库选举与故障切换。
|
||||
2. `HAProxy`：负责数据库访问入口转发，将写请求路由到当前主库。
|
||||
3. `PgBouncer`：负责连接池管理，降低应用对 PostgreSQL 后端连接数的直接冲击。
|
||||
|
||||
本项目不建议以 `pgpool-II` 作为首选统一方案。原因在于 `pgpool-II` 功能较重、配置复杂、运维成本较高，不利于当前项目在甲方环境中的快速落地与稳定运维。
|
||||
|
||||
### 推荐接入拓扑
|
||||
|
||||
#### 模式一：统一读写入口
|
||||
|
||||
适用于一期先满足高可用与连接池要求，暂不启用读写分离的场景。
|
||||
|
||||
接入关系图：
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
APP[应用集群] --> PGB[PgBouncer]
|
||||
PGB --> HAP[HAProxy RW 入口]
|
||||
HAP --> PG1[(当前主库 Primary)]
|
||||
PAT[Patroni] -.主备状态.-> HAP
|
||||
```
|
||||
|
||||
说明：
|
||||
|
||||
1. 应用系统统一连接 `PgBouncer` 暴露的数据库接入地址。
|
||||
2. `PgBouncer` 后端连接到 `HAProxy` 的读写入口。
|
||||
3. `HAProxy` 根据 `Patroni` 暴露的主备状态，将流量转发到当前主库。
|
||||
4. 主备切换时，应用端数据库 URL 不变。
|
||||
|
||||
#### 模式二：读写分离入口
|
||||
|
||||
适用于二期或存在报表、统计、查询分流需求的场景。
|
||||
|
||||
接入关系图：
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
APP[应用集群] --> PGBRW[PgBouncer RW]
|
||||
APP --> PGBRO[PgBouncer RO]
|
||||
PGBRW --> HAPRW[HAProxy RW]
|
||||
PGBRO --> HAPRO[HAProxy RO]
|
||||
HAPRW --> PG1[(当前主库 Primary)]
|
||||
HAPRO --> PG2[(热备库 Standby)]
|
||||
PAT[Patroni] -.主备状态.-> HAPRW
|
||||
PAT -.主备状态.-> HAPRO
|
||||
```
|
||||
|
||||
说明：
|
||||
|
||||
1. 写请求通过 `RW` 入口访问当前主库。
|
||||
2. 只读查询通过 `RO` 入口访问热备库。
|
||||
3. 如备库不可用，`RO` 入口可根据策略降级转发到主库或暂时关闭。
|
||||
4. 应用需在代码或配置层明确区分读写连接场景。
|
||||
|
||||
### 推荐选型结论
|
||||
|
||||
对于福建水务营收系统当前阶段，建议优先采用“`Patroni + HAProxy + PgBouncer`”组合，并采用“统一读写入口”模式上线。待系统稳定运行后，再根据报表与统计查询压力评估是否扩展为“读写分离入口”模式。
|
||||
|
||||
### HAProxy 示例配置
|
||||
|
||||
以下配置仅用于说明读写入口代理思路，实际参数应由项目环境统一配置并纳入变更管理。
|
||||
|
||||
```haproxy
|
||||
global
|
||||
log 127.0.0.1 local0
|
||||
maxconn 20000
|
||||
|
||||
defaults
|
||||
log global
|
||||
mode tcp
|
||||
timeout connect 5s
|
||||
timeout client 1m
|
||||
timeout server 1m
|
||||
|
||||
frontend pg_rw
|
||||
bind *:5000
|
||||
default_backend pg_primary
|
||||
|
||||
backend pg_primary
|
||||
option tcp-check
|
||||
default-server inter 3s fall 3 rise 2 on-marked-down shutdown-sessions
|
||||
server pg01 10.0.0.11:5432 check
|
||||
server pg02 10.0.0.12:5432 check backup
|
||||
```
|
||||
|
||||
配置说明：
|
||||
|
||||
1. 应用不直接连接 PostgreSQL 5432，而是连接 `HAProxy` 暴露的 5000 端口。
|
||||
2. `pg01` 为当前主库，`pg02` 为备库。
|
||||
3. 主库不可用时，代理层将连接切换至备用节点。
|
||||
4. 正式环境建议结合 `Patroni` REST 状态接口配置更准确的主备健康检查，而非仅做普通 TCP 存活检查。
|
||||
|
||||
### PgBouncer 示例配置
|
||||
|
||||
以下配置仅用于说明连接池配置思路，实际参数应由项目环境统一配置并纳入变更管理。
|
||||
|
||||
```ini
|
||||
[databases]
|
||||
waterdb = host=10.0.0.20 port=5000 dbname=waterdb
|
||||
|
||||
[pgbouncer]
|
||||
listen_addr = 0.0.0.0
|
||||
listen_port = 6432
|
||||
auth_type = md5
|
||||
auth_file = /etc/pgbouncer/userlist.txt
|
||||
pool_mode = transaction
|
||||
max_client_conn = 5000
|
||||
default_pool_size = 100
|
||||
reserve_pool_size = 20
|
||||
server_reset_query = DISCARD ALL
|
||||
ignore_startup_parameters = extra_float_digits
|
||||
```
|
||||
|
||||
配置说明：
|
||||
|
||||
1. 应用系统统一连接 `PgBouncer` 的 6432 端口。
|
||||
2. `PgBouncer` 后端目标不是数据库主机，而是 `HAProxy` 的读写入口地址。
|
||||
3. 推荐优先采用 `transaction` 池化模式，以提升连接复用效率。
|
||||
4. 如存在依赖会话级状态的特殊业务，应专项评估是否改用 `session` 模式。
|
||||
|
||||
### 应用接入建议
|
||||
|
||||
对于当前项目的 4 台应用服务器集群，不建议在每台应用服务器上分别配置数据库主机地址切换逻辑。推荐做法如下：
|
||||
|
||||
1. 应用配置文件统一写入数据库代理地址，不写数据库物理主机 IP。
|
||||
2. 生产环境统一维护一个数据库接入地址，例如 `db-rw.xxx.local:6432`。
|
||||
3. 所有应用节点使用同一连接地址接入，由代理层完成后端数据库节点切换。
|
||||
4. 如后续启用读写分离，再增加只读接入地址，例如 `db-ro.xxx.local:6432`。
|
||||
|
||||
### 切换时的接入逻辑
|
||||
|
||||
当主库发生故障或进行计划切换时，推荐接入逻辑如下：
|
||||
|
||||
1. `Patroni` 判定新的主库节点。
|
||||
2. `HAProxy` 将读写入口转发目标切换至新主库。
|
||||
3. `PgBouncer` 清理失效后端连接并重建到新主库的连接。
|
||||
4. 应用系统通过连接池重试机制继续访问统一代理地址。
|
||||
|
||||
在该机制下，应用系统通常无需修改数据库配置，仅在切换瞬间可能出现极短暂连接重试或少量请求失败，恢复后可继续正常提供服务。
|
||||
|
||||
### 正式文档建议表述
|
||||
|
||||
为保障福建水务营收系统数据库主备切换时应用系统的连续接入能力，数据库访问层宜采用“Patroni 负责主备选举、HAProxy 负责访问转发、PgBouncer 负责连接池管理”的组合架构。应用系统统一通过数据库代理地址访问数据库，不直接连接数据库物理节点；当主库故障或发生计划切换时，由代理层自动将访问流量切换至新的主库节点，从而实现应用侧最小感知切换。
|
||||
|
||||
## 部署实施说明
|
||||
|
||||
### 部署原则
|
||||
|
||||
1. 主库与同城备库不得部署在同一物理主机。
|
||||
2. 同城备库宜部署在独立机柜、独立电源域或独立可用区。
|
||||
3. 异地灾备节点宜部署在独立数据中心，避免与生产中心共用故障域。
|
||||
4. 备份归档存储应与数据库节点分离部署。
|
||||
|
||||
### 组件部署说明
|
||||
|
||||
1. 主库节点：部署 PostgreSQL 16 主实例，承担生产写入。
|
||||
2. 备库节点：部署 PostgreSQL 16 备用实例，通过流复制接收主库 WAL。
|
||||
3. 备份节点或备份存储：保存基础备份、WAL 归档和恢复校验文件。
|
||||
4. 管理与监控节点：部署 PostgreSQL 监控、备份调度、告警和巡检组件。
|
||||
|
||||
### 软件部署建议
|
||||
|
||||
1. 操作系统宜采用稳定版 Linux 发行版。
|
||||
2. 数据目录、WAL 目录、备份目录建议分盘或分卷部署。
|
||||
3. 主备切换宜配套连接路由、VIP 或代理层能力，避免应用侧频繁修改连接地址。
|
||||
4. 生产环境应启用备份校验、归档校验和恢复演练机制。
|
||||
|
||||
## 切换与恢复说明
|
||||
|
||||
### 故障切换
|
||||
|
||||
1. 主库故障时，由同城备库提升为新主库。
|
||||
2. 应用连接通过统一连接地址或代理切换到新主库。
|
||||
3. 原主库恢复后，应重新以备库身份加入复制体系。
|
||||
|
||||
### 数据恢复
|
||||
|
||||
1. 误删除、误更新或逻辑损坏场景，通过基础备份与 WAL 归档执行 `PITR` 时间点恢复。
|
||||
2. 区域级灾难场景下，可优先启用异地灾备库；如未建设异地在线库，则从异地备份存储重建数据库。
|
||||
|
||||
### 运维要求
|
||||
|
||||
1. 每季度至少开展 1 次主备切换演练。
|
||||
2. 每季度至少开展 1 次 `PITR` 恢复演练。
|
||||
3. 每日检查复制延迟、归档状态、备份成功率和磁盘余量。
|
||||
|
||||
## 切换实施细则
|
||||
|
||||
### 总体原则
|
||||
|
||||
福建水务营收系统数据库切换应遵循“统一入口切换、先判定后切换、先验证后恢复流量、禁止双主”的实施原则。
|
||||
|
||||
1. 应用系统统一通过数据库代理地址访问数据库，不直接连接数据库物理节点。
|
||||
2. 切换分为计划切换、故障切换和回切三类场景。
|
||||
3. 任一切换过程中，必须避免原主库与新主库同时对外提供写服务。
|
||||
4. 切换完成后，必须执行收费、开账、账务、发票、银行代扣等关键业务链路验证。
|
||||
|
||||
### 计划切换流程
|
||||
|
||||
计划切换适用于数据库补丁升级、主机维护、操作系统维护、机房迁移演练等场景。
|
||||
|
||||
执行顺序：
|
||||
|
||||
发起计划切换申请 → 确认切换窗口与影响范围 → 检查主备复制状态 → 暂停高风险写入操作 → 确认备库追平主库 → 提升备库为新主库 → 切换代理入口到新主库 → 验证关键业务链路 → 恢复应用写入流量 → 原主库修复并重建为备库。
|
||||
|
||||
实施要点如下：
|
||||
|
||||
1. 切换前至少确认主备复制无明显延迟。
|
||||
2. 切换窗口内应暂停批量开账、批量代扣、批量票据处理等高风险写入任务。
|
||||
3. 备库提升后，应优先切换代理层入口，不建议逐台修改应用配置。
|
||||
4. 切换成功后，原主库应以备库身份重新加入复制体系，不得直接恢复为独立写节点。
|
||||
|
||||
### 故障切换流程
|
||||
|
||||
故障切换适用于主库主机宕机、数据库实例不可用、主库存储异常、主库不可恢复等场景。
|
||||
|
||||
执行顺序：
|
||||
|
||||
监控发现主库异常 → 确认主库不可服务 → 隔离原主库写入能力 → 确认备库状态可提升 → 提升备库为新主库 → 代理入口切换到新主库 → 应用重连并恢复服务 → 验证关键业务 → 故障主机修复 → 重建为新备库。
|
||||
|
||||
实施要点如下：
|
||||
|
||||
1. 故障切换的前提不是“主库变慢”，而是“主库已无法稳定提供写服务”。
|
||||
2. 在故障未完全确认前，不得贸然提升多个备库。
|
||||
3. 如主库网络隔离但实例未真正关闭，应先执行隔离措施，避免形成双主风险。
|
||||
4. 故障切换后应优先恢复核心业务可用性，再执行历史备库链路重建。
|
||||
|
||||
### 回切流程
|
||||
|
||||
回切是指原主库修复完成后，在合适窗口下恢复为生产主库或重新调整主备角色。
|
||||
|
||||
执行顺序：
|
||||
|
||||
原主库修复完成 → 作为备库追平现主库 → 评估是否需要回切。
|
||||
|
||||
如不需要回切，则保持现状运行。
|
||||
|
||||
如需要回切，则执行以下步骤：发起计划回切窗口 → 暂停高风险写入 → 确认复制追平 → 切换代理入口 → 恢复原主库为主库 → 验证关键业务 → 现主库调整为备库。
|
||||
|
||||
实施要点如下：
|
||||
|
||||
1. 故障切换后并不要求立即回切，应以稳定运行为优先。
|
||||
2. 仅当原主机重新具备稳定承载能力，且运维窗口允许时，才建议执行回切。
|
||||
3. 回切本质上属于一次计划切换，应按计划切换流程执行。
|
||||
|
||||
### 切换前检查表
|
||||
|
||||
| 检查项 | 检查要求 | 说明 |
|
||||
|---|---|---|
|
||||
| 主备复制状态 | 无严重延迟或异常中断 | 确认备库具备接管条件 |
|
||||
| WAL 归档状态 | 最近归档成功 | 避免切换与恢复证据缺口 |
|
||||
| 备库只读可用性 | 可正常连接与查询 | 确认备库实例健康 |
|
||||
| 代理状态 | `HAProxy`、`PgBouncer` 正常 | 确保切换入口可用 |
|
||||
| 应用连接配置 | 使用统一代理地址 | 禁止应用直连数据库 IP |
|
||||
| 定时任务状态 | 高风险写任务可暂停 | 包括批量收费、批量代扣等 |
|
||||
| 业务通知 | 已通知相关业务与运维人员 | 降低切换窗口影响 |
|
||||
|
||||
### 切换后验证表
|
||||
|
||||
| 验证项 | 验证要求 | 适用说明 |
|
||||
|---|---|---|
|
||||
| 数据库连接 | 应用可正常连接新主库 | 基础可用性验证 |
|
||||
| 登录与鉴权 | 后台登录、令牌校验正常 | 确认统一平台链路正常 |
|
||||
| 收费业务 | 单笔收费、销账可执行 | 核心写业务验证 |
|
||||
| 开账业务 | 账单查询、开账写入正常 | 核心账务链路验证 |
|
||||
| 发票业务 | 发票申请、查询可用 | 核心票据链路验证 |
|
||||
| 银行代扣 | 查询和批次处理链路正常 | 涉及外联时至少完成内部链路检查 |
|
||||
| 日志与监控 | 新主库监控、慢日志、告警恢复正常 | 运维可观测性验证 |
|
||||
| 备份与归档 | 新主库 WAL 归档恢复正常 | 确认恢复能力未中断 |
|
||||
|
||||
### 当前项目建议切换策略
|
||||
|
||||
结合当前项目部署口径，建议采用以下策略：
|
||||
|
||||
1. 数据库切换统一由数据库代理层完成，不在 4 台应用服务器上分别切换配置。
|
||||
2. 一期建议采用统一读写入口模式，减少应用改造复杂度。
|
||||
3. 切换窗口内应重点管控收费、账务、发票、银行代扣等核心写入场景。
|
||||
4. 生产切换完成后，应同步检查 `Quartz` 定时任务、银行文件处理任务及发票异步任务是否恢复正常。
|
||||
|
||||
### 正式文档建议表述
|
||||
|
||||
福建水务营收系统数据库切换采用“主备切换 + 代理入口切换”的实施模式。计划切换和故障切换均由数据库高可用组件完成主备角色调整，由数据库代理层完成统一接入地址切换，应用系统不直接感知数据库物理节点变化。切换实施前应完成复制状态、归档状态、代理状态和高风险任务状态检查，切换实施后应完成收费、开账、账务、发票、银行代扣等关键业务链路验证，并将原主库按备库角色重新纳入复制体系。
|
||||
|
||||
## 申请结论
|
||||
|
||||
为满足福建水务营收系统生产环境对数据库连续运行和灾难恢复的要求，建议甲方按以下原则审批 PostgreSQL 16 容灾资源：
|
||||
|
||||
1. 至少配置 1 台主库服务器、1 台备库服务器和 1 套独立备份归档存储。
|
||||
2. 如备库承担正式接管职责，CPU 与内存宜按主库 100% 配置，存储不得低于主库。
|
||||
3. 如需形成正式生产级容灾体系，建议采用“同城双可用区主备 + 备份归档”方案。
|
||||
4. 如需形成区域级灾难恢复体系，建议进一步增配 1 台异地灾备服务器。
|
||||
|
||||
综上，PostgreSQL 16 容灾资源申请可分阶段实施，但正式生产环境不宜低于“双节点主备 + 独立备份归档”的最低建设标准。
|
||||
@ -15,6 +15,7 @@
|
||||
|
||||
- `02_Table_Specs.md`：单表规格补充（历史映射，非主口径）
|
||||
- `06_Sensitive_Data_Encryption.md`：敏感数据加密方案
|
||||
- `07_PostgreSQL16_DR_Resource_Application.md`：PostgreSQL 16 容灾与资源申请专题说明
|
||||
|
||||
## 维护原则
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user