Pgpool-II作为PostgreSQL的中间件，提供了多种高可用与负载均衡方案，其中native replication模式让Pgpool-II自身承担数据复制职责。它不要求后端节点之间建立流复制关系，而是把每一个写操作分发到所有注册的节点上执行，读操作则可按配置分散到不同节点。
一、native replication模式的基本工作原理
在native replication模式下，Pgpool-II接收到客户端的SQL请求后会进行解析。如果是读操作（如SELECT），可以根据load balance配置把请求发给其中一个节点；如果是写操作（INSERT、UPDATE、DELETE、DDL等），Pgpool-II会将该语句同步发送给所有后端节点，并等待各个节点的执行结果。
这种机制意味着每个PostgreSQL节点都持有完整的数据副本，但节点之间互相不知道对方存在。数据一致性由Pgpool-II的转发逻辑保障，而不是数据库内核。因此，当新增节点时，需要先用基础备份等方式手动同步存量数据，之后才能加入集群由Pgpool-II统一调度。
1.1 写操作的转发流程
Pgpool-II内部通过连接池持有到各个节点的连接。收到写SQL后，它依次或并行通过对应连接发送指令。以并行发送为例，若配置了两个后端节点node0与node1，伪代码逻辑如下：
# 伪代码展示Pgpool-II写转发逻辑
def execute_write(sql):
results = []
errors = []
for conn in [conn_node0, conn_node1]:
try:
res = conn.execute(sql)
results.append(res)
except Exception as e:
errors.append(e)
if errors and config('failover_on_error'):
trigger_failover()
return results
实际C代码中，Pgpool-II会用子进程或线程管理各后端连接，并通过共享内存协调状态。可以看到，复制动作完全发生在中间件，后端无复制进程开销。
1.2 读操作的负载分配
读请求默认也会发往主节点，但开启load_balance_mode后，Pgpool-II会基于权重大小选择节点。由于各节点数据由写转发保证一致，读可分散以提升吞吐。不过若写刚完成而节点间网络延迟被放大，可能出现短暂读到旧值，需要配合同步级别参数权衡。
在事务内，Pgpool-II通常将读也固定到同一节点，避免事务看到不同节点导致的不一致视图。这一点对应用透明，但开发者应了解长事务可能占用某节点连接更久。
二、配置与部署要点
要使用native replication，需在pgpool.conf中设置backend_hostname、backend_port、backend_weight等，并将replication_mode设为true，load_balance_mode可按需开启。每个后端用编号区分，例如backend_hostname0、backend_hostname1。
下面是一个最小化的配置片段示例，展示两个节点的声明方式：
# pgpool.conf 片段 replication_mode = on load_balance_mode = on backend_hostname0 = '192.168.0.1' backend_port0 = 5432 backend_weight0 = 1 backend_hostname1 = '192.168.0.2' backend_port1 = 5432 backend_weight1 = 1
配置完成后启动Pgpool-II，通过pcp_node_info等工具可查看节点状态。若某节点宕机，依据failover_command配置，Pgpool-II可自动将其隔离，剩余节点继续服务写请求。
2.1 初始数据同步
native replication不会自动同步已有数据。常见做法是使用pg_basebackup从其中一个节点拷贝数据到新节点，再启动新节点并注册到Pgpool-II。若跳过此步，新节点会因缺少历史数据而引发查询差异。
对于后续表结构变更，由于DDL也会被转发，因此无需额外处理。但大事务批量写入时，所有节点都要完成才算成功，整体延迟受最慢节点影响。
三、与流复制模式的对比
PostgreSQL自带的流复制是数据库层同步，而native replication是中间件层同步。两者核心差异体现在一致性模型与运维复杂度上。
| 对比维度 | native replication | 流复制 |
|---|---|---|
| 复制发起方 | Pgpool-II | PostgreSQL主库 |
| 节点版本要求 | 可混合不同大版本 | 通常主从同版本 |
| 写性能 | 受最慢节点制约 | 异步时主库较快 |
| 读一致性 | 依赖转发完整性 | 备库可能延迟 |
从表中可知，native replication适合需要异构节点或不想配置WAL归档的场景，但在极端写压力下，其中间件转发会成为瓶颈。流复制则更贴近数据库原生能力，运维工具链成熟。
3.1 失败处理机制
当某个节点在写操作中返回错误，Pgpool-II的行为由配置决定。可设置让集群整体报错，或者将该节点标记为down并继续。若选择后者，恢复节点后需人工补数据或重新全量同步，否则会出现副本缺失。
因此在生产环境，建议配合监控脚本定时校验各节点行数或校验和，及时发现隐性不一致。Pgpool-II本身不提供自动修复副本差异的功能。
四、适用场景与注意事项
native replication适用于读多写少、节点数量不多、且希望快速搭建冗余环境的系统。例如内部报表平台，两个节点互为镜像，前端通过Pgpool-II统一接入。
需要注意，该模式所有写都放大到全节点，因此写膨胀明显。若业务有高频批量导入，应评估网络与磁盘开销。另外，由于每个节点都执行相同SQL，函数中使用非确定性表达式（如now()）可能导致各节点数据微差，应尽量使用参数化或事务级时间。
4.1 简单验证代码
应用侧可通过Pgpool-II端口执行一条写后再读，验证两个节点是否一致。示例如下：
-- 通过Pgpool-II连接执行
INSERT INTO t_log(msg) VALUES ('test native replication');
SELECT count(*) FROM t_log;
随后直接登录各后端节点查询同一表，若计数相同则说明转发正常。若不一致，检查pgpool日志中是否有节点报错或被隔离。
总体来看，Pgpool-II的native replication模式以中间件为中心解决了多节点镜像问题，降低了数据库层配置门槛，但把一致性责任上移到了运维与中间件。理清其转发路径与失败策略，才能在合适业务中用它构建稳定服务。
Pgpool-IInative_replicationpostgresql修改时间：2026-08-10 09:03:37