应用服务器log过多报GC life time is shorter than transaction duration

[jim (jim99)]

捡取了几个tidb的SQL log [2019/08/20 08:56:45.952 +08:00] [INFO] [session.go:1847] [GENERAL_LOG] [conn=19769] [user=@172.31.100.222] [schemaVersion=1290] [txnStartTS=410586281263497227] [2019/08/20 09:50:13.072 +08:00] [INFO] [session.go:1847] [GENERAL_LOG] [conn=19769] [user=@172.31.100.222] [schemaVersion=1290] [txnStartTS=410586281263497227] WHERE ( member_id = 364091 and type = ‘T_ES’ ) limit 1"] [2019/08/20 09:50:13.073 +08:00] [WARN] [conn.go:666] [“dispatch error”] [conn=19769] [connInfo=“id:19769, addr:172.31.100.222:43008 status:1, collation:utf8_general_ci”] [sql=" WHERE ( member_id = 364091 and type = ‘T_ES’ ) limit 1"] [err="[tikv:9006]GC life time is shorter than transaction duration, transaction starts at 2019-08-20 08:52:44.439 +0800 CST, GC safe point is 2019-08-20 08:53:10.589 +0800 CST"]

使用的开发语言java,框架mybatis springBoot1.5

[jim (jim99)]

补充下tidb集群的版本为3.0.1 GC参数如下 tikv_gc_run_interval=30m0s tikv_gc_life_time=30m

[小王同学]

GC Life Time 间隔时间过短，长事务本应读到的数据可能被清理了，可使用如下命令增加 GC Life Time ：

update mysql.tidb set variable_value='30m' where variable_name='tikv_gc_life_time';

其中 30m 代表仅清理 30 分钟前的数据，这可能会额外占用一定的存储空间。可根据业务情况，适当调大 gc time

https://pingcap.com/docs-cn/v3.0/faq/tidb/#9-1-7-error-9006-hy000-gc-life-time-is-shorter-than-transaction-duration

[jim (jim99)]

在tidb-server的GENERAL.LOG中标记事务号为txnStartTS=0的SQL是否代表这条语句并不在一个事务中？

[小王同学]

测试了一下，可以这样理解。