做数据库的人，十有八九都遇到过这种场景：业务要拆分，数据要迁移，或者只想搭个只读报表库，核心要求一句话——把 PostgreSQL（PG）里的数据复制到另一个库去。听起来简单，真动手时坑比想象的多。有人图省事直接用 pgdump 导出再导入，结果数据量一大，跑个通宵也完不了；有人用第三方工具拼凑，结果同步延迟高得离谱，业务方天天骂。其实 PG 自身就带了好几套方案，关键是选对路子。今天咱就掰扯掰扯这些方案，看看哪种适合你的场景。
先说物理复制吧。这是 PG 从 9.0 开始就有的原生能力，本质上是通过 WAL 日志把主库的变更实时同步到从库，延迟通常控制在毫秒级。好处是几乎零侵入，主库照常工作，从库只管接收日志回放。但有个硬性限制：主从库的版本必须一致，而且从库是只读的，不能写东西。如果你只是想要个热备库，或者分担读压力，这方案最省心。举个例子，我见过一家电商公司，每天几百万订单写入主库，报表查询全走从库，就这么跑了两年没出过事儿。不过要注意，网络抖动导致 WAL 堆积时，从库会追不上，必须提前做好监控。
如果业务要求两个库都能写，或者需要跨版本复制，就得靠逻辑复制了。PG 10 引入了内置的逻辑复制机制，原理是把数据变更解析成逻辑流，再通过网络传到目标库去应用。这个方案灵活得多：可以只复制某几张表，甚至指定复制哪些行；源库和目标库的版本可以不一样，比如从 PG 12 复制到 PG 14 也没问题。我见过一家金融公司做数据中台，就是用逻辑复制把交易库的部分表实时同步到分析库，两边互不影响。但代价是会增加源库的 CPU 和内存开销，因为要额外解码 WAL。而且如果表结构改了（比如新增字段），需要手动处理订阅端，否则容易断流。
说到跨库复制，很多人第一反应是用 ETL 工具，比如 Debezium 加 Kafka。这其实是把 PG 的逻辑解码能力外包出去。Debezium 监听 PG 的 WAL，捕获变更事件后投到 Kafka，下游消费者再写入目标库。好处是解耦，数据流可以复用，比如同时推给多个库，或者在中间做清洗加工。但问题是架构变重，维护成本高。我有个朋友在创业公司搞大数据平台，一开始图新鲜上了这套，结果 Kafka 集群天天调优，PG 的复制槽还动不动就撑爆磁盘，最后老老实实换回了 PG 自带的逻辑复制。所以除非你的场景真的需要多路分发或流处理，否则别给自己找麻烦。
还有一种经典方案，是基于触发器的同步。你在源库的每张表上建触发器，每次增删改都记录到一张日志表里，然后写脚本定期把日志表的数据推送到目标库。这办法在 PG 9 之前很流行，因为那时还没有内置复制。现在看，它最大的问题是性能损耗大——每笔事务都要额外写一条日志，相当于把同步压力转嫁到业务写入路径上。而且触发器逻辑复杂，容易出 bug，比如更新操作没处理好会导致目标库数据错乱。不过有个场景它倒是合适：只需要同步部分字段，或者要做字段级别的映射，逻辑复制不支持这种细粒度控制，触发器能搞定。
说到这儿，得提一下很多 PG 运维人员容易踩的坑——用 pgdump 做增量同步。有人觉得每天跑一次全量导出导入，数据量不大就能凑合。但 pgdump 本质上是快照工具，会锁表，生成的文件也大。对于几百 GB 的库，光传输就得好几个小时。更致命的是，业务是 7×24 小时运行时，导出期间的新数据会丢失。我见过一个悲剧案例：某公司用 pgdump 把生产库同步到测试库，导出过程中生产库挂了，恢复时才发现漏了半小时的变更，只能重跑。所以 pgdump 只适合一次性迁移或小数据量的初始化，别当成同步工具。
如果对实时性要求不高，比如每天凌晨同步一次，就可以考虑物化视图或 pgdump 加定时任务。物化视图能定期刷新，把查询结果存成本地表，适合报表类只读场景。但它是全量刷新，数据量大时会压垮磁盘 I/O。PG 14 之后支持增量刷新，不过限制很多，比如不能有聚合函数。另一种取巧的办法是使用 PostgreSQL 的外表功能（FDW），在目标库建一个外部表指向源库，然后通过 INSERT INTO … SELECT 拉数据。这个办法灵活，可以写复杂的 SQL 做转换，但性能差，因为每次查询都要跨库传输数据，适合小批量搬运。
如果你在云上，比如使用 RDS for PostgreSQL 或 Aurora，情况又不一样。云厂商通常提供托管复制方案，例如 AWS 的 DMS（数据库迁移服务），能直接帮你做全量加增量同步，支持跨区域、跨版本，甚至跨数据库类型（比如从 MySQL 到 PG）。但要注意收费和延迟问题。DMS 本质上是跑在 EC2 上的复制进程，如果实例规格配小了，同步速度会慢得让人抓狂。我有个客户用 DMS 把 PG 同步到 Redshift，结果每天要同步几十亿条记录，DMS 实例只有 4 核 16 GB，延迟超过 10 分钟，后来换成 8 核 32 GB 才压到 30 秒以内。所以云方案省了运维，但得舍得花钱买性能。
总结一下，没有万能方案，关键看你的场景。要简单稳定，物理复制最省心；要灵活跨版本，逻辑复制是首选；要做数据清洗或多路分发，再考虑 Debezium 加 Kafka；如果只是小批量定时同步，FDW 或物化视图也能凑合。千万别图省事用 pg_dump 做增量，也别盲目上重架构把自己累死。记住一条原则：能少一个中间件就别多一个，能原生解决就别外包。PG 的生态已经足够成熟，跨库复制这件事，选对方案比折腾工具更重要。
