tidb闪回保留时间是设置哪个参数
有没有大佬解释下，这个参数都设置的多少，如何合理评估参数设置大小
tidb_gc_life_time这个参数控制可以闪回的时间
生产中我们主要还是考虑极端场景下，DBA要有手段可以快速闪回数据，所以大多数集群设的是48小时。（另外：这些集群全备的时间也基本上是1~3天，全备过程中也是会阻碍gc推进，所以 tidb_gc_life_time设置为48小时并没有额外增加性能消耗）
闪回部分的官方文档说明：
另外一篇官方文档说明：
1 个赞
如果数据很重要，建议 tidb_gc_life_time 设置为24小时到48小时。
评估的话主要看数据update和delete多不多，太多的会导致表里面旧数据量太大，影响sql查询效率
tikv_gc_life_time参数，可以在数据库客户端执行如下命令，具体的时间要视业务场景和实际需求来定，默认10分钟，太久了磁盘存储和集群性能会受影响；太短如果误操作数据来不及处理，所以需要根据数据安全和性能之间做平衡。个人建议做好数据备份，该值可以使用默认值
update mysql.tidb set variable_value=‘60m’ where variable_name=‘tikv_gc_life_time’;
tikv_gc_life_time来控制的，但是保留太久，会导致保留更多的历史版本数据，从而对性能和存储空间造成影响，可以根据实际业务做权衡
- 闪回保留时间的核心参数是
tikv_gc_life_time，TiDB 层配置，控制 GC 版本保留窗口，也是闪回的最大有效时间； - 通用配置值随场景变化：生产 OLTP 30m~2h，开发 / 核心数据 12h~3d，不建议超过 7 天；
-- 设置保留时间为 24 小时
SET GLOBAL tidb_gc_life_time = '24h';
-- 设置保留时间为 10 分钟（默认）
SET GLOBAL tidb_gc_life_time = '10m';
生产环境 ：建议设置为 24h 到 72h （1-3天）。这给了 DBA 足够的时间（例如跨天、跨周末）来发现误操作并进行恢复
话说ticdc会依赖这个 tidb_gc_life_time参数吗？
tidb_gc_life_time=48小时的配置完全适配你的生产场景，核心价值是为 DBA 预留足够的闪回时间窗口，且因全备阻碍 GC 推进，不会额外增加性能消耗；- 关键要确保全备结束后 GC 能正常推进，避免历史数据无限制堆积；
- 48 小时窗口配合全备 + binlog，可覆盖绝大多数极端数据恢复场景。
gclife这种参数设置吧
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。