PostgreSQL 平台能否通过安全和运维评审，往往不只取决于数据库能不能启动，还取决于三个问题：静态数据是否加密、读流量能否从主库分担出去，以及故障发生后日志是否仍然可用。Percona Operator for PostgreSQL 3.1.0 正是围绕这三项能力推进：透明数据加密、逻辑副本和持久化日志都可以在自定义资源中表达。
这意味着它们不必再依赖一组分散的手工脚本或集群外配置。数据库平台团队可以把安全和运维要求放进声明式配置，并通过 Kubernetes 的审查、变更和回滚流程管理。
三项能力分别解决什么问题
1. 透明数据加密：降低静态数据暴露风险
透明数据加密的目标，是让数据库文件、表空间或底层存储中的数据在磁盘上保持加密，同时尽量不改变应用访问 PostgreSQL 的方式。应用仍然通过普通 SQL 读写，平台则负责处理静态数据保护相关配置。
这里要区分两个边界：
- 静态数据加密不等于传输加密。客户端到 PostgreSQL 的连接仍应使用 TLS。
- 加密不等于密钥管理。生产环境还需要明确密钥来源、轮换策略、备份恢复流程和访问权限。
因此，启用加密后，评审重点不会消失，而是会从“有没有加密”扩展到“谁能拿到密钥，以及恢复演练是否成功”。
2. 逻辑副本：把读能力从主库旁边拆出来
只依赖主库处理所有读请求，通常会让报表、搜索、数据导出等工作与在线事务争抢 CPU、内存和 I/O。逻辑副本提供了另一种拓扑：把符合需求的数据变化复制到独立实例，再将部分读取流量导向副本。
逻辑复制的价值不只是增加一个 PostgreSQL 实例，还包括更灵活的数据消费方式。例如，可以为分析型读取建立专用副本，减少长查询对主库事务延迟的影响。
但副本不是“免费的只读主库”。设计时必须关注：
- 复制延迟是否满足业务的可接受范围；
- 副本是否包含应用真正需要的表和数据；
- DDL、序列、扩展和冲突处理是否符合使用场景；
- 应用是否能容忍读到略旧的数据。
如果业务要求强一致读，不能仅仅因为有逻辑副本就把所有查询切过去。
3. 持久化日志：让问题发生后仍有证据
容器标准输出适合实时查看，却不一定足以满足审计、合规和故障分析要求。Pod 被重建、节点被替换或日志采集器短暂异常时，短期日志可能丢失。
持久化日志把日志保存周期从“Pod 还活着多久”提升为“存储和保留策略允许多久”。这让团队能够围绕日志容量、保留时间、访问权限和归档方式建立明确的运维规则。
不过，持久化日志也会带来真实成本：磁盘会增长，敏感字段可能被写入日志，日志卷还可能与数据库存储争抢节点资源。上线前应同时配置轮转、容量告警和访问控制，而不是只创建一个更大的卷。
在自定义资源中落地配置
3.1.0 的重要变化，是把这三类能力放进 Operator 管理的自定义资源模型中。下面给出一个可改造的配置示例，用于展示平台配置应如何组织。由于具体字段和层级必须以已安装的 3.1.0 CRD 为准，应用前请先用 kubectl explain 校验字段名；不要直接把示例中的占位字段带入生产环境。
apiVersion: pgv2.percona.com/v1
kind: PerconaPGCluster
metadata:
name: finance-db
namespace: database
spec:
# 以下字段用于表达配置意图；请根据 3.1.0 CRD 校准实际字段名
dataEncryption:
enabled: true
keyManagement: external
logicalReplicas:
enabled: true
name: finance-read
logging:
persistent:
enabled: true
size: 20Gi
retention: 14d
instances:
- name: primary
replicas: 3
dataVolumeClaimSpec:
storageClassName: fast-ssd
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 200Gi
先检查 CRD 能否解释相关字段，再提交变更：
kubectl explain perconapgcluster.spec --recursive | less
kubectl get crd perconapgclusters.pgv2.percona.com -o yaml > perconapgcluster-crd.yaml
kubectl apply --dry-run=server -f finance-db.yaml
kubectl apply -f finance-db.yaml
kubectl -n database get perconapgcluster finance-db -o yaml
如果集群中 CRD 的实际字段名称不同，应以 CRD 和 3.1.0 文档为准重写 YAML。--dry-run=server 很适合放进 CI：它可以在真正修改集群前检查 API 服务器是否接受这份资源。
一次变更，三类验证
将这些能力声明在 CR 中，并不意味着只要 kubectl apply 成功就完成了上线。建议把验证拆成三条独立路径。
验证加密
检查 Operator 状态、数据库实例状态和密钥引用是否符合预期。还要进行一次恢复演练：在没有正确密钥或密钥权限不足时，确认系统会失败得清楚，而不是生成一个看似成功但无法读取的数据集。
验证逻辑副本
制造一条可识别的测试数据，确认它能按预期出现在副本中，并记录复制延迟。然后运行一条较重的读取查询，观察主库 CPU、I/O、事务延迟和副本延迟是否发生变化。
验证持久化日志
删除或重建一个测试 Pod，确认日志仍能从持久化位置或统一采集系统中查询。与此同时，检查日志卷使用率和轮转行为。没有容量告警的持久化日志，最终可能只是把“日志丢失”变成“磁盘写满”。
可以把基础检查写成一个简单的命令步骤：
set -euo pipefail
NS=database
CLUSTER=finance-db
kubectl -n "$NS" get perconapgcluster "$CLUSTER" -o wide
kubectl -n "$NS" get pods -l postgres-operator.crunchydata.com/cluster="$CLUSTER"
kubectl -n "$NS" get pvc
kubectl -n "$NS" get events --sort-by=.lastTimestamp | tail -n 30
标签键可能因 Operator 版本和资源实现而不同；如果第二条命令没有返回 Pod，应先查看资源 YAML 中的实际标签，再调整选择器。
上线前的工程清单
- 确认加密覆盖范围：数据库文件、备份、日志和临时文件是否分别处理；
- 明确密钥生命周期：创建、轮换、权限、备份和灾难恢复；
- 为逻辑副本定义延迟阈值，并决定哪些查询允许读取旧数据；
- 对副本的表范围、DDL 变化和扩展依赖做验证；
- 为持久化日志设置保留周期、轮转、容量告警和访问权限；
- 把
kubectl explain、服务端 dry-run 和状态检查加入 CI/CD； - 在测试环境完成主库故障、密钥不可用、Pod 重建和日志恢复演练。
Percona Operator for PostgreSQL 3.1.0 的价值，不只是增加了三个开关，而是把数据保护、读取扩展和故障证据纳入同一套声明式管理边界。真正采用时，建议从一个非关键集群开始，用可观测性和恢复演练验证效果，再逐步推广到生产数据库。