GC停止 tikv_gc_last_run_time时间停留在几天前

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 等做数据同步?

烦请看一下这个帖子的解决方案,是否有参考价值?

没有, 用br备份过数据

我过滤了下tidb.log,有以下错误,这是我修改的31d ,有错误吗? 请问31天,或者说1个月该怎么写?

好的,我看下 不过感觉他这个跟我好像不是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赞

改完了,tidb日志有如下 输出,tikv_gc_last_run_time 下一次执行是31天以后是吗? 下面状态是正常的吧?

对的,按照现在的设置,从 6.2 开始算, 31 天之后开始真正的 GC。

好的,谢谢~

好的 :grin: