PostgreSQL 高可用性：日志传送与流复制指南

光蛋
25 阅读24分钟

PostgreSQL 高可用性实现指南：日志传送与流复制

前言

PostgreSQL 提供的日志传送（Log Shipping） 技术是实现数据库高可用性（HA）的核心方案之一，该方案也被称为温备，通过主服务器的连续归档与后备服务器的连续恢复机制，实现主备节点的WAL（预写式日志）同步，在主服务器失效时后备服务器可快速接管业务。在此基础上延伸的流复制技术进一步降低了数据丢失窗口，提升了主备同步的实时性，而复制槽、级联复制、同步复制等特性则丰富了高可用配置的灵活性与可靠性。

本指南详细讲解PostgreSQL日志传送与流复制的核心原理、配置步骤及高级特性，所有配置与操作均基于PostgreSQL官方标准实现，无需修改数据库表结构，管理开销低且对主服务器性能影响较小，是生产环境中搭建PostgreSQL高可用集群的主流方案。

1 核心概述

1.1 日志传送基本原理

日志传送是指将主服务器生成的WAL记录传输到一台或多台后备服务器的过程，PostgreSQL原生支持基于文件的日志传送：主服务器以16MB为单位生成WAL段文件，通过连续归档机制将WAL段文件传输到后备服务器可访问的位置，后备服务器则在连续恢复模式下持续读取并应用这些WAL段文件。

WAL段文件的传输无物理距离限制，可部署在本地、同机房或跨地域节点，所需网络带宽由主服务器的事务率决定。

1.2 主备工作模式

  • 主服务器：运行在连续归档模式，开启WAL归档配置，持续生成并归档WAL段文件；
  • 后备服务器：运行在连续恢复/standby模式，通过standby.signal文件标识，持续从归档目录或主服务器直接读取WAL并应用。

1.3 关键特性与数据丢失说明

  1. 异步特性：日志传送（含基础流复制）默认是异步的，WAL记录在事务提交后才会被传输，若主服务器发生灾难性故障，未传输的事务会丢失；
  2. 数据丢失窗口控制：基于文件的日志传送可通过archive_timeout参数限制数据丢失窗口（最低可设为几秒），但过低的设置会增加带宽消耗；流复制则可实现更小的数据丢失窗口，无需依赖archive_timeout；
  3. 快速故障转移：后备服务器的恢复性能优异，激活后通常几秒内即可全面可用，该配置也被称为热备份配置；
  4. 只读查询能力：后备服务器可开启热备份模式，承接只读查询请求，提升集群整体读写分离能力。

1.4 流复制与基于文件日志传送的区别

流复制是对基于文件日志传送的升级，其核心差异在于：无需等待WAL段文件被填满，主服务器在生成WAL记录时实时流式传输给后备服务器，后备服务器增量接收并应用，同步延迟通常低于1秒（后备服务器性能可匹配主服务器负载时）。

流复制需基于TCP连接实现主备直连，而后备服务器仍会优先重放归档中的WAL段文件，再通过流复制接收实时WAL记录。

2 前期规划要点

为保证主备集群的稳定性与兼容性，搭建前需遵循以下规划原则，这是避免后续配置失败、数据不一致的关键。

2.1 服务器环境一致性

  1. 表空间路径：若使用表空间特性，主服务器与所有后备服务器的表空间挂载路径必须完全一致，CREATE TABLESPACE命令执行前，需在所有节点提前创建对应的挂载点；
  2. 硬件架构：主备服务器的硬件架构必须相同（32位与64位系统无法互通），硬件配置无需完全一致，但相同配置更便于后期维护；
  3. 系统环境：建议主备节点使用相同的操作系统、内核版本及依赖库，减少环境差异导致的兼容问题。

2.2 PostgreSQL版本兼容性

  1. 主版本：不同主版本的PostgreSQL之间无法进行日志传送（如13.x与14.x），WAL格式存在不兼容；
  2. 次版本：PostgreSQL不会在次版本升级中修改磁盘格式，主备节点可运行不同次版本（如15.3与15.4），但建议保持版本完全一致；
  3. 版本升级策略：升级次版本时，优先升级后备服务器，新版本通常兼容从旧次版本读取WAL文件，可最大程度保证集群可用性。

3 后备服务器核心操作

后备服务器的核心状态为standby模式，其启动、WAL读取、模式退出均遵循固定的执行逻辑，是主备同步的基础。

3.1 Standby模式启动

服务器启动时，若数据目录中存在 standby.signal 文件，则自动进入standby模式，无需额外启动参数。

3.2 WAL读取与应用的优先级

后备服务器会按以下循环顺序读取并应用WAL，直至服务器停止或被提升为主服务器：

  1. 调用restore_command从WAL归档目录恢复所有可用的WAL段文件，若该命令执行失败则进入下一步；
  2. 读取并恢复本地pg_wal目录中存在的WAL段文件，若无可用文件则进入下一步；
  3. 若配置了流复制，尝试通过TCP连接主服务器，从归档/本地pg_wal中最后一个有效记录开始流式接收WAL；若连接失败、未配置流复制或后续连接断开，则返回步骤1重新尝试。

3.3 退出Standby模式（提升为主服务器）

执行以下任一操作，后备服务器将立即退出standby模式，切换为正常操作模式，成为新的主服务器：

  1. 执行命令：pg_ctl promote；
  2. 调用SQL函数：pg_promote()。

注意：故障转移（提升）前，后备服务器会优先恢复归档/本地pg_wal中所有立即可用的WAL，但不会尝试连接原主服务器。

4 为主服务器配置后备环境

主服务器是WAL的生成源，需完成连续归档配置、复制权限配置、基础备份生成三步操作，为后备服务器提供同步基础。

4.1 配置连续归档

按PostgreSQL连续归档规范，在主服务器的postgresql.conf中配置WAL归档参数，核心要求：

  1. 归档目录需为后备服务器可访问的位置（如后备服务器本地目录、NFS共享目录、远程FTP/SCP目录），禁止将归档目录配置在主服务器本地（主服务器故障后后备服务器无法访问）；
  2. 核心配置参数包括wal_level（需设为replica或更高）、archive_mode（开启）、archive_command（WAL归档命令），具体配置可参考PostgreSQL连续归档官方文档。

4.2 流复制相关配置（若使用）

若后备服务器采用流复制方式同步WAL，主服务器需配置复制连接认证与并发连接限制：

  1. 创建复制专用角色：需赋予REPLICATION和LOGIN权限，推荐专用角色而非超级用户（REPLICATION权限仅用于复制，无法修改主服务器数据），示例：

    1. CREATE ROLE repl_user WITH REPLICATION LOGIN PASSWORD 'repl_pass';

  2. 配置pg_hba.conf：添加复制连接的访问控制规则，指定后备服务器IP、复制角色与认证方式，示例：

    1. # TYPE  DATABASE        USER            ADDRESS             METHOD
host    replication     repl_user       192.168.1.100/32    md5

  3. 修改postgresql.conf核心参数：

    1. max_wal_senders：设置最大WAL发送进程数，需大于等于后备服务器数量（流复制专用）；
    2. max_replication_slots：若使用复制槽，需设置为大于等于复制槽数量；
    3. listen_addresses：需包含后备服务器可访问的IP（如*或主服务器内网IP）；
    4. 可选：wal_keep_size：设置保留的WAL段文件大小，防止后备服务器未及时接收时WAL被回收。

  4. 重启主服务器或执行pg_ctl reload使配置生效。

4.3 生成基础备份

后备服务器需要主服务器的基础备份作为数据同步的基线，按PostgreSQL官方方式生成基础备份（如使用pg_basebackup命令），示例：

pg_basebackup -h 192.168.1.50 -U repl_user -D /pgdata/standby -P -X stream

其中/pgdata/standby为后备服务器的数据目录，-X stream表示流式复制WAL，保证备份的一致性。

5 搭建后备服务器

基于主服务器的基础备份，完成后备服务器的目录配置、参数配置，即可实现后备服务器的搭建，支持单主多备架构，步骤如下。

5.1 恢复基础备份

将主服务器生成的基础备份解压/恢复到后备服务器的数据目录（需为空，且目录所属用户为postgres），示例：

# 假设基础备份文件为pg_basebackup.tar，恢复到后备服务器数据目录
tar -xf pg_basebackup.tar -C /pgdata/standby
chown -R postgres:postgres /pgdata/standby

5.2 创建Standby模式标识文件

在后备服务器的数据目录中创建standby.signal文件，标识该节点为后备服务器：

touch /pgdata/standby/standby.signal
chown postgres:postgres /pgdata/standby/standby.signal

5.3 配置postgresql.conf核心参数

后备服务器需配置WAL恢复相关参数，核心配置：

  1. restore_command：从WAL归档目录复制WAL段文件的命令，需与主服务器归档目录匹配，示例：

    1. restore_command = 'cp /nfs/wal_archive/%f %p'
    2.   注意：该命令需立即返回，后备服务器会自动循环重试，无需设置阻塞逻辑；

  2. recovery_target_timeline：设为latest（默认值），保证后备服务器能跟随故障转移后的新主服务器的时间线变化；

  3. hot_standby：设为on（可选），开启热备份模式，允许后备服务器承接只读查询；

  4. 若为高性能场景，可配置与主服务器相同的shared_buffers、work_mem等性能参数。

5.4 配置流复制连接（若使用）

若采用流复制方式，需在后备服务器的数据目录中创建 postgresql.auto.conf 文件（或修改postgresql.conf），配置主服务器连接信息与可选的复制槽，核心参数：

  1. primary_conninfo：libpq格式的主服务器连接字符串，包含主服务器IP、端口、复制角色、密码等，示例：

    1. primary_conninfo = 'host=192.168.1.50 port=5432 user=repl_user password=repl_pass options=''-c wal_sender_timeout=5000'''

  2. primary_slot_name：若使用复制槽，指定主服务器上创建的复制槽名称，示例：

    1. primary_slot_name = 'standby_01_slot'

5.5 配置WAL归档清理（可选）

若使用WAL归档，可通过archive_cleanup_command参数自动清理后备服务器不再需要的WAL段文件，减少归档目录占用，推荐使用PostgreSQL自带的pg_archivecleanup工具，示例：

archive_cleanup_command = 'pg_archivecleanup /nfs/wal_archive %r'

注意：若归档目录同时用于灾难恢复，需保留至少最后一个基础备份对应的WAL文件，避免清理后无法恢复。

5.6 启动后备服务器

完成以上配置后，启动后备服务器，示例：

pg_ctl -D /pgdata/standby start

启动后可通过pg_stat_wal_receiver视图验证流复制连接状态（若使用流复制）。

5.7 多后备服务器配置注意事项

若搭建多台后备服务器，需保证：

  1. 每台后备服务器均完成上述独立配置，数据目录相互独立；
  2. 主服务器的max_wal_senders参数值大于等于后备服务器数量，保证所有后备服务器能同时建立流复制连接；
  3. 若使用复制槽，为主服务器的每台后备服务器创建独立的复制槽，避免槽冲突。

6 流复制高级配置与监控

流复制是生产环境中最常用的同步方式，除基础连接配置外，还需掌握连接保活、同步状态监控、异常处理等高级操作。

6.1 配置流复制连接保活

在主服务器的postgresql.conf或后备服务器的primary_conninfo中配置TCP保活参数，确保主服务器能快速检测到断开的连接，适用于支持keepalive套接字的系统，示例（在primary_conninfo中配置）：

primary_conninfo = 'host=192.168.1.50 port=5432 user=repl_user password=repl_pass tcp_keepalives_idle=30 tcp_keepalives_interval=5 tcp_keepalives_count=6'

参数说明：

  • tcp_keepalives_idle：TCP连接空闲多久后发送保活包（秒）；
  • tcp_keepalives_interval：保活包发送间隔（秒）；
  • tcp_keepalives_count：连续发送多少个保活包无响应则断开连接。

6.2 流复制状态监控

流复制的核心监控指标是主备WAL延迟，需通过主备节点的系统视图/函数联合查询，核心监控项与查询方式如下。

6.2.1 核心WAL位置函数
  • 主服务器：pg_current_wal_lsn() → 当前WAL写入位置；
  • 后备服务器：pg_last_wal_receive_lsn() → 最后接收的WAL位置；
  • 后备服务器：pg_last_wal_replay_lsn() → 最后应用的WAL位置。

WAL延迟计算：

  • 接收延迟 = 主服务器pg_current_wal_lsn() - 后备服务器pg_last_wal_receive_lsn()；
  • 应用延迟 = 后备服务器pg_last_wal_receive_lsn() - 后备服务器pg_last_wal_replay_lsn()。
6.2.2 主服务器监控视图：pg_stat_replication

该视图展示主服务器上所有WAL发送进程的状态，核心字段：

  • sent_lsn：主服务器已发送的WAL位置；
  • write_lsn：后备服务器已写入本地的WAL位置；
  • flush_lsn：后备服务器已刷写到磁盘的WAL位置；
  • replay_lsn：后备服务器已应用的WAL位置；
  • sync_state：同步状态（async为异步，sync为同步，potential为潜在同步）。

异常判断：

  • pg_current_wal_lsn()与sent_lsn差距过大 → 主服务器负载过高，无法及时发送WAL；
  • sent_lsn与后备服务器pg_last_wal_receive_lsn()差距过大 → 网络延迟或后备服务器接收能力不足。
6.2.3 后备服务器监控视图：pg_stat_wal_receiver

该视图展示后备服务器上WAL接收进程的状态，核心字段：

  • flushed_lsn：已刷写到磁盘的WAL位置；
  • received_lsn：已接收的WAL位置；
  • replay_lsn：已应用的WAL位置。

异常判断：received_lsn与flushed_lsn/replay_lsn差距过大 → 后备服务器WAL接收速度大于应用速度，负载过高。

6.3 无归档流复制的WAL保留策略

若流复制未搭配基于文件的连续归档，主服务器可能在后备服务器接收前回收旧WAL段文件，导致后备服务器无法同步，需通过以下任一方式避免：

  1. 设置wal_keep_size：指定主服务器保留的WAL段文件大小，需足够大以覆盖后备服务器的最大中断时间；
  2. 使用复制槽：自动化保留后备服务器所需的WAL段文件，精准且无冗余，为推荐方案。

7 复制槽（Replication Slots）

复制槽是PostgreSQL提供的自动化WAL与数据保留机制，解决了传统WAL保留方式（wal_keep_size、归档）的冗余或不足问题，同时能防止后备服务器断开时主服务器执行真空删除导致的恢复冲突。

7.1 核心优势

  1. 精准WAL保留：仅保留后备服务器未接收的WAL段文件，无冗余，相比wal_keep_size更节省磁盘空间；
  2. 持续数据保护：即使后备服务器断开连接，仍能防止主服务器删除可能导致恢复冲突的行，相比hot_standby_feedback（仅连接时有效）更可靠；
  3. 自动化管理：复制槽的WAL保留逻辑由PostgreSQL自动维护，无需人工干预。

7.2 注意事项

复制槽可能因后备服务器长期断开而持续保留WAL，导致主服务器pg_wal目录占满磁盘，需通过以下参数限制：

max_slot_wal_keep_size = 10GB

该参数指定单个复制槽可保留的最大WAL文件大小，超出后PostgreSQL会停止保留，避免磁盘溢出。

7.3 复制槽的创建与查询

7.3.1 创建物理复制槽

物理复制槽适用于本指南的物理流复制场景，在主服务器上执行SQL函数创建，示例：

-- 创建名为standby_01_slot的物理复制槽
SELECT * FROM pg_create_physical_replication_slot('standby_01_slot');
7.3.2 查询复制槽状态

通过pg_replication_slots视图查看所有复制槽的状态，核心字段：

  • slot_name：复制槽名称；
  • slot_type：复制槽类型（physical为物理复制，logical为逻辑复制）；
  • active：是否处于活跃状态（t为后备服务器已连接，f为断开）；
  • restart_lsn：复制槽保留的最小WAL位置。

查询示例：

SELECT slot_name, slot_type, active, restart_lsn FROM pg_replication_slots;
7.3.3 删除复制槽

若后备服务器下线，需及时删除对应的复制槽，避免无效WAL保留，示例：

SELECT pg_drop_replication_slot('standby_01_slot');

7.4 后备服务器配置复制槽

在后备服务器的postgresql.auto.conf中配置primary_slot_name参数，指定主服务器上创建的复制槽名称，示例：

primary_conninfo = 'host=192.168.1.50 port=5432 user=repl_user password=repl_pass'
primary_slot_name = 'standby_01_slot'

配置后重启后备服务器，即可基于复制槽实现WAL同步。

8 级联复制（Cascading Replication）

级联复制允许后备服务器作为转发节点，接收主服务器的WAL后，再流式传输给其他后备服务器，核心价值是减少主服务器的直接连接数、降低跨地域部署的带宽开销（如主服务器在机房A，级联后备在机房B，其他后备在机房C，仅机房A与B需跨地域传输WAL）。

8.1 核心概念

  • 级联后备服务器：同时作为WAL接收者和发送者的后备服务器；
  • 上游服务器：直接向当前节点传输WAL的节点（主服务器或更高层级的级联后备）；
  • 下游服务器：从当前节点接收WAL的后备服务器。

8.2 核心特性

  1. 无层级限制：级联复制的下游服务器数量、级联层级无官方限制，可按需部署；
  2. 多源WAL转发：级联后备服务器不仅转发从上游流复制接收的WAL，还会转发从归档中恢复的WAL，上游连接断开时下游仍可通过归档同步；
  3. 热备份反馈向上传播：下游服务器的hot_standby_feedback会逐层向上传播至主服务器，防止主服务器执行真空删除导致的恢复冲突；
  4. 故障转移自动跟随：若上游后备服务器被提升为新主服务器，下游服务器若recovery_target_timeline=latest（默认），会自动从新主服务器同步WAL；
  5. 异步特性：当前级联复制仅支持异步，同步复制配置对级联复制无影响。

8.3 级联复制配置步骤

级联复制的配置核心是将级联后备服务器配置为可接收流复制连接，再将下游服务器的连接指向级联后备，步骤如下：

  1. 配置级联后备服务器：

    1. 修改postgresql.conf：设置max_wal_senders > 0（允许WAL发送）、hot_standby = on（开启热备份）；
    2. 配置pg_hba.conf：添加下游服务器的复制连接规则，与主服务器的复制权限配置一致；
    3. 重载配置：pg_ctl reload；

  2. 配置下游服务器：

    1. 修改primary_conninfo参数，将连接地址从主服务器改为级联后备服务器的IP/端口；
    2. 若使用复制槽，在级联后备服务器上创建复制槽，并配置primary_slot_name；

  3. 重启下游服务器，完成级联复制配置。

9 同步复制（Synchronous Replication）

默认的流复制为异步，主服务器提交事务后无需等待后备服务器确认，可能存在数据丢失；同步复制则要求主服务器在提交事务时，等待一台或多台同步后备服务器确认已将WAL写入磁盘（或应用），仅当主备同时崩溃时才会丢失数据，属于2-safe复制，提供更高的持久性保障。

9.1 核心特性

  1. 提交等待机制：主服务器的写事务提交会阻塞，直至收到同步后备服务器的WAL确认，只读事务、回滚、子事务提交无需等待；
  2. 细粒度配置：可通过synchronous_commit参数在全局、用户、数据库、事务级别控制是否使用同步复制，实现“核心事务同步，非核心事务异步”的精细化策略；
  3. 多同步后备支持：支持配置多台同步后备服务器，可要求事务等待所有或任意N台同步后备的确认。

9.2 基本配置

流复制是同步复制的基础，需先完成基础流复制配置，再在主服务器上添加以下核心配置：

  1. synchronous_standby_names：设为非空值，指定同步后备服务器的选择规则（核心配置），该参数是同步复制的开关；

  2. synchronous_commit：设为on（默认值），表示事务提交等待后备服务器将WAL刷写到磁盘，其他可选值：

    1. remote_write：等待后备服务器将WAL写入操作系统缓存（非磁盘），降低提交延迟，持久性略低于on；
    2. remote_apply：等待后备服务器将WAL应用完成，事务在后备服务器上可见，支持因果一致性的读写分离；
    3. off：关闭同步复制，恢复为异步。

配置示例（主服务器postgresql.conf）：

# 开启同步复制，指定同步后备为standby_01
synchronous_standby_names = 'standby_01'
# 全局默认同步级别：等待后备刷写到磁盘
synchronous_commit = on

注意：同步复制的配置主要在主服务器上，且仅支持直接连接主服务器的后备服务器，级联后备无法成为同步后备。

9.3 多同步后备服务器配置

synchronous_standby_names支持通过FIRST和ANY两种方法配置多台同步后备，实现更灵活的高可用策略。

9.3.1 FIRST：基于优先级的同步

要求事务等待前N台优先级最高的同步后备的确认，若某台同步后备失效，自动由下一台优先级的后备替代。

配置格式：FIRST N (后备1, 后备2, 后备3,...)

示例：

# 等待前2台同步后备（standby_01、standby_02）的确认，standby_03为潜在同步后备
synchronous_standby_names = 'FIRST 2 (standby_01, standby_02, standby_03)'
9.3.2 ANY：基于数量的同步

要求事务等待列表中任意N台同步后备的确认，无需考虑优先级，只要达到指定数量即可。

配置格式：ANY N (后备1, 后备2, 后备3,...)

示例：

# 等待列表中任意2台同步后备的确认
synchronous_standby_names = 'ANY 2 (standby_01, standby_02, standby_03)'
9.3.3 查看同步状态

通过主服务器的pg_stat_replication视图的sync_state字段查看后备服务器的同步状态：

  • sync：当前同步后备；
  • potential：潜在同步后备（优先级较低或未达到数量要求）；
  • async：异步后备（未在synchronous_standby_names列表中）。

9.4 性能与高可用性规划

同步复制虽提升了数据持久性，但也会增加事务提交延迟，需做好以下规划：

  1. 性能规划：

    1. 网络带宽：需保证主备之间的带宽大于WAL生成速率，避免网络成为瓶颈；
    2. 事务分级：对核心事务（如资金交易）设置synchronous_commit = on，对非核心事务（如日志记录）设置synchronous_commit = off，平衡性能与持久性；
    3. 节点部署：同步后备服务器建议与主服务器部署在同机房或低延迟的同城机房，避免跨地域的高延迟导致事务提交缓慢。

  2. 高可用性规划：

    1. 配置足够的潜在同步后备，避免同步后备失效导致主服务器事务提交阻塞；
    2. 若同步后备全部失效，可临时将synchronous_standby_names设为空（禁用同步复制），并重载配置，保证主服务器业务正常；
    3. 后备服务器启动后会进入追赶模式，直至与主服务器WAL延迟为0才会成为同步后备，可通过pg_stat_replication视图的replay_lsn监控追赶进度。

9.5 特殊场景处理

  1. 主服务器重启：若事务提交时正等待同步后备确认，主服务器重启后这些事务会被标记为已提交，无需重新执行；
  2. 快速关闭主服务器：主服务器快速关闭时，会停止等待同步后备确认，但会等待所有未传输的WAL发送到已连接的后备服务器；
  3. 同步后备重建：重建同步后备时，需在主服务器上执行pg_backup_start()和pg_backup_stop()，并临时设置synchronous_commit = off，避免备份命令因等待同步后备而阻塞。

10 后备机上的连续归档

后备服务器也可开启连续归档，实现WAL的多层级备份，需根据归档是否与主服务器共享，采用不同的配置策略，核心参数为archive_mode的always值。

10.1 归档模式说明

PostgreSQL的archive_mode有三个取值：

  • off：关闭归档；
  • on：仅在正常操作模式（主服务器）下开启归档，standby模式下禁用；
  • always：正常操作模式和standby模式下均开启归档，是后备服务器归档的核心配置。

10.2 两种归档场景配置

10.2.1 后备服务器拥有独立的WAL归档

核心配置：将后备服务器的archive_mode设为always，并配置独立的archive_command（与主服务器归档目录分离）。

该模式下，后备服务器会对所有接收到的WAL段文件（无论来自归档恢复还是流复制）执行归档操作，实现WAL的双重备份，适用于灾难恢复要求较高的场景。

10.2.2 后备服务器与主服务器共享WAL归档

核心配置：

  1. 后备服务器archive_mode = always；
  2. archive_command需增加文件存在性与内容校验逻辑，避免主备服务器同时归档同一WAL文件导致的覆盖或竞争；
  3. 若WAL文件已存在且内容一致，archive_command需返回成功，否则执行归档。

该模式下需保证归档命令的原子性，避免竞争条件，适用于归档存储资源有限的场景。

10.3 关键注意事项

  1. 若后备服务器的archive_mode设为on，则仅在被提升为主服务器后才会开启归档，不会归档standby模式下接收的WAL；
  2. 流复制场景下，主服务器的WAL可能未归档即被传输到后备服务器，若需实现完整的WAL归档，需保证主服务器的WAL在传输到后备服务器前已完成归档；
  3. 共享归档时，需使用支持原子写的文件系统或归档工具，避免主备服务器同时写入同一WAL文件。

总结

PostgreSQL的日志传送与流复制是一套轻量、高效的高可用实现方案，从基础的基于文件的日志传送，到实时的流复制，再到复制槽、级联复制、同步复制等高级特性，可满足不同生产场景的高可用需求：

  • 中小规模场景：采用异步流复制+复制槽，兼顾实时性与易用性，数据丢失窗口可控制在秒级；
  • 高持久性场景：采用同步复制+多潜在同步后备，实现2-safe复制，仅主备同时崩溃才会丢失数据；
  • 跨地域部署场景：采用级联复制，减少跨地域带宽开销，提升集群整体稳定性；
  • 高灾难恢复要求场景：采用后备服务器独立归档，实现WAL的多层级备份，提升数据可恢复性。

在实际部署时，需重点保证主备节点的环境一致性、网络稳定性，并做好WAL磁盘空间、复制状态的监控，同时根据业务特性做好同步/异步的精细化配置，平衡数据持久性与集群性能。

avatar
文章
阅读
粉丝