【TiDB 使用环境】生产环境
【TiDB 版本】v7.5.5
【操作系统】
【部署方式】物理机
【集群数据量】
【集群节点数】
【问题复现路径】
【遇到的问题：问题现象及影响】
tidb_gc_life_time默认10min。但是从发现线上问题开始，直到想要使用 flashback 功能可能已经来不及了，gc已经过了。如果想要扩大 flashback 的可恢复范围，又对集群的性能影响较小，tidb_gc_life_time建议设置为多大合理？
【资源配置】
【复制黏贴 ERROR 报错的日志】
【其他附件：截图/日志/监控】
可以先设成30分钟
后面再慢慢调整
我们是用的默认10min。应该从源头管控危险脚本，不能存在侥幸心理。
源头管控是要做的。但是还是想要把安全隐患优化到最小
我们这个集群40多TB，每天写入量不少，设置的是2天（防止周末有人误操作了周一还能快速回滚），目前没发现有明显性能问题，不过不建议设置的太大了，不然磁盘也是个问题。
可以的
越多的范围统计查询，影响会越大，查询没那么多，写多，小点查，影响不大的
测试1天，生产7天
都是从保守的角度考虑，48h，给业务有个缓冲
考虑的很周到，最后一道防线
2天，有点长了，对于增删改多的表sql效率不会有影响吗？
数据可恢复性（Flashback 窗口）和 集群性能 / 存储空间 之间找到平衡，没有绝对值吧，看你个人需求
赞一个，这才是考虑问题的正确思路，我们基本就是设的半个小时
先设置大点，有影响再调小
没什么影响，我们这个集群每天的写入量是很大的，类似物联网那种数据会很多。之前为了做灾备集群同步数据临时改成过5天，也没有明显的延迟
先设置30分钟，后期慢慢调整
其实影响不大
延迟不大的
源头控制