tidb_gc_life_time设置多大合适

🪐 TiDB 技术问题 部署&运维管理
1

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】5.0.0
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
请问tidb_gc_life_time设置多大比较合适，谢谢！
【资源配置】
【附件：截图/日志/监控】

2

看业务，根据实际情况设置，太长会占用过大的空间，太短很多历史变更数据可能就查不到了

3

根据业务调整试试，但是不要太长，会引起性能问题

4

你改这个参数的需求是什么？没有需求就别改

5

整体修改删除多的，以记录状态为主的，就要设置短一点。
整体插入多的，以记录操作日志为主的，就可以长一点。

和你的机器性能也有关系。
反正我的机器性能不行，就用10分钟了，而且就我管理这个库。有10-20m的flashback，基本足够覆盖我自己的操作失误。

6

如果是新库灌入数据的话，建议时间放长一些，20-30分钟，灌完数据后，再改回来！
业务频繁更改的话，5-10分钟吧
具体还要看模块节点配置等

7

防止右人误删了还可以把数据还原

8

tidb_gc_life_time 从 v5.0 版本开始引入

  • 作用域：GLOBAL
  • 是否持久化到集群：是
  • 类型：Duration
  • 默认值：10m0s
  • 范围：[10m0s, 8760h0m0s]
  • 这个变量用于指定每次进行垃圾回收 (GC) 时保留数据的时限。变量值为 Go 的 Duration 字符串格式。每次进行 GC 时，将以当前时间减去该变量的值作为 safe point。

注意

  • 在数据频繁更新的场景下，将 tidb_gc_life_time 的值设置得过大（如数天甚至数月）可能会导致一些潜在的问题，如：
    • 占用更多的存储空间。
    • 大量的历史数据可能会在一定程度上影响系统性能，尤其是范围的查询（如 select count(*) from t）。
  • 如果一个事务的运行时长超过了 tidb_gc_life_time 配置的值，在 GC 时，为了使这个事务可以继续正常运行，系统会保留从这个事务开始时间 start_ts 以来的数据。例如，如果 tidb_gc_life_time 的值配置为 10 分钟，且在一次 GC 时，集群正在运行的事务中最早开始的那个事务已经运行了 15 分钟，那么本次 GC 将保留最近 15 分钟的数据。
9

默认的就可以

10

那要看你们的响应速度，这个时间不能设置太长会影响数据库性能。

11

我看到大部分的社区用户一般设置 10分钟

12

比如：
维护人员，误操作删除了数据，2小时之后，业务侧才发现，那tidb_gc_life_time 要是 设置3小时，数据就闪回了，这样的话数据旧版本就比较多了，在查询使用当中，性能会损失些。

主要还是看业务，还有恢复时间等吧

13

我们是设置1小时，10分钟可能误删了数据不一定来得及操作或者发现不了。不过主要还是看数据更新的频率和磁盘，多少会影响点性能，我见过最大的是设置1天。

14

看需求，我计划设置24小时或者48小时，我们库insert为主，update不多 delete没有所以 mvcc副本多了没影响

15

24小时，挺大啊，你们，不 select 么，，，要是 经常范围查的话，就损耗性能了

16

影响select就看update和detele导致的 mvcc版本多少了，能保证update和detele少就能解决这个问题

17

恩呢，那阔以滴。还是要看业务了 :blush:

18

看成tikv了

tikv_gc_life_time | 1h

19

我觉得24小时合适，但是默认是10分钟，10分钟很难发现问题

20

我们一直用的默认值，硬件跟不上的时候，设置的太长会影响性能。

1 个赞