建索引问题

【 TiDB 使用环境】测试
【 TiDB 版本】6.6.0
【复现路径】建索引
【遇到的问题:问题现象及影响】
执行完建索引SQL后,通过ADMIN SHOW DDL JOBS,查看状态,发现很久没变化


出什么问题了吗?如何结局

【资源配置】
【附件:截图/日志/监控】

只能等着,DDL 是异步的操作

现在集群没有任何负载,就是为了加快建索引的速度。把相关的DDL参数也都调大了

image
创建时间和开始时间差别这么大,你机器配置是多少,修改表数据量有多大啊

等待多久,能有个大概的评估吗,已經等了十几个小时了。

我在多个控制台上执行多个建索引命令。让他们排队挨个执行。第一个索引用了大概36个小时。第二个就是图中的那个。启动后就十几个小时没响应了。这个表的总容量大概90亿条记录

1 个赞

TIDB日志不停的WARN

数据多ddl本来就执行比较慢

在添加第一个索引的时候,DDL JOBS里有个ROW_COUNT字段,会一直变化。但是在添加第二个索引时,这个字段一直是0.

数据量大,90亿
索引字段也多 4个字段
这么看时间长时正常的

我记得ddl 都是排队的啊,是不是第一个完成以后第二个才开会运行

我把所有检索引的任务都用ADMIN CANCEL DDL JOB取消了,重启了一下集群,发现所有TIDB节点都起不来了


TIDB节点不停的输出日志

job id=223的就是取消的检索引任务。现在如何解决,请大家帮忙

所有tidb主机运行 service tidb-4000 stop; service tidb-4000 start 然后问题解决了

看是测试环境,建议使用LTS 版本

一个馊主意啊。

你要不要尝试一下,先给1天的数据建这个索引,然后再给最近7天的数据建。

大致是这个意思,你几十亿条数据,别说建索引,你建任何非row数据都慢啊


在一个只有11万记录的表里检索引,也是一直运行,两个小时都没玩,SCHEMA STATE 一直是WRITE REORGANIZATION, state 是running. 后台日志一直打印

想确认下,tidb_ddl_distribute_reorg 参数是怎么样子的?

首先,目前 6.6 的分布式 reorg 不可用,建议用户不要打开tidb_enable_distribute_reorg,这个跟 fast reorg 一起打开会引发bug


你好,现在TIDB在做什么哪?这个表才十几万的量,执行很久都没执行完.后台还不停的输出日志