AWS DMS CDC场景下PostgreSQL配置操作捕获触发器的可行性咨询

在PostgreSQL(B)上配置触发器捕获DML操作类型与时间的方案，技术上完全可落地，但合理性高度匹配实际需求边界，并非所有场景下的最优选择，不注意配置细节很容易出现数据不准、链路中断的问题。

从技术兼容性来说，方案不存在实现门槛：

• PG的行级触发器可以正常拦截DMS写入的标准DML语句，不管是第一段任务全量初始化阶段的批量插入，还是CDC阶段的增量增删改操作，都能正常触发逻辑、捕获操作类型与对应时间
• 触发器的行级写入逻辑，和DMS依赖的WAL日志解析机制不会产生原生冲突，只要配置得当不会中断两段CDC的同步链路
• 相比独立部署数据库审计组件，这个方案的实现成本极低：不需要额外的审计权限、不需要做全量日志采集，只需要给中转库的同步表加两个标记字段和公共触发器函数即可上线

举个可直接运行的最简实现样例：
首先给每张需要捕获操作的同步表新增两个字段：op_type char(1)、op_time timestamptz，再创建公共触发器函数：

CREATE OR REPLACE FUNCTION capture_b_dml_op()
RETURNS TRIGGER AS $$
BEGIN
  IF TG_OP = 'INSERT' THEN
    NEW.op_type = 'I';
    NEW.op_time = clock_timestamp();
    RETURN NEW;
  ELSIF TG_OP = 'UPDATE' THEN
    NEW.op_type = 'U';
    NEW.op_time = clock_timestamp();
    RETURN NEW;
  ELSIF TG_OP = 'DELETE' THEN
    -- 删除操作无法在主表留存标记，单独写入删除审计表
    INSERT INTO b_dml_delete_audit(table_pk, old_row_data, del_ts)
    VALUES (OLD.primary_id, to_jsonb(OLD), clock_timestamp());
    RETURN OLD;
  END IF;
END;
$$ LANGUAGE plpgsql;

最后给每张表绑定对应的触发器：BEFORE INSERT/UPDATE阶段触发字段填充逻辑，AFTER DELETE阶段触发审计日志写入逻辑即可。

完全合理的适用场景 #

• 你需要捕获的是中转库B本身接收到的所有DML操作标记，不管操作来自上游Oracle(A)的同步、还是其他业务系统直接写入B的请求，触发器都能完整记录操作类型和发生时间
• 你不希望改动最上游的生产源库A的表结构，仅需要在中转层补充审计字段，不影响核心生产系统的稳定性
• 你不需要捕获操作人、客户端IP等复杂审计维度，只需要基础的操作类型和时间戳标记

完全不合理的适用场景 #

如果你的目标是拿到源端Oracle(A)的原生操作类型和操作时间，这个方案从设计逻辑上就存在硬伤：

• 你在B的触发器里拿到的操作类型，是DMS处理后在B端执行的操作类型，不是源端A的真实操作。比如DMS做冲突处理、批量同步时，本来源端是UPDATE操作，到B端可能被执行成DELETE+INSERT；源端的DELETE操作，可能在全量初始化阶段被DMS的UPSERT逻辑覆盖，触发器最终记录的操作类型和源端完全不一致
• 触发器拿到的操作时间，是DMS把数据写入B的时间，不是源端A执行DML的真实时间，遇到DMS队列堆积、网络抖动的场景，时间差可能达到数分钟，完全不满足高精度溯源的要求
• 额外的触发器逻辑会拖慢B的写入性能：逐行触发的逻辑会把DMS的批量写入拆成单行处理，通常会让链路写入吞吐下降30%-50%，大表场景下同步延迟会非常明显
• 触发器产生的额外写入（比如删除操作的暂存日志）如果没配置到DMS的排除列表里，会被误同步到下游Oracle(C)，产生冗余垃圾数据；严重时还会因为锁等待触发DMS同步死锁，直接中断第二段CDC任务

如果你的目标是拿到源端A的原生操作信息，根本不需要编写触发器：
DMS从Oracle(A)读取CDC日志时，每条记录自带$operation（标记I/U/D操作类型）、$timestamp（源端操作时间）元数据，直接在第一段DMS任务的转换规则里，把这些元数据映射成B表的普通列即可。全程没有触发器带来的性能损耗，拿到的数据就是源端的真实值，后续同步到C的时候也可以直接透传这些字段，完全不需要额外开发。

注意：如果一定要用触发器实现，记得把触发器产生的删除审计表加到第二段DMS任务的表排除列表里，同时适当调高同步延迟的监控阈值，给触发器的额外处理留足缓冲空间。

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