PostgreSQL 12 同步流复制搭建与主备切换

结果或目标

完成 PostgreSQL 12 的一主两备（或一主多备）同步流复制环境搭建，确保在主库故障时，可通过 SQL 命令快速将处于同步状态的备库提升为新的主库，实现业务连续性。

准备条件

• 网络环境：所有节点间网络互通，关闭防火墙或放行相应端口（默认 5432）。
• 系统用户：建议各节点使用相同的 OS 用户（如 pg12）管理数据库实例，且密码一致以便免密备份。
• 初始状态：主库已安装 PostgreSQL 12 并正常运行；备用节点已安装相同版本 PG 12，但尚未初始化或未启动数据库服务。
• 权限要求：pg_hba.conf 修改需 root 或具有写权限的用户操作；postgresql.conf 修改需数据库超级用户权限；备库提升操作需超级用户执行。

真实操作顺序

第1步：配置主库接受流复制连接

目的：允许指定 IP 段的服务器作为备库通过流复制协议从主库拉取 WAL 日志。

入口：编辑主库 $PGDATA/pg_hba.conf 文件。

动作：

1. 添加一行记录，允许来自备库网段（例如 192.168.7.0/24）的连接。
2. 指定认证方法为 trust（生产环境建议改为 md5 并使用专用复制账户）。

# TYPE  DATABASE        USER            ADDRESS                 METHOD
host  replication     all             192.168.7.0/24           trust

重要参数：ADDRESS 需准确对应备库的实际 IP 范围。

完成状态：保存配置文件，无需重启即可生效，但建议重启主库或使用 SELECT pg_reload_conf(); 重新加载配置以确保无误。

第2步：配置主库流复制核心参数

目的：在 postgresql.conf 中启用流复制所需的 WAL 级别及同步备库策略。

入口：编辑主库 $PGDATA/postgresql.conf 文件。

动作：确认或添加以下关键参数：

listen_addresses = '*'
max_wal_senders = 5
wal_level = replica  # PG12 推荐值为 'replica' 而非旧的 'hot_standby'
synchronous_standby_names = 'ANY1(standby01,standby02)'

重要参数说明：

• wal_level = replica：确保生成足够的 WAL 信息以支持流复制和逻辑解码。
• synchronous_standby_names：ANY1(...)表示只要有一个列出的备库确认接收到了 WAL，就认为当前事务提交成功，这是实现“同步”复制的关键。

完成状态：参数写入文件，主库服务正常，可通过 show synchronous_standby_names; 验证配置。

第3步：初始化工库并传输到备库

目的：从主库获取完整的数据目录副本，建立备库的基础数据环境。

入口：备库节点终端。

动作：

1. 确保备库上的 $PGDATA 目录为空，或不存在。
2. 使用 pg_basebackup 工具进行物理备份：

pg_basebackup -h <主库IP> -U <用户名> -F p -P -R -D /path/to/new/pgdata -l backup_$(date +%Y%m%d)

重要参数：

• -R：自动在生成的数据目录中创建 standby.signal 文件，并生成包含连接信息的 postgresql.auto.conf。
• -P：显示进度条。

注意：若手动指定 -R 未生效或需更精细控制，请参照下文手动创建配置文件。

第4步：配置备库连接信息与信号文件

目的：告知备库如何连接主库，并声明自身为物理备库。

入口：备库 $PGDATA 目录。

动作：

1. 检查 standby.signal：如果 pg_basebackup -R 执行成功，此文件应已存在。若未创建或位置有误，需在 $PGDATA 根目录下创建一个空文件名为 standby.signal。
2. 配置 primary_conninfo：在 $PGDATA/postgresql.conf 中添加主库连接信息（或在 postgresql.auto.conf 中指定）：

primary_conninfo = 'application_name=standby01 user=bill host=<主库IP> port=5432 passfile=''/home/user/.pgpass'' sslmode=disable'

重要参数：

• application_name：将在主库 pg_stat_replication 视图中显示的名称，用于标识不同备库。
• passfile：指向包含主库登录凭证的 .pgpass 文件路径，避免明文密码暴露。

完成状态：配置文件修改完毕，准备好启动服务。

第5步：启动备库并验证复制状态

目的：启动备库实例，观察其是否与主库保持同步。

入口：备库节点终端。

动作：

1. 使用正确的数据目录启动 PostgreSQL：

pg_ctl start -D /path/to/new/pgdata

2. 在主库查询验证：连接到主库，执行以下 SQL 查看备库是否正在以同步模式流复制：

SELECT * FROM pg_stat_replication;

可观察的完成状态：

• state 字段显示为 streaming。
• sync_state 显示为 sync（如果在 synchronous_standby_names 中定义）或 async。
• sent_lsn, write_lsn, flush_lsn, replay_lsn 数值应基本一致或差异极小。

至此，同步流复制环境搭建完成。

第6步：测试主备切换（Failover）

目的：模拟主库故障，将同步备库提升为独立的主库。

风险提示：切换操作将导致原主库不可用，新主库变为读写状态，业务侧需配合切换连接地址。执行前确保已完成必要的数据备份。

入口：备库节点终端及数据库客户端。

动作：

1. 停止主库（模拟故障）：

pg_ctl stop -m fast -D /path/to/master/pgdata

2. 触发备库提升：

PostgreSQL 12 推荐使用 SQL 函数方式激活备库：

-- 在备库连接的数据库中执行

SELECT pg_promote(true, 60);

重要参数：

• true：等待提升过程完成或超时后返回。
• 60：最大等待秒数。

3. 验证提升结果：

使用操作系统命令检查集群状态：

pg_controldata | grep 'Database cluster state'

可观察的完成状态：

• 输出 Database cluster state: in production 表明该节点已成功提升为新的主库。
• 此时可对该库进行读写操作。

第7步：恢复原主库作为新备库（可选）

目的：当原主库修复后，将其重新加入集群作为新主库的备库，以重建高可用架构。

动作：

1. 在原主库上清空或重命名旧的数据目录。
2. 使用 pg_basebackup 从当前有效的新主库拉取数据（步骤同第3步）。
3. 更新新主库的 pg_hba.conf 以允许原主库的 IP 接入。
4. 启动原主库，它将自动成为新主库的备库。

原文有依据的排错

• 备库启动失败，提示找不到 recovery.conf：PostgreSQL 12 已移除 recovery.conf。检查 $PGDATA 下是否存在 standby.signal（针对物理备库）或 primary_conninfo 是否正确配置在 postgresql.conf 或 postgresql.auto.conf 中。
• 复制延迟大或 sync_state 始终为 async：检查主库 synchronous_standby_names 设置中的名称是否与应用层设置的 application_name 完全匹配。如果是 ASYNC 模式，则无此限制，但会牺牲数据一致性。
• pg_promote() 调用报错：确保连接的是备库实例，且具有超级用户权限。若在只读模式下无法执行。

简要总结

PostgreSQL 12 简化了流复制配置，通过合并配置项和引入 pg_promote() 使得高可用架构的运维更加直观。关键在于正确配置 synchronous_standby_names 以实现强一致性复制，并熟练掌握基于 standby.signal 的备库初始化流程。以上就是 PostgreSQL 12 同步流复制搭建及主备切换方式的详细内容，更多关于 PostgreSQL 高可用架构优化的资料请关注本站其它相关文章！