Kafka JdbcSinkConnector能否自动删除下游库上游已删除行？

核心结论 #

Confluent JDBC Sink Connector 不支持自动检测下游数据库中存在、但上游已不存在的行并自动执行删除的能力。
你配置中开启的delete.enabled=true并不具备全量数据差集比对的功能：这个参数的作用仅为，当连接器从Kafka topic消费到*key与表主键匹配、value为null的墓碑消息（tombstone record）*时，才会在下游执行对应主键行的删除操作。JDBC Sink本身是无状态的事件驱动组件，不会持久化存储上游全量数据快照，完全没有能力主动扫描上下游数据做差集比对。

你当前删除场景同步失效的常见原因 #

你遇到的删除操作无法同步的问题，基本可以归为以下几类：

• 上游内存数据库对接的CDC生产端（负责把内存库变更写入Kafka的组件），在执行行删除操作时，没有向对应Kafka topic发送符合规范的墓碑消息：即消息key和原行主键完全一致、消息value为null。不少轻量内存数据库的CDC实现默认只同步新增、更新事件，漏发删除墓碑消息是高频问题。
• 你重建内存数据库时是直接清空/销毁实例，没有逐行触发删除事件，Kafka中不会产生任何对应删除的消息，连接器自然不会对下游Postgres的存量数据做任何修改。
• 若消息key和下游表主键的字段映射不匹配，就算收到墓碑消息也无法定位到待删除的行，但你当前upsert场景运行正常，该问题概率极低。

开发环境免重建下游库的落地方案 #

你不需要每次更新上游数据库都销毁重建整个Postgres实例，可选以下低成本方案：

• 方案1：每次重建内存数据库、重启Sink连接器前，直接在Postgres中执行对应业务表的截断命令即可：TRUNCATE TABLE <你的业务表名> RESTART IDENTITY;，操作成本远低于整库重建。
• 方案2：补全CDC生产端逻辑，在销毁内存数据库前，遍历库内所有存量行的主键，批量向Kafka topic发送对应key的墓碑消息，等连接器消费完所有消息清空下游表后，再启动新的内存数据库实例。
• 方案3：利用你已开启的auto.create=true配置，每次重建上游时直接删除Postgres中对应的业务表，连接器启动后会自动根据传入的消息schema创建空表，无需操作整个数据库实例。

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