各位好，我是该功能的开发者，很高心看到大家对该问题的探讨。
- cdc 到 kafka 链路，没有 safe-mode 参数。
- 在使用 kafka sink 的情况下，update 事件的拆分逻辑如下。对于单条 update 事件，如果发生了 primary key 或者 unique key 的修改，那么拆分为 delete + insert 语句。
关于 update 事件拆分，用户观察到的是输出内容发生了改变。该行为变更，表面上是对某些协议，如 avro，csv 的兼容，实际上它还牵扯了其他模块的功能正确性，如 index-value dispatcher。
考虑如下 SQL 语句
create table t (a int primary key, b int);
insert into t values (1, 2);
update t set a = 2 where a = 1;
使用 index-value dispatcher，将上述两条 sql 语句的变更，分发到有多个 partitions 的 topic。
第一条 insert message，假设发送到了 partition-1，该值是基于 primary key = 1 计算得到。
第二条 update 语句，如果不做拆分，那么分发到 partition-2.
可能出现的一个情况是，consumer 先消费了 partition-2 的数据，此时下游系统中可能并不存在 primary key = 1 的行，那么就可能出错。
拆分之后。update 语句变成了 delete 1， insert 2.
partition-1 的数据流，先后有 insert-1，delete-1。
partition-2 的数据有，有 insert-2.
这个时候，无论 consumer group 中的 consumer 消费进度如何，最终每个 key 对应的事件，都能被按照正确顺序消费。这即是做出上述改动的最核心动机。
关于 key updated 事件的拆分，参考了 Debezium connector for MySQL :: Debezium Documentation
可以看到，它们对 update 事件，是明确做出了区分的。