引言：理解PostgreSQL主从复制的核心价值
在现代应用架构中，数据库的高可用性和数据安全性是至关重要的。PostgreSQL作为功能最强大的开源关系型数据库之一，提供了成熟且灵活的主从复制（Streaming Replication）机制。主从复制不仅能提供数据冗余备份，还能实现读写分离、负载均衡和故障自动切换，是构建生产级高可用数据库集群的基石。
通过本指南，你将从零开始掌握PostgreSQL主从复制的完整搭建流程，深入理解WAL（Write-Ahead Logging）日志传输机制，并学会如何配置同步与异步复制、监控复制延迟以及实现故障自动切换（Failover）。
第一部分：环境准备与基础概念
1.1 硬件与软件要求
为了模拟生产环境，我们需要准备至少两台服务器（虚拟机或物理机均可）：
主节点 (Primary)
: IP地址
192.168.1.100
从节点 (Standby)
: IP地址
192.168.1.101
操作系统
: 推荐 CentOS
7
⁄
8
或 Ubuntu 20.04 LTS
PostgreSQL版本
: 14.x (本教程以PG 14为例，其他版本配置大同小异)
基础配置要求
：
两台机器时间必须同步（建议配置NTP服务）。
主从节点之间网络互通，且防火墙开放5432端口。
确保两台机器的
ulimit
设置足够大，以支持高并发连接。
1.2 核心概念：WAL与流复制
在动手配置之前，必须理解其背后的原理：
WAL (Write-Ahead Logging)
: PostgreSQL在修改数据文件之前，会先将修改记录写入WAL日志。这是保证事务持久性的关键。
流复制 (Streaming Replication)
: 主库将生成的WAL日志记录通过TCP/IP连接实时传输给从库。从库收到日志后，不断重放（Replay）这些日志，从而保持与主库的数据一致。
复制类型
：
异步复制 (Asynchronous)
: 主库提交事务时，无需等待从库确认。性能最好，但存在极小的数据丢失风险（主库宕机时，最后提交的事务可能未传到从库）。
同步复制 (Synchronous)
: 主库提交事务时，必须等待至少一个从库确认已收到WAL日志。保证数据零丢失，但会增加事务响应时间。
半同步复制
: 介于两者之间，通常配置为等待一个从库确认。
第二部分：主节点 (Primary) 配置
2.1 安装 PostgreSQL
在主节点上安装 PostgreSQL 14：
# Ubuntu/Debian 示例
sudo apt update
sudo apt install postgresql-14 postgresql-client-14
# CentOS/RHEL 示例
sudo yum install -y postgresql14-server postgresql14-contrib
sudo /usr/pgsql-14/bin/postgresql-14-setup initdb
sudo systemctl enable –now postgresql-14
2.2 修改配置文件
PostgreSQL的配置文件通常位于
/etc/postgresql/14/main/
(Ubuntu) 或
/var/lib/pgsql/14/data/
(CentOS)。我们需要修改三个核心文件：
postgresql.conf
、
pg_hba.conf
和
pg_ident.conf
。
2.2.1 修改
postgresql.conf
这是主库的核心配置文件，我们需要调整以下参数以开启流复制功能：
# 1. 监听所有IP，或者指定监听内网IP
listen_addresses = ‘*’
# 2. 指定WAL日志发送的最大进程数，建议大于等于从库数量
max_wal_senders = 10
# 3. 预留用于流复制的WAL日志段文件数量，防止主库清理过快导致从库断开
wal_keep_size = 512MB # PG 13+ 使用此参数，旧版为 wal_keep_segments
# 4. 开启归档模式（虽然流复制主要依赖流传输，但开启归档是生产环境的最佳实践）
archive_mode = on
archive_command = ‘cp %p /var/lib/pgsql/14/archive/%f’
# 5. 日志级别（可选，用于调试）
log_statement = ‘all’
log_line_prefix = ‘%t [%p]: [%l-1] user=%u,db=%d,app=%a,client=%h ‘
修改后重启服务
：
sudo systemctl restart postgresql-14
2.2.2 修改
pg_hba.conf
(Host-Based Authentication)
此文件控制谁可以连接到数据库。我们需要允许从节点的IP连接并进行复制。
在文件末尾添加以下行：
# TYPE DATABASE USER ADDRESS METHOD
# 允许从节点连接到 postgres 数据库进行复制，使用 md5 密码认证
host replication replicator 192.168.1.101/32 md5
# 允许从节点连接所有数据库（用于后续的故障切换工具连接）
host all all 192.168.1.101/32 md5
注意
：这里的
replicator
是我们即将创建的专门用于复制的用户。
2.3 创建复制用户
登录主库数据库，创建一个专门用于流复制的用户：
— 切换到 postgres 系统用户
sudo -u postgres psql
— 创建用户并授权
CREATE USER replicator WITH REPLICATION ENCRYPTED PASSWORD ‘StrongPassword123!’;
第三部分：从节点 (Standby) 配置与基础备份
3.1 停止从库服务
在从节点上，如果已经运行了PostgreSQL，需要先停止并清空数据目录：
sudo systemctl stop postgresql-14
sudo -u postgres rm -rf /var/lib/pgsql/14/data/*
3.2 使用 pg_basebackup 进行基础备份
这是搭建从库最关键的一步。我们需要使用主库的数据来初始化从库。
pg_basebackup
是PostgreSQL自带的工具，它会复制主库的整个数据目录（包括配置文件）。
在
从节点
上执行以下命令：
# 执行备份命令
# -h: 主库IP
# -U: 复制用户
# -D: 目标数据目录（必须为空）
# -Fp: 输出格式为纯数据文件
# -Xs: 在备份过程中流式传输WAL日志
# -R: 生成用于连接的配置文件（方便后续启动）
sudo -u postgres pg_basebackup -h 192.168.1.100 -U replicator -p 5432 -D /var/lib/pgsql/14/data/ -Fp -Xs -P -R
# 系统会提示输入密码：StrongPassword123!
命令解析
：
-R
参数非常重要，它会自动在数据目录下生成
standby.signal
标志文件，并在
postgresql.auto.conf
中写入主库的连接信息（primary_conninfo）。这使得从库启动时自动进入恢复模式。
3.3 验证从库配置
备份完成后，检查从库的配置：
检查
standby.signal
文件
：
ls /var/lib/pgsql/14/data/standby.signal
如果存在，说明从库已标记为待机模式。
检查
postgresql.auto.conf
：
cat /var/lib/pgsql/14/data/postgresql.auto.conf
你应该能看到类似以下内容：
primary_conninfo = ‘user=replicator password=StrongPassword123! host=192.168.1.100 port=5432 sslmode=prefer sslcompression=0 gssencmode=prefer krbsrvname=postgres target_session_attrs=any’
调整从库参数 (可选)
：
默认情况下，从库是只读的。但为了防止误操作，可以在从库的
postgresql.conf
中显式设置：
hot_standby = on
第四部分：启动集群与验证同步
4.1 启动服务
先启动主节点
(如果之前重启过，确保已运行)。
再启动从节点
：
sudo systemctl start postgresql-14
4.2 验证复制状态
4.2.1 检查主库 WAL 发送进程
在
主节点
上执行：
— 查看 WAL 发送进程状态
SELECT * FROM pg_stat_replication;
预期结果
：
如果配置成功，你会看到一行记录，显示从库的 IP 地址、状态（
startup
,
catchup
,
streaming
）、应用的 LSN（日志序列号）等信息。
state
: 应该是
streaming
（流式传输中）。
client_addr
: 应该是
192.168.1.101
。
4.2.2 检查从库恢复状态
在
从节点
上执行：
— 查看从库是否处于恢复模式（即备库模式）
SELECT pg_is_in_recovery();
预期结果
：
返回
t
(true)，表示当前数据库处于恢复模式，即作为备库运行。
第五部分：深入解决数据同步延迟问题
在生产环境中，主从延迟（Replication Lag）是常见问题。如果从库落后主库太多，会导致读取的数据不是最新的，甚至在故障切换时丢失大量数据。
5.1 监控延迟的 SQL 查询
除了
pg_stat_replication
，我们可以通过计算 LSN 差值来精确量化延迟：
在
主节点
上执行：
SELECT
client_addr,
pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn)) as lag_size,
write_lag,
flush_lag,
replay_lag
FROM pg_stat_replication;
lag_size
: 显示从库落后了多少字节的数据。
*_lag
: 显示网络延迟、磁盘写入延迟等时间统计。
5.2 导致延迟的常见原因及解决方案
原因 1：从库硬件性能差或 I/O 瓶颈
如果主库写入很快，但从库磁盘写入慢，会导致重放（Replay）速度跟不上生成速度。
解决方案
：
确保从库的磁盘性能不低于主库（建议使用 SSD）。
检查从库的
io_wait
指标。
原因 2：大事务（Large Transactions）
在主库执行一个删除千万行数据的
DELETE
语句，或者加载大量数据。这会产生巨大的 WAL 日志。从库在重放时，必须先将这些日志写入磁盘，然后在事务结束时统一提交。这会导致从库在该事务结束前看起来没有任何进度。
解决方案
：
拆分事务
：将大事务拆分为多个小事务。
错误示范
：
DELETE FROM logs WHERE date < '2023-01-01';
(删除几亿行)
正确示范
：使用循环分批删除。
# Python 伪代码示例
while True:
result = cur.execute("DELETE FROM logs WHERE id IN (SELECT id FROM logs WHERE date < '2023-01-01' LIMIT 10000)")
if result.rowcount == 0: break
conn.commit()
原因 3：从库执行了长查询
虽然从库是只读的，但如果在从库上运行了复杂的分析查询（长事务），会阻塞 WAL 日志的重放进程（Startup Process），导致延迟飙升。
解决方案
：
将分析查询路由到专门的只读副本或使用只读事务。
监控
pg_stat_activity
，杀掉长时间运行的查询。
原因 4：网络带宽不足
主从之间传输大量数据导致网络拥塞。
解决方案
：
增加带宽。
启用压缩（虽然PG流复制本身不支持压缩，但可以使用SSH隧道压缩或硬件层压缩）。
第六部分：故障切换 (Failover) 实战
当主库发生宕机时，我们需要将从库提升为主库。这里有两种方式：手动切换和自动切换。
6.1 手动故障切换 (Manual Failover)
假设主库
192.168.1.100
彻底宕机，无法恢复。
步骤 1：确认主库确实无法恢复
如果主库只是重启，不要执行此操作，否则会导致脑裂（Split-brain）。
步骤 2：将从库提升为主库
在
从节点
上执行：
# 方法 A：使用 pg_ctl (推荐)
sudo -u postgres pg_ctl promote -D /var/lib/pgsql/14/data/
# 方法 B：创建触发器文件 (旧方法，但也有效)
# sudo -u postgres touch /var/lib/pgsql/14/data/recovery.signal
# 实际上 pg_ctl promote 会自动处理这些
步骤 3：验证提升状态
在从库（现在的新主库）上执行：
SELECT pg_is_in_recovery();
-- 返回 f (false)，表示已结束恢复模式，成为主库
步骤 4：修改应用连接
修改应用程序的连接配置，将 IP 指向新的主库
192.168.1.101
。
6.2 自动故障切换：使用 Patroni + etcd + HAProxy
手动切换在深夜是不可接受的。生产环境通常使用集群管理工具。目前最流行的方案是
Patroni
。
Patroni 架构简述
：
Patroni
: 一个 Python 编写的守护进程，运行在每个数据库节点上，负责管理 PostgreSQL 实例（启动、停止、配置）。
etcd/Consul/ZooKeeper
: 分布式键值存储，用于存储集群状态和选举 Leader。
HAProxy
: 提供统一的 VIP（虚拟 IP）或端口，应用连接 HAProxy，HAProxy 根据 Patroni 的状态将流量路由到当前的 Master 节点。
配置流程概览 (高阶)
：
部署 etcd 集群
(3节点)。
在 DB 节点安装 Patroni
。
配置 Patroni YAML
(
patroni.yml
)：
scope: pg-cluster-01
name: pg-node-01 # 每个节点名字不同
restapi:
listen: 0.0.0.0:8008
connect_address: 192.168.1.100:8008
etcd:
host: 192.168.1.200:2379
bootstrap:
dcs:
ttl: 30
loop_wait: 10
retry_timeout: 10
maximum_lag_on_failover: 1048576 # 1MB 延迟阈值
postgresql:
use_pg_rewind: true
parameters:
wal_level: replica
max_wal_senders: 10
max_replication_slots: 10
initdb:
- encoding: UTF8
- data-checksums
pg_hba:
- host replication replicator 0.0.0.0/0 md5
- host all all 0.0.0.0/0 md5
postgresql:
listen: 0.0.0.0:5432
connect_address: 192.168.1.100:5432
data_dir: /var/lib/pgsql/14/data
pgpass: /tmp/pgpass
authentication:
replication:
username: replicator
password: StrongPassword123!
superuser:
username: postgres
password: SuperSecret123!
parameters:
unix_socket_directories: '.'
tags:
nofailover: false
noloadbalance: false
clonefrom: false
nosync: false
启动 Patroni
：
patroni patroni.yml
Patroni 会自动初始化集群或加入现有集群。如果主库挂掉，Patroni 会利用 etcd 的选举机制自动将某个从库提升为 Master，并利用
pg_rewind
将旧主库重新变为从库加入集群。
第七部分：最佳实践与总结
7.1 生产环境配置清单
监控
：
必须监控
pg_stat_replication
中的
lag_size
。
设置告警：当延迟超过 10MB 或 30秒时触发告警。
网络
：
主从节点必须在同一个低延迟的局域网内。
建议使用千兆或万兆网络。
安全
：
建议在
pg_hba.conf
中限制具体的 IP 地址。
如果网络环境不安全，考虑使用 SSL 加密流复制（在
postgresql.conf
中配置
ssl = on
）。
维护
：
定期在从库上运行
VACUUM
和
ANALYZE
，因为从库也会产生死元组（虽然主库同步过来的清理操作也会同步，但主动维护有助于性能）。
定期测试故障切换流程。
7.2 总结
通过以上步骤，你已经成功搭建了一个具备基本高可用能力的 PostgreSQL 主从集群。
关键回顾
：
WAL 是核心
：理解 WAL 的传输和重放是掌握复制的关键。
pg_basebackup 是利器
：它是初始化从库的标准方式。
延迟是敌人
：通过拆分大事务和优化硬件来对抗延迟。
自动化是未来
：手动切换仅适用于紧急情况，Patroni 等工具才是生产环境的标准配置。
遵循本指南，你不仅能搭建出集群，更能深入理解其运行机制，从而在面对数据同步延迟和故障切换难题时游刃有余。