PostgreSQL 复制实战从流复制、逻辑复制到故障转移的完整指南【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills导读本文以 claude-skills 仓库中 Postgres Pro 技能 的复制主题参考文档 references/replication.md 为主体系统讲解 PostgreSQL 复制体系——从物理流复制的搭建、同步提交策略到逻辑复制、级联与延迟复制、故障转移高可用方案再到基于 WAL 归档的备份与时间点恢复PITR。读完本文你将掌握一套可直接落地的主从复制部署命令、监控与告警 SQL、故障排查步骤并理解各方案背后的数据一致性与可用性取舍。该文档是仓库 67 个专用技能之一 postgres-proPostgreSQL 专家技能的核心参考适用于数据库管理员与后端工程师在生产环境构建读写分离与高可用架构。一、PostgreSQL 复制体系总览PostgreSQL 的复制能力分为两大类两者都建立在预写日志WAL机制之上但在实现粒度与适用场景上截然不同维度物理流复制Streaming Replication逻辑复制Logical Replication复制单位整个实例的 WAL块级物理变更行级数据变更INSERT/UPDATE/DELETE粒度整实例复制可指定表、schema、行过滤器版本要求主备版本需一致主备版本可跨大版本向下兼容典型场景高可用、读写分离、热备份数据分发、部分表同步、升级迁移复制内容全部对象含 DDL、索引仅表数据的 DMLPG 15 后可含部分 DDLpostgres-pro技能的 SKILL.md 将Setup replication — Streaming or logical based on requirements; monitor lag continuously列为核心工作流的第 4 步并将Monitor replication lag viapg_stat_replication列入强制约束MUST DO。这意味着复制方案选型与持续监控是本技能处理数据库问题时的标准动作本文接下来的内容正是该流程的完整实操展开。适用版本说明本文参数与语法以 PostgreSQL 1216 为主这也是 SKILL.md 中 Knowledge Reference 声明的目标版本范围。其中wal_keep_size为 PG 13 起替代wal_keep_segments的参数FOR TABLES IN SCHEMA与WHERE行过滤器为 PG 15 特性pg_promote()函数自 PG 12 起可用。低版本环境需按官方对应参数调整。二、物理流复制Streaming Replication搭建物理流复制是 PostgreSQL 高可用的基石主库持续把 WAL 记录传输给备库备库按序重放形成与主库块级一致的数据副本。2.1 主库配置第一步编辑postgresql.conf-- postgresql.conf wal_level replica max_wal_senders 10 max_replication_slots 10 wal_keep_size 1GB # Or 1024MB for older versions hot_standby on archive_mode on archive_command cp %p /var/lib/postgresql/wal_archive/%f各参数的作用与调优要点wal_level replicaWAL 中写入足够信息以支持复制与归档是流复制的最低要求max_wal_senders允许同时存在的 WAL 发送进程上限至少应大于备库数量 基础备份连接数默认 10 对小型集群通常够用max_replication_slots复制槽上限逻辑复制与物理复制槽共用此额度wal_keep_size 1GB在主库 pg_wal 目录中保留的额外 WAL 量用于备库暂时断开后的追赶旧版本使用wal_keep_segments以段数计hot_standby on允许备库接受只读查询这是读写分离的基础对大部分工作负载建议开启archive_mode on与archive_command启用 WAL 归档与流复制互补既作为备份基础也能在备库长期掉线时补送缺失 WAL。第二步配置pg_hba.conf允许复制连接-- pg_hba.conf (allow replication connections) host replication replicator 10.0.0.0/24 scram-sha-256复制连接使用replication数据库名与普通连接分离授权。scram-sha-256是目前推荐的强认证方式PG 10 支持。第三步创建复制角色与复制槽-- Create replication user CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD secure_password; -- Create replication slot (prevents WAL deletion) SELECT * FROM pg_create_physical_replication_slot(replica_1);复制槽replication slot的作用是防止主库在备库未消费 WAL 之前就将其清理槽位记录了备库的消费位点主库会因此保留对应的 WAL。代价是如果备库长期离线主库磁盘会被持续增长且未被消费的 WAL 撑满监控中必须关注槽位保留量详见复制槽监控小节。2.2 备库搭建# Stop PostgreSQL on standby systemctl stop postgresql # Remove data directory rm -rf /var/lib/postgresql/14/main/* # Base backup from primary pg_basebackup -h primary-host -D /var/lib/postgresql/14/main \ -U replicator -P -v -R -X stream -S replica_1 # -R creates standby.signal and recovery config # -X stream: stream WAL during backup # -S replica_1: use replication slotpg_basebackup是从主库拉取一致性基础备份的标准工具参数含义-h primary-host -U replicator连接主库与复制用户-P -v显示进度与详细信息便于确认备份过程-R自动写入standby.signalPG 12 标识备库的信号文件并把恢复参数写入postgresql.auto.conf免去手工创建-X stream在备份进行期间以流式方式接收新增 WAL使备份集完整可用-S replica_1在备份过程中绑定第 2.1 节创建的主库复制槽防止备份期间 WAL 被回收。备份完成后备库的恢复配置如下-R自动生成也可以手工维护-- standby.signal file created by pg_basebackup -R -- recovery parameters in postgresql.auto.conf: primary_conninfo hostprimary-host port5432 userreplicator passwordsecure_password primary_slot_name replica_1primary_conninfo指定连接主库的信息primary_slot_name关联第 2.1 节创建的物理复制槽确保备库在长时间重放延迟或断线后仍能追赶到最新 WAL而不是依赖wal_keep_size的容量上限。生产环境强烈建议两者配合使用槽位兜底保序wal_keep_size提供短期冗余。2.3 复制状态监控在主库查看复制健康度-- On primary: Check replication status SELECT client_addr, state, sync_state, sent_lsn, write_lsn, flush_lsn, replay_lsn, pg_wal_lsn_diff(sent_lsn, replay_lsn) as lag_bytes FROM pg_stat_replication;字段解读statestreaming表示正在正常流式接收catchup表示正在追赶sync_statesync同步、async异步、potential同步候选详见同步复制一节sent_lsn / write_lsn / flush_lsn / replay_lsn分别表示 WAL 已发送、已写入备库内核、已刷新到磁盘、已重放到数据页的位点replay_lsn是备库真正对外可见数据的位置pg_wal_lsn_diff(sent_lsn, replay_lsn)主备之间的字节级滞后是判断备库落后多少最直接的口径。在备库查看重放滞后-- On standby: Check replay lag SELECT now() - pg_last_xact_replay_timestamp() AS replication_lag;该查询返回最近一次已重放事务距现在的时间间隔是时间滞后视角的度量。若备库处于空闲无新写入此值自然增长需结合 LSN 差值一起判断避免误报。检查复制槽占用-- Check replication slots SELECT slot_name, slot_type, active, restart_lsn, pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn) as retained_bytes FROM pg_replication_slots;restart_lsn是槽位允许的最早可重放位点retained_bytes表示该槽强制保留的 WAL 字节数。若某个槽长期active false且保留量持续增长说明对应备库已断开但槽位仍占着主库磁盘需要及时处理删除槽或重建备库。2.4 同步复制在性能与可靠性之间取平衡默认的流复制是异步的主库提交事务后不必等待备库确认。同步复制则让每个事务在备库确认写入/落盘/重放后才返回成功从而做到主库故障不丢已提交事务Zero Data Loss。-- postgresql.conf on primary synchronous_commit on synchronous_standby_names FIRST 1 (replica_1, replica_2) # Waits for 1 standby to confirm before commit # Options: # FIRST n (names): Wait for n standbys # ANY n (names): Wait for any n standbys # name: Wait for specific standbysynchronous_commit on事务提交时等待备库确认synchronous_standby_names FIRST 1 (replica_1, replica_2)从列表中按顺序取前 1 个备库作为同步目标。FIRST n适合固定主备拓扑ANY n适合多备库、要求更松的场景如 3 备库中任意 2 个确认也可以直接写单个备库名强制等待指定节点。确认当前谁是同步节点-- Query to check sync status SELECT application_name, sync_state, state FROM pg_stat_replication; -- sync_state: sync (synchronous), async, potential其中sync表示当前同步目标事务提交需其确认potential表示若当前同步节点失效将被提升为同步目标async为普通异步备库。权衡提醒同步复制会放大主备网络延迟对写入性能的影响——每次提交都要等待远程确认。若同步备库宕机主库会阻塞所有提交这正是保证不丢数据的代价。常见的生产策略是1 个同步备 1 个异步备或使用ANY n既获得强一致保证又保留容错余地。三、逻辑复制Logical Replication行级数据分发逻辑复制面向行级变更天然适合异构版本同步、局部数据分发、迁移与微服务解耦等场景也是跨 PostgreSQL 大版本升级的主流路径PG 11 起由内置 publish/subscribe 机制提供。3.1 发布端Publisher配置-- postgresql.conf wal_level logical max_replication_slots 10 max_wal_senders 10注意wal_level logical是逻辑复制的前提它的 WAL 信息量大于replica。修改后需要重启实例才能生效。创建发布Publication的四种方式-- Create publication (all tables) CREATE PUBLICATION my_publication FOR ALL TABLES; -- Or specific tables CREATE PUBLICATION my_publication FOR TABLE users, orders; -- Or tables matching pattern (PG15) CREATE PUBLICATION my_publication FOR TABLES IN SCHEMA public; -- With row filters (PG15) CREATE PUBLICATION active_users FOR TABLE users WHERE (active true);FOR ALL TABLES复制全库所有表最简单但未来新增表也会被自动纳入FOR TABLE ...精确控制复制的表清单适合只同步核心业务表的场景FOR TABLES IN SCHEMA publicPG 15按 schema 批量纳入兼顾控制力与扩展性WHERE行过滤器PG 15只发布满足条件的行适合仅同步活跃用户这类数据子集需求。查看发布定义-- View publications SELECT * FROM pg_publication; SELECT * FROM pg_publication_tables;3.2 订阅端Subscriber配置-- Create subscription (creates replication slot on publisher) CREATE SUBSCRIPTION my_subscription CONNECTION hostpublisher-host port5432 dbnamemydb userreplicator passwordpass PUBLICATION my_publication;创建订阅的完整选项-- Subscription options CREATE SUBSCRIPTION my_subscription CONNECTION hostpublisher-host dbnamemydb userreplicator PUBLICATION my_publication WITH ( copy_data true, -- Initial data copy create_slot true, -- Create replication slot enabled true, -- Start immediately slot_name my_sub_slot, synchronous_commit off -- Performance vs durability );copy_data true订阅创建时先执行一次初始全量数据拷贝表结构需预先在订阅端建好create_slot true在发布端自动创建逻辑复制槽可指定slot_name手动命名便于管理enabled true创建后立即启动复制synchronous_commit订阅端的提交级联控制off提升性能订阅端允许落后追求订阅端数据即时可用时可调高。订阅管理命令-- View subscriptions SELECT * FROM pg_subscription; SELECT * FROM pg_stat_subscription; -- Manage subscription ALTER SUBSCRIPTION my_subscription DISABLE; ALTER SUBSCRIPTION my_subscription ENABLE; ALTER SUBSCRIPTION my_subscription REFRESH PUBLICATION; DROP SUBSCRIPTION my_subscription;REFRESH PUBLICATION用于在发布端表清单变化后同步订阅端的复制关系重新扫描发布端表的元数据DROP SUBSCRIPTION会默认清理发布端对应的逻辑复制槽。3.3 逻辑复制监控发布端查看逻辑复制槽的消费进度-- On publisher: Check replication slots SELECT slot_name, plugin, slot_type, active, pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn) as lag_bytes FROM pg_replication_slots WHERE slot_type logical;逻辑复制使用confirmed_flush_lsn订阅端已确认消费并落盘的位点而非物理复制槽的restart_lsn来衡量进度plugin字段通常为pgoutput内置输出插件。同样需要警惕订阅端长期离线导致 WAL 积压。订阅端查看订阅接收状态-- On subscriber: Check subscription status SELECT subname, pid, received_lsn, latest_end_lsn, last_msg_send_time, last_msg_receipt_time, latest_end_time FROM pg_stat_subscription;received_lsn订阅端已接收的 LSNlatest_end_lsn订阅端期望的下一接收位点last_msg_send_time发布端最近一次发送消息的时间last_msg_receipt_time订阅端最近一次确认接收的时间。两者差距拉大说明网络或应用层消费出现瓶颈。四、级联复制Cascading Replication级联复制允许备库再充当其他备库的上游形成链式拓扑减少主库直接承载的 WAL 发送压力适合多机房、多备库的大规模场景。Primary - Standby1 - Standby2-- On Standby1 (acts as relay) -- postgresql.conf hot_standby on max_wal_senders 10 wal_keep_size 1GB -- Standby2 connects to Standby1 -- Same setup as regular standby, but primary_conninfo points to Standby1 primary_conninfo hoststandby1-host userreplicator...要点充当转发节点的 Standby1 必须开启hot_standby并配置max_wal_senders它需要向 Standby2 发送 WAL同时最好设置wal_keep_size或复制槽以兜底下游追赶Standby2 的搭建流程与普通备库完全一致唯一区别是primary_conninfo指向 Standby1 而不是主库注意数据延迟会沿链路累积Standby2 的重放位点天然落后于 Standby1监控滞后时需分别按链路层级评估。五、延迟复制Delayed Standby延迟备库通过人为延迟重放为数据误删、错误批量更新等事故保留一扇后悔之窗。-- On standby: postgresql.conf recovery_min_apply_delay 4h -- Useful for: -- - Protection against accidental data deletion -- - Rolling back to specific point in time -- - Can promote delayed standby to recover dropped tablerecovery_min_apply_delay 4h备库收到 WAL 后延迟 4 小时再重放典型用途主库发生误删或错误更新时延迟备库中仍保留事故前 4 小时内的完整数据可将其提升promote为临时主库导出被误删的表后回灌注意该参数只延迟重放不延迟接收——WAL 仍会持续传输因此延迟备库需要与普通备库相同的网络与磁盘带宽。检查当前实际延迟量-- Check delay SELECT now() - pg_last_xact_replay_timestamp() AS current_delay;六、故障转移与提升Failover Promotion当主库不可用时需要把某个备库提升为新主库。提升后旧主库应降级为备库或被隔离拓扑即完成切换。6.1 手工故障转移# On standby server # Promote standby to primary pg_ctl promote -D /var/lib/postgresql/14/main # Or use SQL SELECT pg_promote();验证提升结果-- Verify promotion SELECT pg_is_in_recovery(); -- Should return falsepg_is_in_recovery()返回false表示已脱离恢复模式成为主库。手工提升的缺点是 RTO 依赖人工响应且提升后如何让原主库安全回归需要额外编排如使用pg_rewind让旧主追平新主。6.2 自动故障转移pg_auto_failoverpg_auto_failoverCitus 团队开源通过独立的 monitor 节点仲裁自动完成主备提升与回归# Install pg_auto_failover apt-get install pg-auto-failover # Setup monitor node pg_autoctl create monitor --hostname monitor-host --pgdata /var/lib/monitor # Setup primary pg_autoctl create postgres \ --hostname primary-host \ --pgdata /var/lib/postgresql/14/main \ --monitor postgres://monitor-host/pg_auto_failover # Setup standby pg_autoctl create postgres \ --hostname standby-host \ --pgdata /var/lib/postgresql/14/main \ --monitor postgres://monitor-host/pg_auto_failover # Check status pg_autoctl show state工作原理所有节点向 monitor 汇报心跳与状态monitor 基于多数派决策维护当前主库身份当主库失联超过阈值时monitor 选择数据最新的备库提升旧主恢复后以pg_rewind方式自动重新加入集群。6.3 Patroni生产级 HA 方案Patroni 是生产环境更主流的 HA 管理层它依赖分布式配置存储etcd / Consul / ZooKeeper做选主仲裁并通过 REST API默认 8008 端口对外暴露集群状态可配合 HAProxy 自动摘除故障节点。# patroni.yml scope: postgres-cluster name: node1 restapi: listen: 0.0.0.0:8008 connect_address: node1:8008 etcd: hosts: etcd1:2379,etcd2:2379,etcd3:2379 bootstrap: dcs: ttl: 30 loop_wait: 10 retry_timeout: 10 maximum_lag_on_failover: 1048576 postgresql: use_pg_rewind: true parameters: max_connections: 100 max_wal_senders: 10 wal_level: replica postgresql: listen: 0.0.0.0:5432 connect_address: node1:5432 data_dir: /var/lib/postgresql/14/main authentication: replication: username: replicator password: repl_password superuser: username: postgres password: postgres_password关键配置含义scope/name集群标识与节点名etcd 中的所有节点必须使用相同scopeetcd.hosts配置存储集群地址选主与元数据存储依赖它bootstrap.dcs.ttl 30leader 租约 TTL秒节点失联超过 TTL 即触发重新选举loop_wait 10与retry_timeout 10Patroni 主循环间隔与单次操作超时maximum_lag_on_failover允许被提升备库的最大 WAL 滞后字节数这里 1048576 即 1MB避免提升一个落后过多的节点丢失太多数据use_pg_rewind: true故障切换后旧主回归时用pg_rewind对齐新主避免全量重建bootstrap.dcs.postgresql.parameters由 Patroni 统一下发的 PostgreSQL 参数保证集群内配置一致postgresql.authenticationreplication 与 superuser 两套认证凭据。七、高可用下的连接池与负载均衡7.1 PgBouncer事务级连接池数据库连接是昂贵的资源PgBouncer 通过复用连接显著降低并发开销这也是 SKILL.md 中Use connection pooling (pgBouncer, pgPool)的强制项。# pgbouncer.ini [databases] mydb hostprimary-host port5432 dbnamemydb [pgbouncer] listen_addr * listen_port 6432 auth_type scram-sha-256 auth_file /etc/pgbouncer/userlist.txt pool_mode transaction max_client_conn 1000 default_pool_size 25 reserve_pool_size 5[databases]把应用访问的逻辑库名映射到真实 PostgreSQL 节点pool_mode transaction事务级复用应用事务结束后连接即归还池中是高并发 Web 场景的推荐模式max_client_conn 1000PgBouncer 可接纳的最大客户端连接数default_pool_size 25每个数据库到后端的常规连接数reserve_pool_size 5高峰期可临时启用的额外连接数形成弹性缓冲。7.2 HAProxy负载均衡与自动摘除HAProxy 以 TCP 四层代理将客户端流量分发到集群节点并利用 PostgreSQL 的pg_is_in_recovery健康检查自动区分主备# haproxy.cfg frontend postgres_frontend bind *:5432 mode tcp default_backend postgres_backend backend postgres_backend mode tcp option tcp-check tcp-check expect string is_master:true server primary primary-host:5432 check server standby1 standby1-host:5432 check backup server standby2 standby2-host:5432 check backuptcp-check expect string is_master:true执行SELECT pg_is_in_recovery()并期望返回false只有当前主库通过健康检查server ... check标记为可参与负载均衡的节点backup标记的备库仅在主库不可用时才被启用当 Patroni 或 pg_auto_failover 完成切换后HAProxy 的检查会自动把流量导向新主库实现读写入口的自动化收敛。八、备份与时间点恢复PITR复制不是备份误删、逻辑损坏、多节点同时故障等场景仍依赖可靠的备份体系。最佳实践是复制 WAL 归档双保险。8.1 WAL 归档配置-- postgresql.conf wal_level replica archive_mode on archive_command test ! -f /backup/wal/%f cp %p /backup/wal/%f archive_timeout 300 # Force archive every 5 minutes -- Or use pg_archivecleanup archive_command pgbackrest --stanzamain archive-push %parchive_command在每次 WAL 段切换后执行%p为源 WAL 路径%f为文件名test ! -f防止重复归档同名文件archive_timeout 300即使低写入负载也每 5 分钟强制切换一次 WAL保证归档时间线的连续性PITR 目标时间的精度即受此影响生产环境更推荐专用工具归档如示例中的 pgBackRest自带校验、压缩与并行传输。8.2 使用 pg_basebackup 做基础备份# Full backup pg_basebackup -h localhost -U postgres \ -D /backup/base/$(date %Y%m%d) \ -Ft -z -P -X fetch # -Ft: tar format # -z: gzip compression # -P: progress # -X fetch: include WAL files-Ft -z以 tar 格式输出并 gzip 压缩适合统一备份目录归档-X fetch把备份过程中产生的 WAL 一并纳入备份集保证基础备份的一致性。8.3 时间点恢复PITR完整流程# Stop PostgreSQL systemctl stop postgresql # Restore base backup rm -rf /var/lib/postgresql/14/main/* tar -xzf /backup/base/20241201/base.tar.gz -C /var/lib/postgresql/14/main # Create recovery.signal touch /var/lib/postgresql/14/main/recovery.signal # Configure recovery # postgresql.conf or postgresql.auto.conf: restore_command cp /backup/wal/%f %p recovery_target_time 2024-12-01 14:30:00 # Or: recovery_target_xid, recovery_target_name, recovery_target_lsn # Start PostgreSQL (will recover to target) systemctl start postgresql # After recovery, check SELECT pg_is_in_recovery(); # Should be false after recovery completesrecovery.signalPG 12 标识实例进入恢复模式的信号文件PG 12 前为recovery.confrestore_command从 WAL 归档目录按序取回 WAL 段恢复目标可指定时间recovery_target_time、事务 IDrecovery_target_xid、还原点recovery_target_name或 LSNrecovery_target_lsn恢复完成后pg_is_in_recovery()返回false且该实例此后应作为独立节点使用恢复目标时间线已与生产分叉。归档频率与archive_timeout、备份频率共同决定了 RPO最多丢失数据量恢复演练则应定期进行——这也是 maintenance.md 中维护清单Quarterly: Test backup restoration的要求。九、复制监控最佳实践将常用监控查询固化为视图是持续观察复制健康度的标准做法-- Create monitoring view CREATE VIEW replication_status AS SELECT client_addr, application_name, state, sync_state, pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) / 1024 / 1024 AS lag_mb, (pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn)::float / (1024 * 1024 * 16))::int AS estimated_wal_segments_behind FROM pg_stat_replication; -- Alert if lag 100MB SELECT * FROM replication_status WHERE lag_mb 100; -- Check replication slot disk usage SELECT slot_name, pg_size_pretty( pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn) ) as retained_wal FROM pg_replication_slots;要点视图把 LSN 差值换算为直观的lag_mb并估算落后的 WAL 段数按默认 16MB 段大小推算可直接对接告警系统lag_mb 100可作为初始告警阈值生产环境中按业务容忍度与网络质量进一步校准复制槽磁盘占用必须纳入常规巡检槽位保留的 WAL 若不清理可能耗尽主库磁盘。这与 maintenance.md 中Daily: Verify replication lag (if applicable)的维护清单相互印证复制监控本就是数据库日常维护的一环。十、故障排查复制中断与备库滞后10.1 复制中断的排查步骤-- Replication broken? -- 1. Check pg_stat_replication on primary SELECT * FROM pg_stat_replication; -- 2. Check logs on standby -- tail -f /var/log/postgresql/postgresql-14-main.log -- 3. Check replication slot exists SELECT * FROM pg_replication_slots WHERE slot_name replica_1; -- 4. Recreate slot if missing SELECT pg_create_physical_replication_slot(replica_1); -- 5. Check WAL files available -- ls -lh /var/lib/postgresql/14/main/pg_wal/排查路径先在主库确认备库是否仍处于streaming状态再看备库日志获取具体的连接失败原因认证、网络、磁盘满等随后核对复制槽是否存在——若槽位丢失例如被误删备库重连后将无法确定消费位点最后确认主库pg_wal/中是否还保留着备库所需的 WAL 段否则即使重连也会因缺段而失败。10.2 备库严重滞后的三种处置-- Standby too far behind? -- Option 1: Increase wal_keep_size -- Option 2: Use replication slots -- Option 3: Re-run pg_basebackup增大wal_keep_size给备库更多的追赶缓冲窗口适合滞后时间不长的场景使用复制槽从根本上保证主库不提前回收 WAL但需配套槽位保留量监控防止主库磁盘被撑爆重新执行pg_basebackup滞后过大主库 WAL 已被回收、槽位丢失时重建备库通常比尝试追赶更快更可靠。日常运维中应遵循 SKILL.md 的约束——Ignore replication lag alerts属于 MUST NOT DO滞后告警出现后应立即介入处理。总结PostgreSQL 的复制体系覆盖了从数据冗余与读写分离物理流复制到灵活数据分发与迁移逻辑复制、再到极端场景保护延迟备库与自动故障转移Patroni / pg_auto_failover的完整需求光谱。落地时把握三个核心原则先选型再动手同版本全量高可用选物理流复制跨版本/局部同步选逻辑复制事故防护加一台延迟备库监控先行把pg_stat_replication、pg_replication_slots的滞后与 WAL 保留量监控纳入日常巡检参考 maintenance.md 的维护清单复制槽是最容易埋雷的隐性风险点复制不等于备份同步复制 PgBouncer/HAProxy 提供的是可用性WAL 归档 pg_basebackup PITR 才是可恢复性的最终保障两者缺一不可。如需进一步了解与复制配套的数据库性能调优、JSONB 使用与日常维护可继续阅读同技能下的 performance.md、jsonb.md、extensions.md 与 maintenance.md该技能的使用边界与完整工作流可参见 postgres-pro/SKILL.md。本主题属于仓库基础设施类技能之一与 database-optimizer、devops-engineer、sre-engineer 等技能配合可组成完整的数据库高可用工程方案。【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考