调整tikv_gc_life_time后报错: destroy range on store failed with error

shonge · 2021 年3 月 22 日 13:47

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：

【TiDB 版本】v3.0.8

【问题描述】把tikv_gc_life_time 从720h缩短为2h后，tidb日志报错：

[gc worker] destroy range on store failed with error

github.com

pingcap/tidb/blob/dbc5b4f5d1829cc72c349a0eb78f22b3f881eb39/store/tikv/gcworker/gc_worker.go#L673-L688


	for _, store := range stores {
		address := store.Address
		storeID := store.Id
		wg.Add(1)
		go func() {
			defer wg.Done()
			_, err1 := w.store.GetTiKVClient().SendRequest(ctx, address, req, tikv.UnsafeDestroyRangeTimeout)
			if err1 != nil {
				logutil.Logger(ctx).Error("[gc worker] destroy range on store failed with error",
					zap.String("uuid", w.uuid),
					zap.Uint64("storeID", storeID),
					zap.Error(err))
				err = err1
			}
		}()
	}

看代码这里配置5分钟超时：
https://github.com/pingcap/tidb/blob/dbc5b4f5d1829cc72c349a0eb78f22b3f881eb39/store/tikv/client.go#L52-L53

请问如何进一步查看当前gc worker状态是否正常？

若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。

GangShen · 2021 年3 月 23 日 01:12

完整的 TiDB 日志是否可以提供一下
gc worker 状态可以通过在 tidb.log 和 tikv.log 中 grep ‘gc_worker’ 关键字查看，也可以看下 select VARIABLE_NAME, VARIABLE_VALUE from mysql.tidb where VARIABLE_NAME like “tikv_gc%”; 的结果

shonge · 2021 年3 月 23 日 03:02

看日志已经执行完成了：

finish redo-delete ranges"]  [uuid=xxx] ["num of ranges"=4365"] ["cost time"=3h1m34.xxx]

GangShen · 2021 年3 月 23 日 03:33

嗯，应该是调整时间跨度过大，GC 需要清理的数据应该比较多。

shonge · 2021 年3 月 23 日 03:37

看结果是这样的。
1、TiKV UnsafeDestroyRange 这个接口是异步的吗？
2、如何观测tikv destroy range进度，或者评估gc耗时？
3、如果gc时间太久已影响业务，能否中途取消？

GangShen · 2021 年3 月 23 日 03:42

是异步的
进度问题可以参考下：TiDB 写入慢流程排查系列（六）— GC 机制
GC 不可以取消，但是可以控制 GC 流控：https://docs.pingcap.com/zh/tidb/stable/garbage-collection-configuration#流控

system · 2022 年10 月 31 日 19:14

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