PostgreSQL 流復制與邏輯復制性能優化與故障切換實戰經驗分享
在高可用和數據安全愈發受到重視的生產環境中，PostgreSQL 復制技術是保障業務連續性的重要手段。本文結合真實生產場景，分享流復制（Physical Replication）與邏輯復制（Logical Replication）的架構設計、性能優化和故障切換實戰經驗。
1. 業務場景描述
- 主庫承載日均千萬級寫入請求，讀請求峰值達2000 QPS。
- 需要實時備庫做故障切換，且對主從延遲（Replication Lag）有嚴格要求（<100ms）。
- 希望在無需停機的情況下進行版本升級或跨數據中心切換。
- 同時需要對部分表或數據庫進行靈活的邏輯訂閱，以支持分庫分表后數據同步。
2. 技術選型過程
- 流復制：內置、穩定，對全庫一致性保證強，適合主從切換或流量剪切。
- 邏輯復制：基于發布/訂閱，可選擇性同步表結構變更，支持跨版本/跨架構遷移。
- 工具選型：使用官方 replication slot+pg_basebackup 搭建流復制，邏輯復制使用
CREATE PUBLICATION/CREATE SUBSCRIPTION。故障切換借助pg_ctl promote或第三方repmgr。
最終方案：主備采用流復制+同步提交（synchronous commit），跨 DC 或分庫場景使用邏輯復制。
3. 實現方案詳解
3.1 流復制部署
- 主庫配置（postgresql.conf）：
# WAL 級別
wal_level = logical # 支持邏輯復制可選 physical
max_wal_senders = 10 # 并發復制連接數
max_replication_slots = 10 # 復制槽
wal_keep_segments = 128 # 保留WAL段避免過快清理
synchronous_commit = on # 開啟同步提交
synchronous_standby_names = 'standby1' # 同步備庫名稱
- 主庫認證（pg_hba.conf）：
# 允許復制用戶連接
host replication replicator 192.168.1.0/24 md5
- 創建復制用戶：
CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'StrongP@ssw0rd';
- 初始化備庫：
pg_basebackup -h 主庫IP -D /data/pgsql/primary2 -U replicator -X stream -P
- 備庫配置（recovery.conf 或 postgresql.auto.conf）：
standby_mode = 'on'
primary_conninfo = 'host=主庫IP port=5432 user=replicator password=StrongP@ssw0rd'
recovery_target_timeline = 'latest'
# 可選：故障切換觸發
trigger_file = '/data/pgsql/trigger.promote'
- 啟動備庫：
pg_ctl -D /data/pgsql/primary2 start
3.2 邏輯復制部署
- 主庫開啟邏輯復制支持：
wal_level = logical
max_worker_processes = 8
max_replication_slots = 8
max_wal_senders = 8
- 創建發布：
-- 發布所有表
CREATE PUBLICATION pub_all FOR ALL TABLES;
-- 發布單表
CREATE PUBLICATION pub_user FOR TABLE public.user;
- 目標庫創建訂閱：
CREATE SUBSCRIPTION sub_all CONNECTION 'host=主庫IP port=5432 dbname=postgres user=replicator password=StrongP@ssw0rd'PUBLICATION pub_all;
- 驗證延遲：
-- 查看邏輯訂閱狀態
SELECT * FROM pg_stat_subscription;
4. 踩過的坑與解決方案
-
WAL 段過快清理導致備庫初始化失敗
- 原因：
wal_keep_segments配置過小 - 方案：適當增大
wal_keep_segments或使用archive_mode+archive_command長期保存WAL。
- 原因：
-
復制槽堆積導致磁盤占滿
- 原因：邏輯復制槽未及時消費
- 方案：定期監控
pg_replication_slots，必要時手動清理或調整max_replication_slots。
-
主從切換后客戶端連接抖動
- 原因：應用側未配置連接重試和讀寫分離
- 方案：使用 PgBouncer 或 HAProxy 實現健康檢查和自動路由。
-
版本升級時邏輯復制不兼容
- 原因：跨主次版本時 WAL 格式或目錄結構變化
- 方案：升級前先測試 publication/subscription 兼容性，必要時使用雙寫中間件平滑切換。
-
同步提交性能瓶頸
- 原因：synchronous_commit 阻塞主庫寫入
- 方案：僅對關鍵庫開啟同步提交，其他只用異步模式；或者使用半同步模式(
remote_write)。
5. 總結與最佳實踐
- 對業務關鍵表使用流復制+同步模式，保障零數據丟失。
- 對靈活拆庫、跨 DC 場景使用邏輯復制，按需訂閱表。
- 生產環境中要覆蓋 WAL 歸檔、復制槽監控、連接池與中間件容災。
- 灰度或測試環境定期演練故障切換，驗證
pg_ctl promote和連接重試策略。 - 持續關注
pg_stat_replication、pg_stat_subscription延遲指標，自動告警。
通過以上實戰經驗的分享，希望幫助后端開發及 DBA 在高并發場景下，結合業務需求選擇合適的 PostgreSQL 復制方案，并在性能優化與故障切換實踐中少走彎路。
