Tispark分批次读取tikv,多个批次后报错send tikv request error: UNAVAILABLE, try next peer later

  • 【TiDB 版本】:3.0.2

  • 【问题描述】:tispark分批次读取tikv,多个批次后报错send tikv request error: UNAVAILABLE, try next peer later,tikv日志报错peer is not leader

    errorlog.txt (22.6 KB)

tikv 节点有发生重启吗

没有重启过

麻烦提供一下 tispark 的版本以及 spark 版本

// 获取spark版本 org.apache.spark.SPARK_VERSION // 获取SparkConfig sc.getConf.getAll.foreach(println) // 获取TiSpark版本 spark.sql(“select ti_version()”).show(false)

spark是2.4.4,tispark是2.1.5-spark_2.4

从日志来看是 tikv 节点没有连接上,能提供一下 tikv 节点的日志吗

这个节点的日志:tikv.20191119.log (841.9 KB)

看了下 tispark 报错是在19号上午7点,这个tikv日志开始时间是在19号15点开始的

可以 grep Welcome 关键字看下 tikv 节点有没有重启

看了下日志,某个 region 处于 peer is not leader 的状态。

[err=“region message: “peer is not leader for region 144616, leader may Some(id: 144618 store_id: 4)” not_leader { region_id: 144616 leader { id: 144618 store_id: 4 } }”]

这种情况一般是某个 tikv 挂掉。

可以 dmsg 看一看 tikv 挂掉的原因,如果是 tikv oom 类的错误,可以限制一下 spark 的内存使用。

用的是spark on k8s 模式,并不在tidb集群内,spark 内存使用影响不到tikv。我还是把storage.block-cache.capacity给小一点吧

请问参数调整之后,还有相同的情况出现吗

不好意思,昨天调整完之后,其他同事再忙别的事情,没用应用spark服务,没有测试···

好的,后续有问题的话可以继续反馈

还有一个疑问,这里tikv某个节点被kill之后,难道不会去重试其他tikv节点吗?

根据从缓存或者 PD 拿到的 region 信息,确认数据在该节点之后,当节点异常被 kill 不会去重试其他节点。

昨天夜里测试了一下,缩小tikv storage.block-cache.capacity后,没有发生这个情况了

:+1::+1::+1: