tikv频繁down,查看日志提示rpc相关错误

该问题在https://asktug.com/t/topic/63007有提出,但是没有后续回答。


该问题通过重启机器可以暂时解决,但后续又会出现

  1. 集群是什么版本的?
  2. tikv down 是状态显示为 down ,但是进程还是存在么?

https://github.com/tikv/tikv/pull/8612 可能和这个有关

可以考虑升级到 v4.0.13 观察一下

好,后续我们再继续观察一下看是否需要升级集群

:handshake::handshake::handshake:

执行 nohup tiup cluster upgrade test-cluster v4.0.13 --transfer-timeout 10000,报错如图


以下有两个问题:
1、这是因为kv上的leader太多10000秒都不够迁移导致的吗,还是说迁移过程中出现了错误导致卡住,不是时间问题?
2、官方文档说添加force参数可以跳过leader迁移,并且说这样会对集群性能造成影响,具体影响多大,针对现在的情况是否要使用force完成升级

  1. 这个最好是在迁移过程中,通过 pd-ctl 执行 store 命令来确认当时的迁移情况,如果是有少数几个 region leader 迁移不走的话,需要具体检查几个 region 的状态
  2. 添加 force 参数会不迁移 leader 直接停止 tikv 节点,对于 TiDB 访问的时候,会出现 not leader 的 backoff 重试,这个重试是自动的,对于应用层的感知应该是部分 SQL 执行变慢,但是具体多大影响,这个与 SQL 设置的 region 数量,region 大小,当时的情况等都有影响,无法给出具体影响数据。

您好,关于第二点,是否可以理解为,使用force参数升级完集群后,集群中会出现部分region没有leader,这时调度会自动执行leader选举,等leader调度完成后,集群就恢复正常了?

不是升级完集群后会有部分 region 没有 leader
是 force 的话,会直接停止 tikv 实例,也就是对应 leader 在该实例上的 region 会直接失去 leader ,需要等待重新选举出新的 leader 对外提供服务。在没有选举出 leader 的时候,应用访问到了对应的 region 的话,会出现 not leader 的 backoff ,知道 backoff 等到新 leader 选举出现,完成访问。

嗯嗯,就是force命令执行完成后需要等待选出leader才能正常提供服务,我们内部商量一下看是否要用。

您好,执行未加force命令的upgrade后,现在日志卡在如图情况


通过store命令发现该leader在236节点上
“store”: {
“id”: 24478148,
“address”: “10.12.5.236:20160”,
“version”: “4.0.13”,
“status_address”: “10.12.5.236:20180”,
“git_hash”: “a448d617f79ddf545be73931525bb41af0f790f3”,
“start_timestamp”: 1623233030,
“deploy_path”: “/home/tidb/deploy/bin”,
“last_heartbeat”: 1623317636576720669,
“state_name”: “Up”
},
“status”: {
“capacity”: “5.952TiB”,
“available”: “3.444TiB”,
“used_size”: “1.846TiB”,
“leader_count”: 7,
“leader_weight”: 2,
“leader_score”: 3.5,
“leader_size”: 636,
“region_count”: 62835,
“region_weight”: 2,
“region_score”: 2749226,
“region_size”: 5498452,
“start_ts”: “2021-06-09T10:03:50Z”,
“last_heartbeat_ts”: “2021-06-10T09:33:56.576720669Z”,
“uptime”: “23h30m6.576720669s”
}
},

执行region --jq=".regions[] | {id: .id, leader_store_id: .leader.store_id | select(.==24478148) }"命令结果如下

{“id”:80616381,“leader_store_id”:24478148}

{“id”:80950046,“leader_store_id”:24478148}

{“id”:248731054,“leader_store_id”:24478148}

{“id”:359185,“leader_store_id”:24478148}

{“id”:6963497,“leader_store_id”:24478148}

{“id”:112293,“leader_store_id”:24478148}

{“id”:93992158,“leader_store_id”:24478148}

对每个region查看具体情况如下
region 80616381
{
“id”: 80616381,
“start_key”: “7480000000000204FFF75F728000000005FFE80F6E0000000000FA”,
“end_key”: “7480000000000204FFF75F728000000005FFEA52750000000000FA”,
“epoch”: {
“conf_ver”: 18585,
“version”: 52318
},
“peers”: [
{
“id”: 245278358,
“store_id”: 24478148
},
{
“id”: 246648589,
“store_id”: 38833310
},
{
“id”: 268592857,
“store_id”: 24590972
}
],
“leader”: {
“id”: 245278358,
“store_id”: 24478148
},
“written_bytes”: 0,
“read_bytes”: 0,
“written_keys”: 0,
“read_keys”: 0,
“approximate_size”: 97,
“approximate_keys”: 163840
}

» region 80950046
{
“id”: 80950046,
“start_key”: “7480000000000204FFF75F728000000025FF64E9AC0000000000FA”,
“end_key”: “7480000000000204FFF75F728000000025FF670E300000000000FA”,
“epoch”: {
“conf_ver”: 18603,
“version”: 55903
},
“peers”: [
{
“id”: 80950048,
“store_id”: 24590972
},
{
“id”: 248315125,
“store_id”: 24478148
},
{
“id”: 484725795,
“store_id”: 24480822
}
],
“leader”: {
“id”: 248315125,
“store_id”: 24478148
},
“pending_peers”: [
{
“id”: 484725795,
“store_id”: 24480822
}
],
“written_bytes”: 0,
“read_bytes”: 0,
“written_keys”: 0,
“read_keys”: 0,
“approximate_size”: 97,
“approximate_keys”: 158669
}

» region 248731054
{
“id”: 248731054,
“start_key”: “7480000000000001FF745F728000000025FF3F4CCB0000000000FA”,
“end_key”: “7480000000000001FF745F728000000025FF3F606B0000000000FA”,
“epoch”: {
“conf_ver”: 63807,
“version”: 19744
},
“peers”: [
{
“id”: 248731055,
“store_id”: 24478148
},
{
“id”: 248731057,
“store_id”: 38833310
},
{
“id”: 315144887,
“store_id”: 24590972
}
],
“leader”: {
“id”: 248731055,
“store_id”: 24478148
},
“written_bytes”: 0,
“read_bytes”: 0,
“written_keys”: 0,
“read_keys”: 0,
“approximate_size”: 137,
“approximate_keys”: 0
}

» region 359185
{
“id”: 359185,
“start_key”: “7480000000000001FFF15F698000000000FF0000020131353735FF37383838FF323100FF0000000000F90380FF0000000003FEFA00FE”,
“end_key”: “7480000000000001FFF15F698000000000FF0000020131353736FF30383939FF343600FF0000000000F90380FF00000000A3C7D600FE”,
“epoch”: {
“conf_ver”: 953,
“version”: 2859
},
“peers”: [
{
“id”: 24488100,
“store_id”: 24478148
},
{
“id”: 115818100,
“store_id”: 38833310
},
{
“id”: 268660874,
“store_id”: 24590972
}
],
“leader”: {
“id”: 24488100,
“store_id”: 24478148
},
“written_bytes”: 251,
“read_bytes”: 0,
“written_keys”: 1,
“read_keys”: 0,
“approximate_size”: 77,
“approximate_keys”: 1067125
}

» region 6963497
{
“id”: 6963497,
“start_key”: “7480000000000001FF745F728000000010FF85586A0000000000FA”,
“end_key”: “7480000000000001FF745F728000000010FF85D7110000000000FA”,
“epoch”: {
“conf_ver”: 1481,
“version”: 8276
},
“peers”: [
{
“id”: 248506405,
“store_id”: 38833310
},
{
“id”: 249024553,
“store_id”: 24478148
},
{
“id”: 330268746,
“store_id”: 24480822
}
],
“leader”: {
“id”: 249024553,
“store_id”: 24478148
},
“pending_peers”: [
{
“id”: 330268746,
“store_id”: 24480822
}
],
“written_bytes”: 0,
“read_bytes”: 0,
“written_keys”: 0,
“read_keys”: 0,
“approximate_size”: 78,
“approximate_keys”: 0
}

» region 112293
{
“id”: 112293,
“start_key”: “7480000000000001FF745F728000000005FF04BF420000000000FA”,
“end_key”: “7480000000000001FF745F728000000005FF04FB3B0000000000FA”,
“epoch”: {
“conf_ver”: 908,
“version”: 3548
},
“peers”: [
{
“id”: 246079850,
“store_id”: 38833310
},
{
“id”: 248331895,
“store_id”: 24478148
},
{
“id”: 326423698,
“store_id”: 24590972
}
],
“leader”: {
“id”: 248331895,
“store_id”: 24478148
},
“written_bytes”: 0,
“read_bytes”: 0,
“written_keys”: 0,
“read_keys”: 0,
“approximate_size”: 49,
“approximate_keys”: 40960
}

» region 93992158
{
“id”: 93992158,
“start_key”: “7480000000000204FFF75F698000000000FF0000010130783437FF39643336FF656363FF6435653862FF6264FF633937646331FF39FF38653232383933FFFF3164393331333538FFFF65646236346137FF31FF643630326438FF3937FF3363393837FF656664FF64320000FF00000000F9000000FC”,
“end_key”: “7480000000000204FFF75F698000000000FF0000010130783437FF65313838FF666133FF3739303061FF3035FF333564326137FF35FF35333231613935FFFF3339666634623961FFFF65623362313832FF39FF383865313138FF3834FF6364663366FF323066FF64640000FF00000000F9000000FC”,
“epoch”: {
“conf_ver”: 18585,
“version”: 51663
},
“peers”: [
{
“id”: 99404516,
“store_id”: 38833310
},
{
“id”: 160011777,
“store_id”: 24478148
},
{
“id”: 318613622,
“store_id”: 262397455
}
],
“leader”: {
“id”: 160011777,
“store_id”: 24478148
},
“written_bytes”: 0,
“read_bytes”: 0,
“written_keys”: 0,
“read_keys”: 0,
“approximate_size”: 101,
“approximate_keys”: 732440
}

参考https://asktug.com/t/topic/63377的方法对其中有down和pending的region执行remove-add操作
operator add remove-peer 80950046 24480822
operator add remove-peer 6963497 24480822
发现region状态无变化,升级进度也未推进,但监控显示236的leader数量已经降到0

另外,通过在236机器上执行类似于grep ‘80616381’ tikv.log 发现大量lease is not expired日志,其他region同理
日志如下:
链接: https://pan.baidu.com/s/1amm3q_9ZapAGMeYLBBzp5A 密码: qfds

针对以上情况,请问接下来该如何操作,该集群需要尽快恢复使用,烦请加急处理,谢谢

最新发现,236机器频繁的down的真正原因也许在于oom,通过dmesg -T发现


请问如何解决

看下grafana 的over-view 监控信息,是否 tidb 和 tikv 资源在这个时候有大量使用。
查看 dashboard 的慢日志,按照内存排序,有没有大sql排查下。

集群升级未能成功,导致现在集群中仅有部分节点为4.0.13版本,dashboard的慢查询也无法正常显示



grafana的over-view相关监控信息如图