PostgreSQL跨库数据同步的四种实现方案

要实现PostgreSQL数据库之间的表数据同步，无论是实时还是定时，生产环境里其实就那么几种成熟方案。每种方案都有其特定的适用场景，选对了事半功倍，选错了可能就得踩坑。今天，我们就来系统梳理一下最常用、最稳定的四种实现方式。

一、最简单：触发器 + 外部表（dblink/foreign table）

这个方案特别适合那些数据量不大、只需要同步单张表、并且对实时性要求极高的场景。它的最大好处是纯粹依赖PostgreSQL自身功能，不需要引入任何外部组件。

核心是怎么运作的呢？

原理很直观：在源库的表上创建一个触发器，每当发生增、删、改操作时，这个触发器就会被激活。触发器接着会调用一个自定义函数，这个函数通过dblink扩展建立到目标库的连接，并执行相应的SQL语句，从而将变化实时“复制”过去。

具体配置，可以分为三步走：

首先，在源数据库上启用dblink扩展：

-- 源库执行
CREATE EXTENSION IF NOT EXISTS dblink;

接着，在源库创建一个处理同步逻辑的函数：

CREATE OR REPLACE FUNCTION sync_table_func()
RETURNS TRIGGER AS $$
BEGIN
  -- 连接目标库：替换为你的目标库信息
  PERFORM dblink_connect(
    'dbname=目标库名 host=目标IP port=5432 user=账号 password=密码'
  );

  -- INSERT 同步
  IF (TG_OP = 'INSERT') THEN
    PERFORM dblink_exec(
      'INSERT INTO 目标表名 VALUES ($1.*)', NEW
    );
  -- UPDATE 同步
  ELSIF (TG_OP = 'UPDATE') THEN
    PERFORM dblink_exec(
      'UPDATE 目标表名 SET 字段1=$1,字段2=$2 WHERE id=$3',
      NEW.字段1, NEW.字段2, OLD.id
    );
  -- DELETE 同步
  ELSIF (TG_OP = 'DELETE') THEN
    PERFORM dblink_exec(
      'DELETE FROM 目标表名 WHERE id=$1', OLD.id
    );
  END IF;

  PERFORM dblink_disconnect();
  RETURN COALESCE(NEW, OLD);
END;
$$ LANGUAGE plpgsql;

最后，将这个函数绑定到需要同步的源表上：

CREATE TRIGGER trigger_sync_table
AFTER INSERT OR UPDATE OR DELETE ON 源表名
FOR EACH ROW EXECUTE FUNCTION sync_table_func();

这个方案的优点很明显：

① 纯原生，无需额外部署，学习成本几乎为零。
② 真正的实时同步，延迟极低。
③ 针对单表配置起来非常快速。

但它的局限性也需要留意：

① 在高并发或大数据量场景下，触发器本身的执行和远程调用会对源库性能产生直接影响。
② 一旦目标库出现网络问题或不可用，源库的写操作就会因触发器执行失败而报错，影响业务。
③ 不太适合需要批量操作或同步多张分表的复杂场景。

二、最常用：逻辑复制（Logical Replication）

这是PostgreSQL 10及以上版本内置的“王牌”功能，堪称生产环境的标准答案。尤其适合需要实时同步、涉及多张表、且数据量较大的情况。

它之所以成为首选，有几个硬核优势：

① 基于WAL日志解析，对源库（发布者）的读写性能影响微乎其微。
② 具备断点续传能力，即使目标库（订阅者）断开连接，重连后也能从断点继续同步，保证数据不丢失。
③ 灵活性高，可以配置同步整个数据库、多张特定表，甚至只同步表的某些列。
④ 作为官方核心功能，稳定性和可靠性经过充分验证。

配置起来其实并不复杂，主要就三步：

1、首先，需要修改源库的配置文件（postgresql.conf），开启逻辑复制所需参数：

wal_level = logical  # 这是关键，必须改为logical
max_replication_slots = 10 # 根据订阅数调整
max_wal_senders = 10       # 根据并发数调整

修改后记得重启PostgreSQL服务使配置生效。

2、在源库上，创建一个“发布”（Publication），指明要同步哪些表：

-- 创建发布（同步指定表）
CREATE PUBLICATION pub_target FOR TABLE 表1, 表2;
-- 确保使用的数据库账号有复制权限
ALTER ROLE 账号 REPLICATION;

3、最后，在目标库上创建一个“订阅”（Subscription），指向源库的发布：

-- 创建订阅，数据会自动开始同步
CREATE SUBSCRIPTION sub_source
CONNECTION 'host=源IP port=5432 dbname=源库 user=账号 password=密码'
PUBLICATION pub_target;

至此，配置完成。源表的所有数据变更都会近乎实时地同步到目标库。

三、企业级：Debezium + Kafka（CDC 方案）

当场景升级到高并发、分布式架构，或者需要让同一份数据变更被多个不同系统（如数仓、搜索、缓存）同时消费时，基于CDC（变更数据捕获）的方案就更合适了。这在微服务架构中非常常见。

它的工作原理是：

① Debezium（一个开源CDC工具）作为连接器，实时监听并解析PostgreSQL的WAL日志。
② 将捕获到的数据变更事件（插入、更新、删除）作为消息，发送到Kafka消息队列中。
③ 目标数据库或其他任何需要数据的服务，作为消费者从Kafka订阅这些消息，然后各自处理。

这种架构的优点在于：

① 实现了彻底的解耦。数据同步过程完全不影响核心业务数据库。
② 支持一对多同步，一份数据变更可以被多个下游系统消费，扩展性极强。
③ 消息队列天然具备缓冲和历史回溯能力，便于审计和重放。
④ 这是构建现代大数据平台和实时数据管道的标准组件组合。

当然，代价是复杂度：

① 部署和维护成本较高，需要管理Kafka集群和Debezium连接器。
② 对于简单的、单一目标的同步需求，有点“杀鸡用牛刀”的感觉。

四、定时同步：pg_dump + cron / pg_clogSync

并非所有场景都需要“实时”。对于数据同步延迟不敏感，比如只需要每天或每小时同步一次的报表库、备份库等，定时同步方案更简单、更省资源。

方案一：定时全量同步（最简单粗暴）

使用PostgreSQL自带的pg_dump和pg_restore工具，配合Linux的crontab定时任务。

在源库导出数据：

pg_dump -h 源IP -U 用户 -d 库 -t 表 -F c -f dumpfile

在目标库恢复数据：

pg_restore -h 目标IP -U 用户 -d 库 -t 表 dumpfile

将这两个命令写成脚本，然后用cron设置定时执行即可。

方案二：增量同步（更高效）

对于数据量大的表，每次全量同步效率低下。可以考虑使用一些开源工具（如pg_clogSync，或其他基于时间戳、逻辑解码的增量工具），只同步上次同步后发生变化的数据，速度会快很多。

方案选择建议

场景	推荐方案	难度
单表、小数据、实时	触发器 + dblink
多表、生产、实时	逻辑复制（首选）
微服务、多系统同步	Debezium + Kafka
非实时、定时同步	pg_dump 定时任务

综合来看，逻辑复制是覆盖生产环境90%场景的“万金油”选择。它的优点几乎是碾压性的：作为官方原生功能极其稳定；既能保证实时性又不丢数据；对源库性能损耗极小；配置步骤清晰，五分钟就能搭起来。

总结

最后，给一个直接的选型参考：

1、如果你是新手，或者项目初期只想快速验证，那么触发器 + dblink是最快的上线方式。
2、对于严肃的生产环境，需要稳定、高效且对业务无侵入的同步，请优先考虑 逻辑复制。
3、如果你的系统是分布式微服务架构，需要将数据变更事件广播给多个下游服务，那么 Debezium CDC 这套组合拳是标准答案。
4、如果业务只要求T+1或小时级的同步，那么用 定时 pg_dump 脚本是最经济实惠的方案。