请教有关tidb binlog 事务的问题

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:

【TiDB 版本】
版本3.0.5

【问题描述】
有关tidb binlog的原理想请教下,谢谢

tidb3.0有事务的限制,事务最大不能超过100M。

1、tidb binlog的记录模式是类似于mysql statement-只记录执行语句,还是row-记录所有行的变化?
2、如果是row的,那假设一条update,产生了100m的事务,通过pump-drainer输出到kafka, 它是不是了一条100m的message?


若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

关于 binlog 的原理可以参考下官网博客文章, 类似于 MySQL row 模式,记录每一行的变更;

谢谢,这篇文章看过了,但是文章里没有没解释第二个问题:一条update,产生了100m的事务,通过pump-drainer输出到kafka, 它是不是了一条100m的message?

之前做实验,执行dm初始化操作的时候,drainer报了kafka:max_message_size相关的报错,将max_message_size调整到100M后才解决的。dm初始化是dump操作,dump操作为什么会产生那么大的message?

没太理解,DM 是 PingCAP 开源的 DM 工具吗 /?drainer 是 tidb-binlog 组件的呀。这是两个工具。

对,一套环境有DM从mysql同步数据到tidb ,还有drainer 同步tidb数据到kafka。在dm做初始化某一个库的时候,drainer报错了。

mysql 的 binlog 格式和 tidb-binlog 格式是不一样的。超过 kafka 的消息限制就报错了。

binlog 主要存在 Pump 中,TiDB 调用 Pumps Client 使用 Grpc 的方式给 Pump 发送一个写 binlog 的请求,Pump 会把 binlog 以 append 的方式写到 log 文件的末尾,然后会返回以个 success message 给 TiDB ,然后 Pump 异步的把 binlog 的元信息写到 Pump 内部封装的 leaveDB 数据库中,元信息包括 binlog 的 start-ts,commit-ts ,binlog 的类型,这条 binlog 在 logfile 中的位置等,然后它会更新自己的 max_commit_ts,这个是 pump 维护的一个自己的状态,表示这个 Pump 接收到的 binlog 最大的 commit_ts。然后它会异步的把已经接收的到 perwrite binlog 和 commit binlog 做一个一一对应并组合起来。

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。