【 TiDB 使用环境】生产环境
【 TiDB 版本】v6.3.0
【复现路径】定时加分区和删分区任务,偶然情况下会出现。以前是own_id更换后DDL要卡8-10个小时,这次own_id更换后这个表还是一直卡着。
【遇到的问题:问题现象及影响】
生成环境明天会增加分区和删除分区。5月20号后一个表生成分区卡住,导致后续堆积很多DDL任务。重启集群后其他表的DDL也卡住。修改own_id和重启集群问题没解决。只是重启集群8个多小时后,其他表的DDL操作能执行。
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件:截图/日志/监控】
你的生产也是6.3.0版本吗
是的。
6.3.0DMR版本不建议生产使用, 6.3中开始引进了 tidb_enable_metadata_lock
变量,这个会导致dml阻塞ddl , 而且刚引入不是很成熟,设置为false看看。如果是重启解决的话 需要所有tidb server都关闭后再重启。 建议升级下版本吧
1 个赞
看下这个参数
这个参数本来就是 off的。
这个参数是 OFF
这种情况在平时定时加分区和删除分区的时候会随机在某个表上出现?
tidb卡住ddl只能restart所有tidb节点了。
我的经验是不要用分区表, tidb上意义不大。
如果要用,最好提前把这些分区都加了
我直接把集群重启的。
每个分区表都要加对应的分区。
tidb节点重启过,没效果。
tiup cluster restart tidb-test -R tidb
这么重启的吗
是只有这个表会卡住吗?其他表正常?
这不是应该是job在tikv中。然后去执行的么。把tidb server关闭了。过一会再启动
mark等官方解答
关注,tidb早期对ddl的处理让我感到奇怪。实际上很多批量作业是DDL和DML一起混着用的,阻塞DDL结果不会比阻塞DML差。
想了下,还是根据我薄弱的理解提一些建议:1,
ADMIN SHOW DDL
看看有哪些DDL在执行,考虑是否有必要kill掉这个job
2,最终没办法,看看是否能够升级解决。8.1对DDL的处理效率应该是比较高的
1 个赞
还是重启大法好用