tidb 版本 v3.0.9
使用drainer同步binlog下游到kafka遇到一些问题：
- drainer同步到kafka，跑的是批还是流
- drainer同步到kafka，可用配置只有配置文件中提及到的吗
- drainer同步到kafka时，偶发binlog too big，200+M级别，可否过滤筛查到这条binlog消息具体内容
- 什么情况下，binlog会产生上述这么大，drop表吗，可否避免，因为如果动不动需要修改下游kafka配置以满足drainer同步条件，比较不妥。
收到，这里分析下，如果有更新会及时跟帖回复，感谢配合~~
- 同步到 kafka 是流
- 是的
- binlog 大小理论上没有上限，取决于上游 tidb 写入 tikv 的 kv size.( 这里希望是过滤到一定大小的 binlog 吗？目前还没有这个支持
- 大事务，或者批量删除场景，会有这个情况，下游 kafka 配置可以 messege 可以在一开始设置大些。
你好，如果某条binlog因为大小原因无法同步，能否看到binlog的执行内容
如果 tidb-binlog 下游是 kafka 目前无法查看。
drainer 同步会被卡住，从日志中可以看到，fatal 出现后 drainer 已经重启。
关于 save point 变化，可以看下是否开启 safe mode，drainer 在重启后会进行 safe mode 加载一段时间数据，避免数据重复，可以忽略。
对于本帖的问题还是需要调整 kafka broker 的单条message限制，已解决此问题。
safe mode 加载的是历史数据 / 最新数据？还有safe mode对kafka类型的下游也有效？
更正下，safe mode 仅对下游是 tidb 或 mysql 才会生效。
drainer 重启 5min 之内会将新的数据通过将上游的 INSERT 改写为 REPLACE，将 UPDATE 改写为 DELETE 与 REPLACE，同步到下游。
对于本帖的问题还是需要调整 kafka broker 的单条message限制，来解决。
你好，感谢回复，也没有办法控制上游的binlog大小吗，关于kafka下游配置中有最大message限制，这个的作用为何，因为不知道上游会有多大的binlog，如果每次去放大下游broker的配置，有点僵硬，感谢耐心回复
你好，
楼上的回复应该可以解答你的问题，目前上游无法限制 binlog 大小，只能从应用端控制写入 tidb 的单次数据量的大小。
好的，那由于该报错导致drainer退出，重启之后，不会出现漏掉一部分binlog吧，目前测下来，下游kafka仍然有数据进来，但是drainer由于message大小问题一直在重试重启，考虑数据一致性的问题
不会丢数据的，drainer 重启后会读取 kafka 中 commit-ts 来保证数据的增量同步
https://docs.pingcap.com/zh/tidb/v4.0/tidb-binlog-faq#什么是-checkpoint
你好，请确认下，tidb 中 txn-total-size-limit 的值，可以通过 tisb.log 搜索下
txn-total-size-limit":104857600 限制是100M，应该也对不上
你好，针对 update 操作 binlog 里面的是带有旧值的，就算 tidb 限制的是100M, 生成的 binlog 有可能是超过 100M的。所以只能通过降低 tidb 端单事务大小，或者调大 kafka broker
你好，
上传下 drainer 日志中的 两个 welcome 的日志，需要取人下 fatal 时，commit ts 。
额，请上传下完整的日志文件，该信息并不是很全，也不方便检索