独立服务器上的 PostgreSQL 流复制指南

PostgreSQL 流复制会在事务写入时，把预写式日志（WAL）记录从主数据库服务器传送到一个或多个备用服务器。这种架构可以支持读取扩展、报表、维护时段和更快恢复，而无需改变应用程序的数据模型。

在独立服务器上，团队可以控制 CPU、内存、存储、网络路径和操作系统设置，让复制更容易按实际负载规划；但这并不代表可以忽略 WAL 保留、复制延迟、故障切换、备份和恢复测试。本指南整理正式部署前的主要规划重点。

PostgreSQL 流复制如何运行

主服务器会把每项已提交的变更写入 WAL。备用服务器通过复制用户连接，从 WAL sender 接收记录，在本地写入并重放。备用服务器在追上进度前，可以保持只读状态。

PostgreSQL 流复制属于数据库层面的设计，而托管层会影响节点之间能否稳定通信。Dataplugs 的实时协作平台托管基础设施文章也把状态一致性、备份设计、复制和故障切换视为基础设施问题。

• 主服务器和备用服务器角色清晰，并应记录在操作文档内
• WAL sender、WAL receiver 和重放进程负责传送及应用变更
• 异步复制会在备用服务器重放前确认主服务器的写入
• 同步复制会等待一个或多个备用服务器后才确认提交
• 物理复制复制整个集群；逻辑复制则按数据库对象选择变更

同步与异步复制的选择

异步复制通常可以保持较低的写入延迟，因为主服务器不必等待备用服务器。代价是发生故障时，最新事务可能尚未在备用服务器上可用。同步复制可以减少这种数据差距，但每项提交都取决于所设置的备用服务器和网络路径。

合适的模式应按恢复点目标（RPO）、恢复时间目标（RTO）和服务器距离决定。Dataplugs 的专用托管的备份与灾难恢复贴士也提醒，复制、备份和故障切换程序分别处理不同的恢复问题。

• 写入延迟和读取扩展较重要时，可以使用异步备用服务器
• 不能接受已确认事务丢失时，才考虑同步复制
• 多个备用服务器参与确认时，可以按需要使用仲裁设置
• 把同步节点放在不同地点前，先测量往返延迟
• 同时保留独立的备份和时间点恢复路径

PostgreSQL 副本的独立服务器容量规划

主服务器和备用服务器的规模，应按写入量、数据集、查询组合、检查点活动和恢复目标计算，而不能只看连接数量。能够应付日常读取的备用服务器，在写入高峰时仍可能无法及时重放大量 WAL。

存储延迟往往会先在 WAL 刷新、检查点和重放过程中体现。Dataplugs 的季节性网站流量高峰的资源分配优化文章说明，应以测量所得的 CPU、内存、存储和带宽需求规划独立基础设施，而不是只按平均值估算。

• 为查询、WAL 压缩、vacuum 和重放预留 CPU 余量
• 为 shared_buffers、work_mem、连接池和文件系统缓存分配内存
• 数据文件、WAL 和临时工作使用低延迟 NVMe 存储
• 带宽需要应付 WAL、读取流量、备份和重建
• 为故障切换、重建索引、vacuum 和副本追赶保留容量余量

Tip: 应使用最大而合理的数据集和 WAL 高峰测试故障切换与副本重建，因为平均使用率可能掩盖恢复瓶颈。

WAL 保留、复制槽和延迟管理

WAL 必须保留到每个备用服务器取得所需记录为止。wal_keep_size、复制槽和 WAL 归档处理的是不同层面的保留要求。复制槽可以保护断线用户仍需的 WAL，但长期无人使用的槽可能让 pg_wal 持续占用磁盘。

• 监测复制延迟时，不只要看数值，也要找出原因。pg_stat_replication 可以在主服务器显示发送和接收进度，备用服务器的视图则可以显示接收状态和重放位置。告警应覆盖延迟时间、延迟量、复制槽增长和磁盘余量。
• 按最长预计断线或维护时段设置 WAL 保留量
• 检查使用者后才限制或移除没有用途的复制槽
• 追踪 sent、write、flush 和 replay 的 LSN 位置
• 在 WAL 或数据磁盘接近容量上限前发出告警
• 记录触发流量切换或故障切换决定的延迟门槛

故障切换、提升和应用程序路由

流复制负责传送数据，但不会自行决定何时把备用服务器提升为主服务器。提升需要操作员或协调工具、隔离旧主服务器的方法，以及把应用程序流量转移到新主服务器的受控流程。

独立服务器架构应测试完整流程：检测故障、提升正确节点、更新写入端点、重建连接池，并确认没有两个同时写入的 split-brain 主服务器。故障恢复和副本重建步骤也应写在同一份操作手册内。

• 清楚定义谁或什么工具有权提升备用服务器
• 允许新写入者运行前，先隔离或围堵旧主服务器
• 使用稳定的应用程序端点、代理或受控 DNS 变更
• 以退避方式重连，避免故障后出现连接风暴
• 记录故障恢复、时间线历史和事故后验证步骤

备份和时间点恢复

备用服务器不是备份。误删数据、错误迁移和已损坏的写入都可能同步到所有副本。应使用基础备份配合持续 WAL 归档，让团队可以恢复到事故发生前的指定时间点。

恢复副本应存放在主服务器之外，并在独立容量上定期测试还原。恢复计划需要写明保留期、加密、访问控制、还原顺序，以及硬件或软件故障后重建备用服务器所需的时间。

• 定期建立并验证基础备份
• 持续归档 WAL，并监测归档失败
• 以受保护的方式保留服务器外或跨站副本
• 使用时间点恢复处理操作员或应用程序错误
• 按订定的 RPO 和 RTO 进行还原与恢复演练

总结

在独立服务器上使用流复制，可以建立清晰的主备架构、可预测的资源分配，以及支持读取扩展和恢复的基础。要让设计可靠，必须一并定义 RPO/RTO、WAL 保留、故障切换权限、备份、安全和监测。

如果工作负载需要 PostgreSQL 及相关服务的可预测单租户容量，Dataplugs 提供具备可配置 CPU、内存、存储和网络选项的独立服务器方案。

如需了解更多，欢迎浏览 Dataplugs 或联系 sales@dataplugs.com。