read tso is smaller than tidb gc safe point

🛸 其他技术问题 TiSpark
1

【概述】 场景 + 问题概述
tispark 写入tikv报错，read tso is smaller than tidb gc safe point

【现象】 业务和数据库现象
写入失败

【 TiDB 版本】
tidb：4.0.13
tispark：2.3.14

【附件】 相关日志及监控（https://metricstool.pingcap.com/)
Caused by: com.pingcap.tikv.exception.SelectException: query id: 793756d8-a188-41e0-ab7a-c33b70f4f45e, read tso: 426219066472267783 is smaller than tidb gc safe point: 426219164343730176: (while creating InputStreams from storage db_691.t_102006, table_id: 102006)
at com.pingcap.tikv.region.RegionStoreClient.doCoprocessor(RegionStoreClient.java:745)
at com.pingcap.tikv.region.RegionStoreClient.handleCopResponse(RegionStoreClient.java:716)
at com.pingcap.tikv.region.RegionStoreClient.coprocess(RegionStoreClient.java:660)
at com.pingcap.tikv.operation.iterator.DAGIterator.process(DAGIterator.java:219)
… 7 more

Driver stacktrace:

image
image2820×850 303 KB

image
image2854×830 504 KB

spark日志：
spark.log (20.3 KB)

image
image1780×774 331 KB

2 个赞
2

gc life time 间隔时间过短，长事务本应读到的数据可能被清理了，可以根据查询时长适当调大 gc 时间，如 SET GLOBAL tidb_gc_life_time = ‘24h’;

3

@qizheng 您好，报错是gf save point 不是gf life time，gc时常是1小时
@yilong 大佬，可以帮忙看下吗 ，调大gc life time估计可以解决，但是感觉不太对

这个的逻辑我看了下，是用tispark读取tidb数据，然后做了一些处理，然后写回tidb另一个表，有个不理解的地方是，读取和spark处理了40多分钟，写入的第一个算子走了30多分钟，就报错了，看着像是读取+写入超过了1小时被gc了，但是不明确的是 前三个算子是读取tidb+处理只花了40分钟，单纯的读取没超过1小时，tidbUtils算子是开始写入了，花了30分钟，按理说应该是读取不超过一小时就行，写入不超过一小时就行，为什么是读取+写入不超过一小时呢？

我理解的是读取本身不超过1小时就可以，这时候数据已经被读到spark集群了，然后写入本身不超过1小时就行，但现在看着不是这么回事

image
image1920×461 32.9 KB

4

再确认下报错的 query id: 793756d8-a188-41e0-ab7a-c33b70f4f45e 是什么时间发起的，日志中它对应的 read tso: 426219066472267783，解析后 2021-07-10 13:58:27.429 +0800，在 gc safe point 2021-07-10 14:04:40.779 +0800 之前

1 个赞
5

是的，日志报错是read tso 小于 gc safe point，但是为啥会出现这样的情况呢，我gc设置了1小时，但是读取只读了20分钟吧(第一个算子读，第三个算子数据已经到spark集群了，跟tidb没关系了吧)

6

第三个算子报错了么，spark 集群也是要访问 tikv 的数据，如果 tidb 触发的 gc 已经清理掉这部分数据，也会受影响

7

job 0,1,2是读tidb数据，然后处理，这个时候数据都在spark内存中或者spark集群的硬盘里了，跟tidb没任何关系了吧，跟gc应该更没关系了，然后job 3是写入的第一个算子，报错了，就说不通了啊

8

job3 的算子是怎么写入的，需要先读 tikv 么，开始多久报错的

9

JOB 0是读取tidb，然后走我们的一些自己的逻辑(job1和2)，这时候数据应该都在内存或磁盘了，计算完后，开始写入tikv(dataframe.write.format tidb 这样写入)，然后报错，运行时间图上有

10

这个事务是 tidb 的，没明白你的意思，应该是在写入数据的时候，检查tso 时间有问题，似乎说的过去吧

11

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。