tidb版本:v4.0.9
背景：
sync-log 改为false
如下图：tikv_gc_run_interval由默认的10m0s改为 ，30m0s后，tikv_gc_last_run_time 就停留在了6天以前，修改的时候。 请问这是啥原因？是我修改的有问题吗，谢谢~
可以拿下 GC leader 的 tidb.log 看下，应该是 host b26 这个节点。另外除了手动修改之外，有没有使用其他工具，比如 TiCDC 等做数据同步？
烦请看一下这个帖子的解决方案，是否有参考价值？
好的，我看下 不过感觉他这个跟我好像不是1个问题 谢谢~
Go Duration 类型最粗粒度只支持到小时，如果要设置 31 天话，可以设置为 744h
type Duration int64
const (
Nanosecond Duration = 1
Microsecond = 1000 * Nanosecond
Millisecond = 1000 * Microsecond
Second = 1000 * Millisecond
Minute = 60 * Second
Hour = 60 * Minute
)
另外问下，为什么需要将 gc life time 设置为 31 天，GC 保留时间设置过程，会导致存在过多的版本数据，会影响 SQL 查询的效率。
您好，我们的业务场景，对数据的删除、修改 很少。 大部分是数据插入，查询。
设置为31天的目的是因为，我们数据量大，并且集群sync-log没有开启（开启sync-log会导致所有tikv IO非常高，所以关闭了），所以目前集群采用BR进行数据备份， 备份方案是：每月1号全量备，然后1号后每天基于1号的全量做 增量备份。所以才设置了31天。
请问下：我们的业务场景，会导致gc数据非常多吗？我观察了几天 感觉内存/硬盘 容量都没有明显变化。
新插入数据，会存储为gc数据吗？
数据的删除和修改很少的话，那么 GC 的数据是很少的。GC 的数据是已经通过业务删除或者更新的数据，看描述这部分数据是很少的，所以磁盘容量变化不大是正常的。GC 时间的设置可以按照上面同学讲的，将 31d 转成 744h 试下。
1 个赞
对的，按照现在的设置，从 6.2 开始算， 31 天之后开始真正的 GC。
好的，谢谢~
好的 