【 TiDB 使用环境】生产环境
【 TiDB 版本】5.2.2
【遇到的问题:问题现象及影响】
为何auto analyze table总是失败,而人工执行analyze table却能成功呢?两者做analyze有什么不同吗?这套集群遇到很多次了
![image](https://asktug.com/uploads/default/original/4X/c/6/4/c641fe592571095e9ed3118be57652920d3a016f.png)
tidb.log关于analyze的日志:
【 TiDB 使用环境】生产环境
【 TiDB 版本】5.2.2
【遇到的问题:问题现象及影响】
为何auto analyze table总是失败,而人工执行analyze table却能成功呢?两者做analyze有什么不同吗?这套集群遇到很多次了
tidb.log关于analyze的日志:
自动analyze是单线程,大表因为gc问题导致失败。 手工执行时多线程的有几个build相关变量可以控制并发度
但是手工analyze也需要接近2个小时,远超tidb_gc_life_time设置了,这是为啥呢?
并发度不一样啊
从你发的日志可以确定auto analyze是因为超过GC失败,是因为以前的版本 后台任务运行时没有考虑自动增加gc safepoint时长,6.x版本后才改进,减少因GC失败。前台任务对于长时间执行的是可以增加safepoint时长的,自动调整,你可以试试在手动analyze 超过gc saepoint后,查看以下saepoint时间 :pd-ctl service-gc-safepoint
自动分析比较慢呀
不是慢不慢的问题,自动的都是20分钟就报错了
{
“service_gc_safe_points”: [
{
“service_id”: “gc_worker”,
“expired_at”: 9223372036854775807,
“safe_point”: 445874237452845193
}
],
“gc_safe_point”: 445874237452845193
}
请问这个如何转换为时间呢?
select TIDB_PARSE_TSO(9223372036854775807);
或者
tiup ctl:v<CLUSTER_VERSION> pd -u https://127.0.0.1:2379 tso {TIMESTAMP}
那看来show global status like ‘tidb_gc_safe_point’;这个应该也可以
应该是受参数影响造成的
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。