tidb集群添加字段慢

集群版本:V4.0.8
问题:
集群添加字段慢,集群中的tidb-server某个节点日志显示:


加字段还能加上非常慢,然后把这个节点下了 ,现在集群无法添加字段

看了多个代理没异常日志输出,添加完DDL 后处于初始任务状态none,
查看OWNER信息:


执行 这个命令 提示
This node is not a ddl owner, can’t be resigned.
对所有的TIDB-server 都执行 都返回一样的消息

当前操作过:
1、下线过tidb-server节点、扩容一个节点
2、集群更换过PD集群,部分TIDB-SERVER/TIKV 没有更新过PD地址、
3、测试添加DDL 不执行

1 个赞

更换 PD 集群是怎么操作的呢?

下线一个 上线一个 然后执行depoly.yml

现在集群异常,升级版本 卡在滚动TIDB-SERVER节点 异常,,,,
[2021/12/22 16:45:01.947 +08:00] [INFO] [ddl_worker.go:262] [“[ddl] add DDL jobs”] [“batch count”=1] [jobs=“ID:70428, Type:modify column, State:none, SchemaState:none, SchemaID:3, TableID:21, RowCount:0, ArgLen:5, start time: 2021-12-22 16:45:01.891 +0800 CST, Err:, ErrCount:0, SnapshotVersion:0; “]
[2021/12/22 16:45:01.947 +08:00] [INFO] [ddl.go:487] [”[ddl] start DDL job”] [job=“ID:70428, Type:modify column, State:none, SchemaState:none, SchemaID:3, TableID:21, RowCount:0, ArgLen:5, start time: 2021-12-22 16:45:01.891 +0800 CST, Err:, ErrCount:0, SnapshotVersion:0”] [query=“ALTER TABLE mysql.stats_histograms MODIFY cm_sketch BLOB(6291456)”]
[2021/12/22 16:48:01.934 +08:00] [INFO] [client_batch.go:661] [“recycle idle connection”] [target=xxx]
服务启动着 实际端口没起来


请问,是异常了之后,又决定升级;还是先升级,然后执行的过程中又执行了 ddl,产生了异常?

是异常之后 决定升级的,升级前已经异常了 ,升级版本 看着需要修改MYSQL库下表的DDL…

ALTER TABLE mysql.stats_histograms MODIFY cm_sketch BLOB(6291456) 修改的系统表?
上面的截图又是 test 库的 aa 表?
这个是测试库吗?
另外在查下,被下掉的那个tidb-server 节点,进程还有残留吗? ps -ef 检查下,是不是 owner 在下掉的机器上。

在test库下验证的加字段 ,目前把剩余的几个tidbserver重启 可以滚动,不知道这个问题怎么发生的,,导致DDL 没有OWNER

恢复了吗? 如果恢复了,那应该是下掉的那个可能是 owner,没有下干净,所以让查下是否有残留进程。owner 还在下掉的那个节点。

前面重启了部分tidb-server 现在直接全部依次的kill -9 过去 就可以了

好的,那升级也完成了是吧。

升级时完成了 ,这个TIDB-SERVER的OWNER 为什么会掉了呢?


你查的时候,owner 在这里吗? 有没有后面在确认过。你的操作等执行一次 resign 后,有没有在看下 owner 在哪里?

检查的时候 显示ownere是这个,通过resign显示This node is not a ddl owner, can’t be resigned.返回这个信息

那就需要在重新查看下,owner 选举到哪个节点了。你多次执行了 resign,不知道是不是连续执行的,导致可能有些问题。 感觉出问题以后,可以先查看问题,如果多次执行命令,缩容扩容后,不大好判断问题在哪里了。你可以回想下,是否在执行resign 的同时缩容了tidb-server。导致正好resign 到了缩容的tidb 节点

在出问题得时候 还没执行resign, 后面看着没得救了 ,才开始执行resgin的,
整个流程:
在这之前换过PD集群3个节点:昨晚源端进行批量的DDL通过DM同步到TIDB

上午在test库进行测试开始DDL 很慢—》然后关闭某个点tidb-server 然后又扩回去一个—》发生了无法添加DDL —》---》查看owner,但resign返回This node is not a ddl owner, can’t be resigned.
–》想着升级能不能解决—》升级滚动到TIDB-SERVER 异常了–》服务通过ps -ef存在 检查端口不存在—》回滚之前版本 可以正常—》 依然无法添加DDL --》登陆客户端执行SELECT tidb_is_ddl_owner();返回为0—》最后在@lizhongshu建议下重启tidb-server,一波KILL -9 就好了

确认一下是否在 DDL 过程中执行的升级操作 ?这块要注意一下,因为我们目前升级工程中不要有 DDL 操作。可以再确认一下这个点。

1 个赞

学习了,集群异常。。

目前就是怀疑有2个操作引起的问题:1、集群在扩缩容期间,有进行DDL 2、PD 集群换过地址(3个pd)

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