写不了了,binlog 跟 GC 逻辑没关系的,失败了就不行,看 binlog-error 的设置决定怎么办,可能是 skip-binlog ,可能是崩溃
他跳过了,直接开始写8点多的,binlog-error是 binlog.ignore-error: true
那就已经丢了,之前的跳过的没写 binlog 的事务找不回来了,只能通过 tidb api 或者重启 tidb 实例的方式重新让 tidb 从现在时间点开始写 binlog
如果把ignore-error改为faile 我看文档写得是会停止服务, 他停止tidb所有服务还是只是 pump服务?
哪个 tidb 实例写 binlog 写不下去,它就会停止哪个,比如说集群都正常,突然有个 tidb 实例与所有 pump 节点的网络有问题了,这时候它要写 binlog 的话,写不下去就会崩溃,其他 tidb 实例不受影响。
TiDB 正常写入,drainer 检查点正常推进,下游 kafka 没有数据,有没有可能你没变更呢,看看 drainer 监控的 Drainer Event
我说没变更是指你集群是不是业务量很少,真的没啥变动,不过看你监控之前应该是又的,你还是哪里有问题导致 drainer 没数据,你再检查下吧
找到了,curl http://192.168.1.1:10080/info/all |grep binlog 则个状态变了,变成skip,还是得要重启tidb服务才行。沃妮马~~
我用这两个看状态,一直都是正常onlind
show pump status;
show drainer status;
1、检查所有tidb的binlog写入状态:
curl http://tidb_ip:10080/binlog/recover?op=status
2、如果有skip的手动恢复一下
curl http://tidb_ip:10080/binlog/recover
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。


