一、流复制机制概述与扩容必要性
PostgreSQL的流复制（Streaming Replication）就像数据库世界的"实时复印机"，主库（Master）持续发送WAL日志给从库（Standby）。这个过程中的传输延迟通常控制在毫秒级，特别适合需要读写分离的热备场景。
真实的扩容需求通常出现在以下几种情况：
- 大促期间数据库QPS突破原有从库处理能力
- 报表系统等OLAP业务需要独立副本避免影响交易
- 分区域部署从库满足地域性访问需求
- 逐步替换老旧硬件时的滚动升级
# 查看当前复制状态（主库执行）
SELECT client_addr, state, sync_priority, sync_state
FROM pg_stat_replication;
二、在线扩容完整操作流程
2.1 环境准备（以PostgreSQL 16为例）
主库IP：192.168.1.100 新从库IP：192.168.1.101 操作系统：Ubuntu 22.04 LTS 归档存储路径：/archive_wal
2.2 主库配置调整
# postgresql.conf核心配置
wal_level = replica # 保证足够的信息量用于复制
max_wal_senders = 10 # 允许最多10个复制连接
wal_keep_size = 16384 # 保留至少16GB的WAL日志
# pg_hba.conf添加复制权限
host replication replica 192.168.1.101/32 scram-sha-256
关键要点说明：
- wal_keep_size需要根据业务写入量调整，防止新从库追赶时缺失日志
- 若使用复制槽（Replication Slot）则可不依赖wal_keep_size
- 每次修改配置后都要
pg_ctl reload
2.3 从库基础环境搭建
# 操作系统层面优化
sudo sysctl -w shmmax=17179869184 # 内存分配调优
sudo mkfs.xfs /dev/sdb -f # 推荐独立分区存储数据
# 同步时区设置（必须与主库一致）
sudo timedatectl set-timezone Asia/Shanghai
2.4 物理复制完整示例
# 从库执行（建议使用专用复制账号）
pg_basebackup -h 192.168.1.100 -U replica \
-D /var/lib/postgresql/16/main \
--checkpoint=fast \
--wal-method=stream \
--progress \
--verbose
参数解析：
--checkpoint=fast加快备份启动速度--wal-method=stream实时传输WAL避免中断-D指定数据存放路径需与PGDATA一致
2.5 启动复制进程
# recovery.conf配置（重要！）
standby_mode = 'on'
primary_conninfo = 'host=192.168.1.100 port=5432 user=replica password=xxxxxx'
restore_command = 'cp /archive_wal/%f %p'
recovery_target_timeline = 'latest'
启动服务后的验证方法：
-- 查看恢复状态
SELECT pg_is_in_recovery();
-- 检查复制延迟
SELECT now() - pg_last_xact_replay_timestamp() AS replication_delay;
三、关联技术与高级配置
3.1 同步复制与异步复制的选择
-- 修改主库为同步复制模式
ALTER SYSTEM SET synchronous_standby_names = 'standby1';
SELECT pg_reload_conf();
注意要点：
- 同步复制需要设置合理的超时参数
synchronous_commit - 多级从库架构中谨慎使用同步配置
3.2 复制槽管理实战
-- 创建物理复制槽
SELECT * FROM pg_create_physical_replication_slot('node2_slot');
-- 重要监控SQL
SELECT slot_name, active, wal_status
FROM pg_replication_slots;
运维经验：
- 长期不清理的复制槽可能导致存储爆炸
- 建议设置max_slot_wal_keep_size
3.3 级联复制配置要点
从库的从库需要特别注意：
hot_standby = on
wal_level = replica
max_wal_senders = 3
四、生产环境验证方案
4.1 全量数据校验
-- 使用pg_checksums进行块校验
pg_checksums --enable --progress -D /data/pgdata
4.2 压力测试方案
# 使用pgbench生成测试负载
pgbench -c 100 -j 8 -T 600 postgres
4.3 容灾切换演练
# 主库故障时手动切换
pg_ctl promote -D /path/to/standby/data
五、应用场景深度分析
- 金融系统读写分离：查询请求全路由到从库
- 实时数仓构建：使用逻辑复制筛选特定表
- 多地多活架构：跨区域部署级联从库
- 灰度发布支持：新版本先在从库验证
六、技术方案优缺点
✅ 优点：
- 秒级RPO（恢复点目标）
- 支持级联扩展
- 无需第三方工具
- 配置灵活可控
⛔️ 缺点：
- 表级复制需要额外配置
- DDL操作无法过滤
- 大事务可能导致延迟
七、运维注意事项
- WAL日志存储必须充足
- 定期检查replication slots状态
- 主从版本必须严格一致
- 网络带宽要预留余量
- 归档策略与备份方案协同
八、经验总结与展望
通过本文的完整流程实践，我们可以实现数据库水平扩展从小时级缩短到分钟级。未来可结合Patroni等管理工具实现自动故障切换，并通过逻辑解码实现更灵活的数据订阅。
评论