ticdc是怎么处理大事务的?

[Mwkk (Ti D Ber A Cla Yr Lb)]

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】

生产环境开始逐步升级到 v7.1.5 ，之前版本都是使用 Drainer 在向下游同步数据，之前遇到业务在一个事务中大批量写入的时候，导致下游 kafka topic oom 报错的情况，查看日志为一个消息150M+，现在想通过使用 cdc 来看看这类问题能不能有所缓解。
想问一下1. cdc 在确认大事务的情况下，有无拆分的相关逻辑。2.事务会有 begin 和 commit 标识吗

[Jasper]

cdc 的 transaction-atomicity 参数会控制大事务是否拆分

[Jasper]

另外， ticdc 是有参数来 控制 kafka 消息较大的情况的，具体可以参考这个文档： https://docs.pingcap.com/zh/tidb/stable/ticdc-sink-to-kafka#处理超过-kafka-topic-限制的消息

[TIDB-Learner]

楼上说的对

[Mwkk (Ti D Ber A Cla Yr Lb)]

事务中 begin 和 commit 的标识有吗

[TiDB-ruiqianyun (rui qian yun)]

不清楚
不是不建议用大食物么
会卡住

[zhaokede]

会拆分的

[forever]

只要能抽取到的事务都是已经提交了的，这要事务是顺序的，这个有没有begin和commit是不是对你也没有影响啊

[kevinsna (Ti D Ber P O Zcnp Ja)]

1. 消息拆分逻辑：TiDB CDC 通过 TiKV 的变更日志捕获数据变更，然后将其转换为行级变更的消息发送到下游系统（如 Kafka）。TiDB CDC 会尽量保证每个变更消息的大小适中，避免单个消息过大。但是，如果事务中的变更非常大，TiDB CDC 可能无法在事务级别进行拆分，因为它主要基于变更日志的自然边界来生成消息。不过，您可以在 TiDB CDC 的配置中设置 message.max-size 参数，以限制单个消息的最大大小，从而避免单条消息过大。
2. 事务标识：TiDB CDC 在发送数据到下游时，会包含事务的开始（begin）和提交（commit）标识。这允许消费者识别事务的边界，并且可以根据这些信息来处理事务性的数据变更。例如，在 Kafka 中，可以使用事务的开始和结束标识来确保消息的顺序性和完整性。

针对您的情况，以下是一些建议：

• 监控和调整：监控数据同步过程中的消息大小，并根据需要调整 message.max-size 参数，以确保消息大小在可接受的范围内。
• 事务大小控制：在业务层面，尽量避免在一个事务中执行大量的写入操作。如果业务逻辑允许，可以将大事务拆分成多个小事务。
• 下游处理能力：确保下游系统（如 Kafka）有足够的处理能力来应对大事务产生的数据量。这可能包括增加 Kafka 集群的资源，或者优化 Kafka 的配置。
• 使用 TiDB CDC 的事务性语义：利用 TiDB CDC 提供的事务性语义，确保数据的一致性和完整性。在消费端，可以按照事务的开始和结束标识来处理数据，以避免因大事务导致的数据处理问题。
• 测试和验证：在升级到新版本之前，在测试环境中模拟大事务的情况，验证 TiDB CDC 的表现和配置的有效性。

[濱崎悟空 (Ti D Ber A4y L3 Lr T)]

有拆分控制