PostgreSQL 灾备核心详解：基于日志文件传输的物理复制（流复制）

PostgreSQL 灾备核心详解：基于日志文件传输的物理复制（流复制）

在 PostgreSQL 的众多高可用与灾备方案中，基于日志文件传输的物理复制（Physical Streaming Replication, PSR） 无疑是最为核心、应用最广泛的基石技术。它高效、稳定且原生集成，能够为大多数生产系统提供可靠的数据保护和服务连续性保障。

本文将深入解析流复制的工作原理、核心配置、同步模式以及最佳实践。

一、核心思想：字节级完美复制

流复制的根本目标是创建一个与主库（Primary）在物理层面上完全一致的备用库（Standby/Replica）。这意味着备库的磁盘数据块内容与主库几乎是逐字节匹配的。

其实现依赖 PostgreSQL 的核心机制：预写式日志（Write-Ahead Logging, WAL）。任何对数据库的修改都必须首先被记录到 WAL 日志中，然后再写入数据文件。流复制正是通过传输和重放这些 WAL 记录来实现数据同步的。

二、工作原理与流程

流复制的工作流程可以清晰地分为以下几步：

WAL 记录生成（主库）：

当用户提交一个事务（如
INSERT,
UPDATE）时，主库首先将变更以数据页的变化形式写入 WAL 日志缓冲区。WAL 缓冲区定期或根据策略（如事务提交时）被刷入磁盘，生成连续的 WAL 段文件（如
0000000100000001000000A5）。

WAL 记录传输（主库 -> 备库）：

主库上的 WAL Sender 进程 被启动。备库上的 WAL Receiver 进程 主动向主库的 WAL Sender 进程发起 TCP 连接。一旦连接建立，WAL Sender 不再仅仅等待一个完整的 WAL 段文件产生，而是实时地（Streaming） 将刚生成的 WAL 记录流式传输给备库的 WAL Receiver 进程。这是“流复制”名称的由来，也是其低延迟的关键。

WAL 记录持久化（备库）：

WAL Receiver 进程接收到数据后，将其传递给备库上的 Startup 进程。Startup 进程将这些 WAL 记录按照完全相同的顺序写入备库的磁盘上的 WAL 段文件中。这一步确保了备库拥有和主库完全一致的 WAL 日志。

WAL 记录重放（Recovery）（备库）：

最后，Startup 进程重放（Apply） 这些 WAL 记录，将修改应用到备库的数据文件中。至此，备库的数据状态得以与主库保持同步。

三、核心配置详解

要搭建流复制，需配置主库和备库的
postgresql.conf 和
pg_hba.conf 文件。

主库配置：


postgresql.conf:


wal_level = replica (或
logical)：确保生成足够信息的 WAL。
max_wal_senders = 5：设置最多可连接多少个 WAL Sender 进程，需大于备库数量。
max_replication_slots = 5：强烈推荐使用复制槽（Replication Slot），防止备库长时间断开连接后，主库删除其尚未接收的 WAL 日志，导致复制中断。
synchronous_commit：控制同步模式（见下文）。


pg_hba.conf:

添加一条记录，允许备库以复制权限连接主库。
host replication replica_user standby_ip/32 md5

备库配置：

使用
pg_basebackup 工具从主库获取一份基础备份，这是搭建备库的起点。创建
standby.signal 文件：告诉 PostgreSQL 实例这是一个备库。配置
postgresql.conf：

primary_conninfo：指定如何连接到主库，包含IP、端口、用户名、密码等。
primary_conninfo = 'host=primary_ip port=5432 user=replica_user password=your_password'
primary_slot_name = 'standby_slot_name'：推荐使用，与主库的复制槽对应。

四、同步模式：异步 vs. 同步

这是流复制最关键的选择之一，直接影响 RPO（数据丢失风险） 和性能。

异步复制（Asynchronous）：

机制：主库提交事务时，无需等待备库的确认，即可向客户端返回成功。优点：性能极高，事务延迟不受网络延迟影响。缺点：存在数据丢失风险。如果主库在WAL记录传输到备库前发生不可恢复的故障，已提交的事务数据将会丢失。配置：
synchronous_commit = off (或
local,
remote_write 在某些版本中等效于异步)。

同步复制（Synchronous）：

机制：主库提交事务时，会等待至少一个同步备库接收并写入WAL日志后，才向客户端返回成功。优点：数据零丢失（RPO=0），提供了更高级别的数据一致性保证。缺点：增加事务延迟，延迟时间为主备库网络往返时间（RTT） + 备库磁盘I/O时间。如果同步备库宕机，主库的写操作会被阻塞，直到备库恢复或从同步列表中移除。配置：
synchronous_commit = on (或
remote_apply) 并指定
synchronous_standby_names = 'standby_slot_name'。

选择建议：大多数对性能敏感的应用（如电商）可采用异步复制；对数据一致性要求极高的核心系统（如金融交易）则应采用同步复制。

五、最佳实践与注意事项

监控复制状态：定期查询
pg_stat_replication 视图，监控
state,
write_lag,
flush_lag,
replay_lag 等关键指标，确保复制健康且延迟在可接受范围内。使用复制槽：强烈建议使用复制槽，它可以精确跟踪备库的复制进度，避免因主库的
wal_keep_size 设置不足或日志清理导致复制中断。网络与硬件：主备库之间的网络质量（带宽、延迟）直接影响复制性能和稳定性。理想情况下，它们应部署在高速、稳定的内网中。对于异地容灾，需评估网络成本与延迟。备库只读查询（Hot Standby）：备库可以设置为
hot_standby = on，使其在应用 WAL 的同时能够处理只读查询。这极大地提升了资源利用率，可以用作报表查询、读写分离等，但要注意查询可能会稍有延迟。

总结

PostgreSQL 的流复制是一项经过千锤百炼的成熟技术，它通过高效传输和重放 WAL 日志，实现了数据的近乎实时同步。理解其工作原理、熟练配置同步模式、并遵循最佳实践，是构建稳定、可靠的企业级数据库高可用与灾备体系的基石。无论是为了故障自动切换，还是仅为数据备份和读写分离，流复制都是 PostgreSQL DBA 工具箱中不可或缺的首选利器。