PostgreSQL多租户数据子集的增量CDC迁移方案咨询

核心需求梳理 #

• 源RDS（us-east）仅需迁移CustA的关联数据至目标RDS（eu-central），单客户数据量18GB、涉及多表
• 采用「快照初始迁移 + CDC增量同步」的模式，部分表无modified_date字段
• 要求CDC仅同步CustA的变更记录，降低切换时间与导出开销

可选方案分析 #

AWS DMS #

• 单租户CDC过滤支持：完全支持。通过DMS任务的表映射规则可配置行级过滤，针对每张关联表添加WHERE cust_id = 'CustA'（替换为实际租户标识字段）的条件。即使表无业务时间字段，DMS基于PostgreSQL的WAL日志捕获变更，无需依赖业务字段。
• 实操要点：
  • 初始快照：创建DMS任务时选择「迁移现有数据并持续复制」，同时在表映射中配置行过滤，快照仅同步CustA的记录，无需全量导出整个库。
  • CDC阶段：DMS自动捕获WAL中属于CustA的INSERT/UPDATE/DELETE变更，直接同步至目标端。
  • 前置配置：需开启源RDS的逻辑复制（将rds.logical_replication参数设为1），并为DMS的IAM角色配置源、目标RDS的访问权限。
• 优劣势：优势是AWS原生服务，运维成本低、无需额外部署组件；劣势是自定义逻辑灵活性有限，复杂关联表的过滤规则需仔细校验。

Debezium #

• 单租户CDC过滤支持：支持且灵活性更强。通过PostgreSQL连接器的**转换（Transforms）**功能实现行级过滤，示例配置如下：

  transforms=filterCustA
  transforms.filterCustA.type=io.debezium.transforms.Filter
  transforms.filterCustA.language=spel
  transforms.filterCustA.condition=payload.after.cust_id == 'CustA'
  

  无modified_date的表同样基于WAL捕获全量变更，过滤后仅同步CustA的记录。
• 实操要点：
  • 需部署Debezium集群（可托管于AWS MSK或自建Kafka Connect），依赖Kafka存储变更事件。
  • 初始快照可通过Debezium自带的快照功能完成，同时配置过滤条件拉取CustA的数据。
  • 切换日：停止CDC任务，禁用源端CustA的访问权限，确认最后一批增量同步完成后启用目标端服务。
• 优劣势：优势是高度可定制，支持复杂过滤、转换逻辑，适配多租户精细化管理；劣势是需维护Kafka与Debezium组件，运维成本高于DMS。

自建ETL管道 #

• 单租户CDC过滤支持：完全自定义，灵活性拉满。基于PostgreSQL的逻辑复制功能（pg_logical_slot）开发CDC捕获程序：
  • 创建逻辑复制槽订阅WAL日志，解析变更记录后按租户ID过滤出CustA的内容，再同步至目标RDS。
  • 初始快照用pg_dump加条件导出：

    pg_dump -t Customer -t CustomerShoppingDet --where="cust_id='CustA'" -f custA_dump.sql
    

    再将导出文件导入目标端。
• 实操要点：
  • 需自行处理WAL日志解析、断点续传、异常重试等逻辑，保障数据一致性。
  • 无modified_date的表直接通过WAL中的变更类型（INSERT/UPDATE/DELETE）同步，无需依赖业务字段。
• 优劣势：优势是完全可控，适配特殊业务规则或合规要求；劣势是开发与维护成本高，需要专业的PostgreSQL与CDC技术能力，上线周期长。

方案选择建议 #

• 追求低运维成本、快速上线：优先选AWS DMS，原生服务集成度高，足以满足单租户过滤需求。
• 需要复杂自定义逻辑、多租户精细化管理：选Debezium，配合Kafka可灵活扩展后续数据流处理。
• 有特殊业务规则/合规要求且团队技术能力充足：再考虑自建ETL管道。

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