PostgreSQL 企业实操：三可用区、连续归档与时间点恢复

验证：未记录

适用版本: 未记录
验证范围: 尚未登记验证记录。

本篇选定 EKS（AWS 托管 Kubernetes）上的 CloudNativePG，三可用区、独立加密卷、Barman Cloud 插件归档到 S3。数据库 Pod 重建、主节点切换和误删恢复分别验收；不把 pg_dump 成功等同于灾备。

1. 前置与版本锁定#

三 AZ（可用区）各有可调度节点，EBS CSI（存储接口）支持加密卷、WaitForFirstConsumer，StorageClass 使用 Retain 回收策略；已安装 cert-manager，控制面可访问 webhook。备份桶版本化、私有、独立账号/权限管理，生命周期长于恢复窗口。

export CNPG_CHART=REPLACE_APPROVED_CHART_VERSION
helm show chart cloudnative-pg --repo https://cloudnative-pg.github.io/charts --version "$CNPG_CHART"
# 确认 appVersion 与集群 Kubernetes minor、Barman 插件兼容，保存 Chart 与摘要。
helm upgrade --install cnpg cloudnative-pg --repo https://cloudnative-pg.github.io/charts --version "$CNPG_CHART" -n cnpg-system --create-namespace --wait
curl --fail --location https://github.com/cloudnative-pg/plugin-barman-cloud/releases/download/v0.15.0/manifest.yaml -o barman-plugin.yaml
# 审核并保存文件后安装，插件与 operator 同 namespace。
kubectl apply -f barman-plugin.yaml
kubectl -n cnpg-system rollout status deployment/barman-cloud

插件要求 CloudNativePG ≥1.26；使用当前仍受支持且通过组织验证的 operator 补丁，不使用 main 分支清单。插件安装条件

2. 身份、存储与创建集群#

按 Add-on 云身份创建 IRSA（ServiceAccount 对应 IAM 角色）：信任精确限定 system:serviceaccount:data:orders-db，S3 只允许本桶 orders/orders-db/*，包含 ListBucket 的前缀条件、GetObject/PutObject，以及保留策略需要的受限 DeleteObject；SSE-KMS（KMS 服务端加密）另授权指定密钥。恢复角色只读，信任 data:orders-restore。平台禁止业务修改这些 SA/角色。

下载 cluster.yaml，替换备份桶、角色 ARN、受支持 PostgreSQL 17 镜像摘要和 StorageClass：

kubectl create namespace data --dry-run=client -o yaml | kubectl apply -f -
# 先下载并替换 network.yaml 中的私有端点 CIDR。
kubectl apply -f network.yaml
kubectl apply --dry-run=server -f cluster.yaml
kubectl apply -f cluster.yaml
kubectl -n data wait --for=condition=Ready cluster/orders-db --timeout=20m
kubectl -n data get pods -l cnpg.io/cluster=orders-db -o wide
kubectl -n data get backups

要求三 Pod 分布于三 AZ；同步复制要求至少一个同步备用，失去所需同步副本时阻塞写入是预期一致性策略。备用容量、节点数量和卷可用区必须匹配，不能仅改 replicas=3。

CNPG 创建内部 TLS（传输层安全）证书和 orders-db-app Secret。运行连接使用 orders-db-rw.data.svc、sslmode=verify-full、CNPG CA；复制和运维链路也必须验证。下载 network.yaml，填写 API Server、S3 与区域 STS 私有端点 CIDR 后在建库前 apply；策略限制业务/运维 5432、operator 管理端口、副本通信、DNS 和备份出口。NodeLocal DNS 另加其精确地址，恢复集使用独立策略，仅允许 operations 运维、恢复副本之间以及 operator/监控所需端口；业务 namespace 不能访问恢复库。NetworkPolicy 需 CNI 实际执行，并检查不存在其他扩大授权的策略；禁止公网 Service。

3. 写入可对账业务与备份#

安装与 operator 版本匹配的 kubectl-cnpg 插件。仅平台身份可执行以下本地数据库管理命令：

kubectl cnpg psql orders-db -n data -- -d orders -v ON_ERROR_STOP=1 <<'SQL'
CREATE TABLE restore_probe(id integer PRIMARY KEY, amount_cents bigint NOT NULL);
INSERT INTO restore_probe VALUES(1,1200),(2,2300);
SELECT count(*),sum(amount_cents) FROM restore_probe;
SQL

集成订单工程时，以独立迁移管理员先创建角色并执行迁移，再下发 API/worker 最小权限连接。不能拿 CNPG app owner 直接当超级用户。在平台 kubectl cnpg psql orders-db -n data -- -d orders 交互会话执行：

CREATE ROLE orders_migrator LOGIN CREATEROLE;
\password orders_migrator
GRANT orders_owner TO orders_migrator;
GRANT CONNECT ON DATABASE orders TO orders_migrator;
GRANT USAGE,CREATE ON SCHEMA public TO orders_migrator;

通过提示设置秘密密码，构造迁移 Secret 指向 orders_migrator，再运行配套 migration Job；它会创建业务表和四个运行角色。完成后平台执行 ALTER ROLE orders_migrator NOLOGIN NOCREATEROLE;，删除迁移 Secret；下次迁移经受控流程临时启用。触发器函数仍由该不可登录 owner 执行，API/worker 不能修改安全边界。

kubectl cnpg backup orders-db -n data --method=plugin --plugin-name=barman-cloud.cloudnative-pg.io
kubectl -n data get backups -w

必须等新 Backup phase=completed，并确认 WAL（预写日志）归档无错误，再记录 UTC 恢复时间。先在数据库执行 SELECT now(); SELECT pg_switch_wal();，等待对应 WAL 已归档，确保恢复目标可达。

4. 误删与独立 PITR#

仅隔离实验库执行删除一条 probe，再下载 restore.yaml。填入删除前、且已归档的 UTC 时间，沿用原镜像、存储类、只读恢复角色：

kubectl cnpg psql orders-db -n data -- -d orders -c 'DELETE FROM restore_probe WHERE id=1;'
kubectl apply --dry-run=server -f restore.yaml
kubectl apply -f restore.yaml
kubectl -n data wait --for=condition=Ready cluster/orders-restore --timeout=30m
kubectl cnpg psql orders-restore -n data -- -d orders -c 'SELECT count(*),sum(amount_cents) FROM restore_probe;'

从实际业务 Pod 连接恢复 Service 应超时，运维身份查询应成功，再核对没有复用业务连接 Secret。恢复库必须返回两行、3500；原库仍只有一行，证明没有覆盖原库。PITR（时间点恢复）目标前的基本备份和 WAL 必须连续，缺失时不得跳过检查强行宣称成功。恢复副本默认不向原前缀归档；要提升为业务库，先配置新备份前缀和写权限，禁止覆盖源备份。插件恢复配置

5. 故障切换、升级及退出#

业务持续产生幂等订单时，通过 kubectl cnpg promote orders-db REPLACE_HEALTHY_REPLICA -n data 演练受控切换；观察新主、连接恢复、账本一致性与同步备用恢复。更高风险的节点失联演练应确认旧主已隔离、不会脱离 operator 自行继续写入。

补丁升级先升级隔离恢复库 imageName、等待滚动完成并重做验收，再推广源库；跨 PostgreSQL major 使用明确支持的迁移/升级流程，不能直接换 imageName 标签。升级 operator、CRD、插件和数据库引擎分开变更；不兼容时恢复新集群而非盲降版本。

告警覆盖备份最后成功时间、WAL 归档错误、复制延迟、磁盘和连接数，并验证实际通知。结束先保留恢复证据，删除本次恢复 Cluster 前核对 PVC/PV 回收策略；不删除源备份桶、KMS key 或尚在恢复窗口内的 WAL。