【 TiDB 使用环境】生产环境
【 TiDB 版本】5.3.0
【复现路径】定时任务每天先trunc表，然后insert 进四千多万数据
【遇到的问题：问题现象及影响】
通过监控看到，region和内存增长，当时时间点有大量空region产生
通过TIKV_REGION_STATUS表看到，昨天有库名、表名的region今天变为null了，该数据表是trunc了，然后新增了数据。
该帖子https://asktug.com/t/topic/665043说是gc问题，但没有提及怎解决
【资源配置】
【附件：截图/日志/监
region和内存增长.bmp (4.2 MB)
空region迅速合并.bmp (2.1 MB)
控】
TIKV_REGION_STATUS昨天table_name有值，今天为null.bmp (4.5 MB)
show variables like ‘%gc%’ ,mysq.delete_range/mysql.delete_range_done有多少条数据
gc_delete_range 和gc_delete_range_done我转了下时间
gc_delete_range和done的数据竟然是1984年的.bmp (2.1 MB)
gc_delete_range :9079
gc_delete_range_done:146
gc配置.bmp (2.1 MB)
如果没gc掉，先得等他gc，如果gc完了，tikvctl看下对应的region_id的region大小是多少，咋看看 max-merge-region-size参数设置的多大，是不是还没小到需要合并region的时候。
转换的时候tiup ctl:v5.4.3 pd -u https://10.10.10.16:2379 tso 445041280393412610
这么转
或者直接SELECT TIDB_PARSE_TSO(445041280393412610);
select * from mysql.tidb。 pd-ctl service-gc-safepoint --pd pd_addr 两个结果看下
gc_delete_range :9079 gc间隔是10分钟 ，gc没有正常执行。
select * from mysql.tidb
看看tikv_gc_run_interval,tikv_gc_last_run_time,tikv_gc_safe_point 三个值
在leader tidb035 这台上看看tidb.log 日志gc相关的记录是不是有很多gc worker busy
[2023/10/31 06:03:29.604 +08:00] [Error] [gc_worker.go:713] [“[gc worker] delete range failed on range”] [uuid=62977187790001c] [startKey=748000000000007b2d] [endKey=748000000000007b2e]
[error=“[gc worker] destroy range finished with errors: [unsafe destroy range failed on store 2351687: gc worker is too busy unsafe destroy range failed on store 2354153: gc worker is too busy unsafe destroy range failed on store 2354194: gc worker is too busy unsafe destroy range failed on store 5: gc worker is too busy unsafe destroy range failed on store 1: gc worker is too busy]”]
确实，有很多gc worker is too busy
TiDB 5.3.1 Release Notes 有关于 “GC worker 繁忙后无法执行范围删除（即执行 unsafe_destroy_range 参数）的问题 #11903
我找到您回答的帖子，我确实是5.3.0，这个只能升级解决么？是否有临时手动解决的方法？
多谢，找到原因了，我也是重启tikv临时解决问题，我申请下是否升级到6.5.5
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。
