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

[wfxxh (倔强的蜗牛)]

• 【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)

[GangShen]

tikv 节点有发生重启吗

[wfxxh (倔强的蜗牛)]

没有重启过

[GangShen]

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

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

[wfxxh (倔强的蜗牛)]

spark是2.4.4，tispark是2.1.5-spark_2.4

[GangShen]

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

[wfxxh (倔强的蜗牛)]

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

[GangShen]

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

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

[zhexuany-PingCAP (杨哲轩 - PingCAP)]

看了下日志，某个 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 的内存使用。

[wfxxh (倔强的蜗牛)]

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

[GangShen]

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

[wfxxh (倔强的蜗牛)]

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

[GangShen]

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

[wfxxh (倔强的蜗牛)]

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

[不懂就问 (zhouyueyue)]

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

[wfxxh (倔强的蜗牛)]

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

[张鱼小丸子-PingCAP (zhangyuxiaowanzi)]