首先，这个之前是有支持的，开发的下游需要maxwell 格式支持。另外，文档中有说明支持的： [image] https://docs.pingcap.com/zh/tidb/v7.5/ticdc-sink-to-kafka#sink-uri-配置-kafka

cdc.log (3.1 MB) 测试环境日志

关闭这个sql

还有就是，既然是cdc 应该和主流cdc 一致，不然，生态不兼容

那个\n 是我自己加上去的，方便查看，实际没有这个换行符

这个参数下游kafka 不生效 以下参数仅在下游为 Pulsar 时生效。 下游kafka 报错： Error: component TiCDC changefeed’s config file /Cluster-data/ticdc/changefeed_ods.toml contained unknown configuration options: batching-max-message

是的，kafka 里面一条数据

执行多条写入： INSERT INTO ods.ods_test (id, user_id, user_name, mysql_delete_type) VALUES(2, 10596, ‘222’, 0), (3, 10749, ‘333’, 0), (4, 10596, ‘555’, 0); 数据依旧合并到了一起

目前测试了dispatcher = “table” 后多条合并 dispatch =“rowid” 报错： Error: [CDC:ErrDispatcherFailed]index not found when verify the table, table: ods.ods_consult_qy_wx_user, index: dispatch =“ts” 多条合并情况消失

目前数据要求，下游解析JSON，所以不要多条合并

更改配置文件： max-batch-size=1 无效

说明一点：我们这个cdc 同步的时候是 dim库下所有表

到tikv 目录下，du -sh ./* 对比一下三个的主差异文件

是否是日志的问题呢？

谢谢

gitee 里面有gif

好吧，但是开源的tikv api 确实可以这么用

这个我就不知道怎么判定了

你说的对，但是再tidb 开源的tikv api 来看，使用tikv 读取数据就是无需密码的； 在我们日常的使用中，一定要保护好自己的tikv ,tipd 的端口号哦