该sql没进入慢sql。当时的指标看起来除了其中一台TiDB报错暂时未发现问题。
[2020/07/13 09:29:07.278 +08:00] [WARN] [conn.go:684] [“dispatch error”] [conn=2773633] [connInfo="id:2773633, addr:10.204.9.202:52650 status:1, collation:utf8_general_ci, user:uic
“] [command=Query] [status=“inTxn:1, autocommit:0”] [sql=“update uic_user\
SET extend_attr = ‘{“defaultPaymentType”:“1”,“boxShowModeTipTimes”:“1”,“courier_growth_
score”:“7854”,“courier_feature_rank”:“1”,“courier_effective_time”:“20200808”,“boxShowMode”:“2”,“real_name_flag”:“1”,“courier_growth_rank”:“4”,“showBoxTypeMo
dePage”:“1”,“boxShowModeGray”:“2”}’,\
\
\
\
\
\
\
\
\
update_
time = ‘2020-07-13 09:30:13.436’ \
where id = 246881774439772160”] [err=”[tikv:9006]GC life time is shorter than transaction duration, transaction starts at 2020-07-13 09:1
5:03.041 +0800 CST, GC safe point is 2020-07-13 09:19:31.441 +0800 CST
监控时间与报错时间不相符哦~
暂时建议调大 gc life time 并观察会不会再次出现该问题
9:29是这是报错的时间，9:30是业务生成该sql执行的时间。图表中报错也有个9:30在报错。时间是相符的，只是不太明白为什么会拿到9:15的事物时间。这里是有问题的，而且3台TiDB中只有一台会这样。
报错显示 7-13 9:15 获取的 start ts ，当前监控时 7-14 日的监控
[err="[tikv:9006]GC life time is shorter than transaction duration, transaction starts at 2020-07-13 09:1
5:03.041 +0800 CST, GC safe point is 2020-07-13 09:19:31.441 +0800 CST\
可以看下这个 tidb 的时区与其他服务器是否相符。
相符，检查过PD ，TiDB ,TiKV的所有时间，都是通过NTP去获取服务器的时间。至少我查的时候是一样的
暂时建议调大 gc life time 先观察下是否还会出现该问题吧
调大肯定会减少，这个不能解决问题吧。毕竟目前还是测试集群。
调大 gc 时解决此问题的办法，gc 是 tidb 垃圾回收机制，如果不回收会有太多的版本信息需要存储，反之如果回收的过快，会产生类似的问题，调整 gc 也是运维优化 tidb 的手段之一。
https://docs.pingcap.com/zh/tidb/stable/garbage-collection-overview
刚看了下报错，这个错拿开始时间会到50分钟之前，而且还是一批的，就算把gc life time调大了，甚至会拿错时间，这个挺可怕的。比如12:20select拿到的却是11:40的数据，这个在逻辑上是直接错了的，目前正在翻代码看下能不能找出来为啥会拿错时间的问题。
对的呀，就是这个意思，这里是12点20生成sql结果拿到了的start ts是11点40的，而且12点到12点25之间有6万多条sql都拿的start ts是11点40的
如果这些 sql 在一个 begin （事务中），start ts 是相同的，sql 执行时间超过了 gc 的时间，就会被清理掉。可以根据业务看下将 gc life time 设置为 72h？48h？
gc时间是 10分钟，这个是录制出来的流量，不是真实的事物。有可能是begin了之后。commit的语句被分发到其他TiDB了。
所有的报错都是，
status=“inTxn:1, autocommit:0”
理论上autocommit是1。
这是第一条报错
[2020/07/14 12:00:15.448 +08:00] [err="[tikv:9006]GC life time is shorter than transaction duration, transaction starts at 2020-07-14 11:40:24.741 +0800 CST, GC safe point is 2020-07-14 11:49:31.441 +0800 CST
这是最后一条报错
[2020/07/14 12:25:01.101 +08:00] [err="[tikv:9006]GC life time is shorter than transaction duration, transaction starts at 2020-07-14 11:40:24.741 +0800 CST, GC safe point is 2020-07-14 12:09:31.441 +0800 CST
根据日志确认了就是因为begin了之后没关闭导致的。
检查了下，猜想基本准确，同一个连接id为2777161中最早2020-07-14 11:40:24.741附近被改成了状态为inTxn:1, autocommit:0的，之后到11:50还有 一条，而该连接11:50~12:00之间是没有请求进来，所以不存在拿不到数据而报错的。到12点钟进来了之后就发生了。
12:25分最后一条报错之后，该连接在日志中消失，有可能是该连接关闭或者接收到了commit。又能正常执行了
回放时，事务是不是出现变化的，他也不会将一个事务拆分成多个
对的，网卡录制，只能还原独立的语句，无法还原带事务的语句
确定吗，begin commit 语句是怎么回放的？
现象是，中间隔了层nginx，我在检查是不是断开之后nginx复用链接了
可以检查下，但是对于线上业务 begin commit 属于同一个事务，在 tidb 中，是有一致性保障的，回归到本贴的问题。还是需要修改 gc 来解决
嗯，不会有这么大的事物的，也不允许跑这么大事物。这个应该是意外来的
已私信，判断可能是网卡流量回放问题，当前问题需要调整 tikv_gc_life_time 来解决，感谢反馈，如有新的问题欢迎开新帖继续讨论。