- 【TiDB 版本】：3.1.0.beta.2
- 【问题描述】：调大gc时间到10小时然后全程进行压测 发现磁盘空间只是上涨了一段时间 然后趋于平衡
如下图调大gc时间到10小时
然后进行压测 观察到tikv容量只是上涨了一段时间 然后趋于平衡 在整个压测过程中 gc的快照版本应该都保留下来 空间应该是一直往上涨的吧 ？但是现在看到上涨了一段时间 然后趋于平衡
然后进行压测 观察到tikv容量只是上涨了一段时间 然后趋于平衡 在整个压测过程中 gc的快照版本应该都保留下来 空间应该是一直往上涨的吧 ？但是现在看到上涨了一段时间 然后趋于平衡
1、确认下压测的语句是 insert + select 类型吗？
如果是 insert 完成之后 select ，在压测过程中如果没有数据的删除、更新以及表的清理，那么数据都不会被 GC 掉，反映在磁盘空间波动不大。
2、有数据删除，GC 变化不大，麻烦看下 GC leader 是否正常
查询 mysql.tidb 表，确定 gc leader 节点位置，more tidb.log |grep ‘gc_worker’
混合型的 insert update delete select 都有
2、有数据删除，GC 变化不大，麻烦看下 GC leader 是否正常
查询 mysql.tidb 表，确定 gc leader 节点位置，more tidb.log |grep ‘gc_worker’
gc leader上没看到有什么报错信息
insert 和 delete 都有，那么经过 GC 之后磁盘空间大小变化不大是符合预期的。有数据增量，又有数据被 GC掉，在磁盘空间上表现为空间使用率变化不大是可能的。还有，因为 GC 时间已经调整成 10 小时，那么在 tikv_gc_safe_point 对应的值基础上加上 10 小时就是下次执行 GC 的时间，可以观察下是否有磁盘空间变化。
再请教一个问题 如果我设置gc时间为10小时 然后进行br备份 在备份过程中 不管是否有update和delete 应该都不会gc数据吧
GC 过程是会影响 BR 备份的。在进行 BR 备份的时候，建议首先根据数据量预估下备份时间，然后调整 GC 时间。参考文档：https://pingcap.com/docs-cn/dev/reference/tools/br/br/#使用-br-进行备份与恢复