PostgreSQL 原理图解 · 复制与高可用

同步复制：五个档位，不是一个开关

MySQL 的半同步是一个插件，PG 的同步是 synchronous_commit 的五个取值——它决定的是「主库什么时候才告诉客户端提交成功」，不是一个「开/关」。

怎么指定「必须等几个备库」

# 等 1 个备库确认即可（性能优先）
synchronous_standby_names = '1 (standby1, standby2)'

# 等 2 个里全部确认（金融级）
synchronous_standby_names = '2 (standby1, standby2)'

# 按应用名，支持 quorum（PG 9.6+）
synchronous_standby_names = 'FIRST 2 (s1, s2, s3)'   -- 前 2 个可达的
synchronous_standby_names = 'ANY 2 (s1, s2, s3)'     -- 任意 2 个

复制槽：保命的机制，也是撑爆磁盘的元凶

WAL 段文件会被循环回收——「这个位置之前的所有备库都确认收到了」。可如果备库掉线很久，主库凭什么知道它还没收到？复制槽就是主库给每个备库记的一个书签：这个位置之前的 WAL 一律不许删。

两种槽，用途完全不同

三个必须进监控的指标

-- 1. 每个槽卡住了多少 WAL（超过几十 GB 就该报警）
SELECT slot_name, active,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained_wal,
       age(xmin) AS xmin_age, age(catalog_xmin) AS catalog_age
FROM pg_replication_slots ORDER BY 3 DESC NULLS LAST;

-- 2. pg_wal 目录多大（这个涨起来就是磁盘告警）
SELECT pg_size_pretty(sum(size)) FROM pg_ls_waldir();

-- 3. 备库到底跟到哪了
SELECT client_addr, state, sync_state,
       write_lag, flush_lag, replay_lag
FROM pg_stat_replication;

逻辑复制：什么时候必须用它

物理复制是「整实例照抄」，逻辑复制是「按表解析出行变更再重放」。它慢、限制多，但只有它能做到跨版本、跨平台、只同步部分表、以及从库可写。

-- 主库
ALTER SYSTEM SET wal_level = 'logical';     -- 需要重启
CREATE PUBLICATION pub_orders FOR TABLE orders, order_items;

-- 目标库
CREATE SUBSCRIPTION sub_orders
  CONNECTION 'host=primary dbname=app user=repl'
  PUBLICATION pub_orders;

和物理复制的取舍

备份与 PITR：全备 + 无限重放 WAL

PG 的恢复模型比 MySQL 干净得多：基础备份（pg_basebackup）+ 归档的 WAL = 可以恢复到任意一个时间点。不需要「先恢复全备再算 binlog 位点」，因为 WAL 是连续的字节流，天然接得上。

# 主库：开启归档（改完 reload 即可，不用重启）
archive_mode = on
archive_command = 'pgbackrest --stanza=main archive-push %p'
wal_level = replica            -- 至少要 replica

# 做一次基础备份
pg_basebackup -h primary -D /backup/base -Ft -z -Xs -P

# 恢复：在目标实例上放一个 recovery.signal + 配置
restore_command = 'pgbackrest --stanza=main archive-get %f "%p"'
recovery_target_time = '2026-11-12 14:31:59+08'
recovery_target_action = 'promote'    -- 到了就停在那儿并变成可写

三个必须理解的行为

① 恢复点之后的数据是「被丢弃」，不是「回滚」。PG 到 recovery_target_time 就停止重放并 promote，之后的 WAL 全部不要。所以要恢复到新实例上验证，确认无误再切流量——别在原实例上直接恢复。

② recovery_target_action 默认是 pause，不是 promote。恢复完会停在只读状态等你确认。这是好事（可以检查数据），但自动化脚本里必须显式设置，否则实例一直不可写，看起来像「恢复失败」。

③ 主备切换后的分叉要靠 pg_rewind。旧主库被提升过的备库甩开了一段 WAL，直接当备库连上去会失败（时间线不一致）。pg_rewind 会把旧主库「倒带」到分叉点，再让它作为备库追上去——不需要重新做全量基础备份。

工具怎么选