咨询Google Cloud SQL中PostgreSQL逻辑复制的更优实现方案

• PostgreSQL的logical decoding是底层基础能力，作用是从写入WAL日志的流中拆解出结构化的行级变更记录，为上层能力提供数据源
• logical replication是构建在logical decoding之上的端到端用户功能，支持把单库、单表甚至行级的变更从源库持续同步到目标库，两者是底层引擎和上层功能的关系。

你当前使用9.6版本Cloud SQL的场景下，完全不需要跨5个组件拼接流程，现有链路有3处明显的冗余可以直接砍掉：

• 砍掉Pub/Sub中间层
  现在Cloud Scheduler本身支持直接以HTTP、事件驱动的方式触发Cloud Function，根本不需要先把消息发到Pub/Sub、再由Pub/Sub触发函数，直接把原来“Scheduler发消息到主题”的步骤换成“Scheduler定时直接调用导出函数的触发地址”，直接少一跳链路。
• 砍掉删库重建的固定步骤
  你之前选择删除B库再重建，本质是因为默认导出的pg_dump文件不包含对象清理语句，这个问题完全可以通过调整导出参数解决：触发Cloud SQL导出任务时，给pg_dump增加--clean --if-exists参数，导出的文件会自动在每个对象创建前附带对应的DROP、清理语句，直接导入到已存在的B库就可以完成数据覆盖，不需要删库重建。这一步不仅能省掉两次调用Cloud SQL管理API的耗时，还能消除整个操作过程中B库完全不可用的空窗期。
• 合并两个独立的Cloud Function
  原来的设计是“导出文件写GCS”的事件触发第二个导入函数，这种异步事件的链路不仅容易出现事件延迟、偶发丢失的问题，还会拉长整个流程的执行时间。完全可以把两个函数的逻辑合并为一个，在导出Function内等待Cloud SQL导出任务执行完成、确认GCS上的dump文件可正常读取后，直接在同一流程内执行导入任务，不需要依赖GCS的事件触发机制。

1. Cloud Scheduler 按你设定的非实时同步频率，定时触发合并后的Cloud Function
2. 函数调用Cloud SQL导出API，导出A库全量数据到指定GCS桶，导出附带--clean --if-exists参数
3. 函数轮询确认导出任务状态为成功后，直接调用Cloud SQL导入API，把GCS上的dump文件导入到已存在的B库
4. 导入任务确认成功后，函数直接清理GCS上的临时dump文件

如果你的A库数据量不算特别大（单库总规模在10G以内），甚至可以进一步去掉GCS中转环节：让Cloud Function直接通过数据库连接同时打通A、B两个库，在函数内通过pg_dump把A库的数据导出为内存流，直接通过psql连接导入到B库，全程不需要落盘临时文件，整体链路可以压缩到只有Cloud Scheduler、单个Cloud Function、Cloud SQL三个组件，运行速度更快，维护成本更低。

注意：因为你本身没有近实时同步的要求，这套定时全量覆盖的方案，维护成本其实远低于原生逻辑复制，不需要持续配置复制槽、监控WAL堆积、处理同步延迟，完全匹配你的业务需求。

内容的提问来源于stack exchange，提问作者chb