drainer状态正常,实际为不正常,修改状态没生效

为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。

  • 【TiDB 版本】:V3.0.3
  • 【问题描述】: drainer下游数据库数据停止更新,查看drainer状态为online,修改其状态为paused,没有生效也没有报错

如附件截图

1:请问出现这个现象的原因是什么呢? 该如何解决该问题呢

2:多个pump之间,是互为高可用的关系吗? pump组件的数量要大于或等于drainer组件的数量?目前可以一个pump后配置多个drainer组件吗?目前是2个pump和2个drainer,分别同比到一个mysql和一个kafka ,如果其中一个pump挂掉了,对下游的mysql和kafka有影响吗?

谢谢

您好:

    1. 查看drainer的日志,执行了添加索引的操作,之后断开连接了? 请查看下游tidb是否有报错信息
    2. change状态的这个drainer,就是drainer日志的吗? 
   3. 您当前要修改的是哪个ip的drainer?

你好

1:下游不是tidb,是mysql,上游是tidb。添加索引的操作是在上游tidb上进行的,在drainer日志里报错加索引失败

2:是的

3:要修改的是17.158这个机器的drainer

您好:

    1. 请帮忙查看下游mysql是否添加索引成功? 当前是否能够同步
    2.  drainer.log 日志能否从报错到现在发我,多谢
    3.  drainer进程存在,所以paused后会自动再次online

下游索引添加失败,数据同步从创建索引失败的那一刻就断掉了,日志请见附件

谢谢

drainer.log (3.1 KB)

您好: 1. 下游mysql只有drainer同步对吧,能否检查下游mysql为什么添加索引失败? 2. 可以在下游mysql手工添加索引成功后,尝试跳过此ddl

1:下游添加索引在执行到第70分钟左右时失败了 ,当时的一些日志被覆盖了,ddl失败原因暂时不太好定位。

对于下游ddl时间过长的情况,drainer和pump组件能够容忍吗 ?是否有做什么干预行为呢

2:多个pump组件之间是互为高可用关系吗,如果某个pump挂掉了,会影响drainer组件的正常同步吗

谢谢

你好, 你的问题已收到,正在分析~

  1. 抱歉,这个问题时间这么久
  2. pump和drainer这边没有什么具体干预行为
  3. pump同步可能会断开,因为drianer需要将所有pump来归并排序,所以不一定可以继续同步