链接:https://pan.baidu.com/s/1ggTGBDnQ8nzaXd_uYNH0Bw
提取码:oyso
@户口舟亢
你好,该页面不存在,请核实下。
ok,已收到
你好,
drainer 重启之后会根据 checkpoint 开始 5min 的 safe mode 插入数据,从日志中,
红色框代表重启前的 commit ts > 绿色框代表重启后初始化的 commit ts ,是预期的。目前 drainer 在不断的重启,原因是:
[error=“kafka: Failed to produce message to topic bd_tidb_online_log: kafka server: Message was too large, server rejected it to avoid allocation error.”]
所以需要调整 kafka message 大小,
https://docs.pingcap.com/zh/tidb/v4.0/handle-tidb-binlog-errors
好的,感谢
ok。
绿色框是从savepoint文件中读取的?
对于 kafka 下游来说,是从 pb 文件中读取的
我最后梳理下,因为一条message过大了,目前可以通过kafka放开限制解决,但是如果过大的导致drainer不断重试,最后会退出,systemd会重新拉起drainer,这时候按照上述,会读取pb文件tso,并以此为基准做最近5分钟的safe mode数据插入,请问是这样的吗
但是目前遇到savepoint在有过大binlog未同步过去(drainer不断重启)的时候,还是被更新的情况,正常否,会是啥原因导致的;针对kafka类型的下游,safe mode机制是不生效的,这个我在测试中也没有复现(先插入、update,然后调小kafka message配置,导致大binlog没有同步的报错后,drainer重试重启都没有发现有五分钟前的数据进入kafka)
假设 fatal commit ts 为 100,drainer 重启后会从一个早的 checkpoint 开始同步,到了 100 ts 又会中断.
这边出现fatal报错后,但是仍然能够继续同步数据到kafka,这会是什么情况; 如你所说,我也验证了一下,首先,正常生成binlog并从kafka去消费,然后调小kafka message后,出现一条fatal告诉你message过大,记录savepoint到文件,无论是重试还是重启drainer,根据drainer日志和下游kafka最新消费,发现都不会有历史(更早的一段时间 ts)数据产生
drainer重启之后,我认为的是有savepoint文件记录的tso肯定权重高于drainer配置的initial_ts,如果这时候
从更早时间开始同步,是否也会去更新这个文件呢
此为 replace int 覆盖插入,会重新获取 commit ts,不会有新的数据插入。
是的,当找不到 checkpoint ,则会从 init ts 拉取数据。
这里的更早的时间指的是什么操作
指的是 早一点的savepoint开始同步
这里说的safe mode是对kafka不生效的,这一点明确了,我也测试验证了,但是就是想知道明明日志已经提示fatal message过大,drainer重启重试也罢,这里理应卡住在这个savepoint,但是实际遇到了savepoint被更新了,而且kafka也有数据进来
这是卡住的时间点
这是savepoint的时间(期间drainer不断重启重试,savepoint没有手动更新过)
![image](https://asktug.com/uploads/default/original/3X/1/9/19ed68a1f09cae81f98b6c636ee5913f4c858347.png)
drainer日志
链接:百度网盘-链接不存在
提取码:4md3
从这个日志中看到,06/24 00:24 的时候 drainer 就已经不断重启,卡在 checkpoint 417566177481982008 这里了,直到 06/24 10:30 checkpoint 都没更新过。理论上没有数据发送才对。
`但是实际遇到了savepoint被更新了,而且kafka也有数据进来`
这里能不能给这个不断重启的 drainer 开启 debug 日志,如果这个 drainer 给 kafka 发送了消息,就会打印一个 debug 日志。关键字 get success msg from producer。就能表明是这个 drainer 发送了消息。