CloudNativePG集成K8s：法定人数同步复制下的读一致性与负载均衡疑问

1. CNPG内置-ro/-r Service的安全性问题 #

CNPG默认创建的-ro（仅路由副本）、-r（路由主库+副本）Service，在法定人数同步复制模式下无法直接安全地做读请求负载均衡。这类Service仅基于Pod的角色（主/副本）做路由，不会判断副本是否参与了上一次写入的法定人数确认，也不会校验副本的数据同步状态。

2. 未参与quorum的副本是否会引发一致性问题 #

会。当主库完成写入并向客户端返回响应时，仅意味着有k个副本确认收到并持久化了该写入（quorum要求），其余未参与quorum的副本可能还未同步该数据。此时如果读请求被路由到这些副本，会读取到写入前的旧数据，直接违反「写请求返回后所有读请求必须看到最新数据」的读已提交一致性要求。

3. CNPG的规避机制 #

CNPG本身没有原生机制直接跟踪并过滤未参与quorum的副本，但可以通过以下方式间接规避：

• 自定义就绪探针：给副本Pod配置自定义readinessProbe，检查副本的WAL回放状态，比如执行SELECT pg_last_wal_receive_lsn() = pg_last_wal_replay_lsn()，确保副本已完成所有收到的WAL回放。未同步完成的副本会被标记为未就绪，自动从Service后端剔除。
• 基于标签的自定义Service：通过扩展CNPG Operator或使用sidecar容器，实时查询PostgreSQL的pg_stat_replication视图，给已同步到最新状态的副本Pod添加特定标签（如cnpg/synced: "true"），然后创建仅指向该标签的自定义Service，确保读请求只路由到同步完成的副本。

4. 是否需要连接池 #

需要。连接池（如PgBouncer）能更精准地控制读请求的路由策略，适配一致性需求：

• 对于要求强一致性的读请求，可直接路由到主库，或者仅路由到已确认参与quorum/同步完成的副本；
• 对于允许弱一致性的读请求，仍可通过-ro Service负载均衡到所有副本，实现资源利用最大化；
• 连接池可结合CNPG提供的主从状态信息（如通过Operator暴露的API或Pod标签），动态调整路由规则，无需手动维护Service后端列表。

内容的提问来源于stack exchange，提问作者lololozhkin