TiKV扩缩容场景下的TiKV异常，寻找已下线的store节点["request failed"] [err_code=KV:PD:gRPC] [err="Grpc(RpcFailure(RpcStatus { code: 2-UNKNOWN, message: \"invalid store ID 1, not found\", details: [] }))"]

🪐 TiDB 技术问题 部署&运维管理
1

【 TiDB 使用环境`】生产\测试环境
【 TiDB 版本】仅使用PD TiKV 版本 5.2.3
【遇到的问题】
线上环境集群构成如下：
3PD 3TiKV 没有使用TiDB
问题场景：
向集群中水平扩容一个TiKV节点 到4个TiKV实例
使用pd-ctl store delete 移除一个原有TiKV节点 id=1
等待store 1 迁移完leader region 状态转为tombstone
执行remove-tombstone将该节点从集群中移除
此时PD查看store状态为 3 TiKV UP
停止已下线节点TiKV实例进程回收磁盘资源

此时：
从现有其他存活TiKV实例的日志中可以看到如下类型错误
1.
[2022/04/20 11:41:54.719 +08:00] [ERROR] [store.rs:622] [“handle raft message failed”] [err_code=KV:Raftstore:Unknown] [err=“Other(”[components/raftstore/src/store/fsm/store.rs:1547]: [region 9642] region not exist but not tombstone: region { id: 9642 start_key: 6C696768746E696EFF672D736B2D746573FF743A3030303A4D3AFF3230323230343230FF3130343735363137FF3031373132313430FF3739393736333035FF3931000000000000F9 end_key: 6C696768746E696EFF672D736B2D746573FF743A3030303A4D3AFF3230323230343230FF3130343735363137FF3031373132313430FF3739393737373135FF3736000000000000F9 region_epoch { conf_ver: 13 version: 17 } peers { id: 9643 store_id: 4 } peers { id: 9644 store_id: 6 } peers { id: 9645 store_id: 8 } }")"] [store_id=4]

[2022/04/20 12:24:19.836 +08:00] [ERROR] [raft_client.rs:712] [“connection abort”] [addr=10.101.129.229:23000] [store_id=1]

[2022/04/20 12:24:19.837 +08:00] [ERROR] [util.rs:460] [“request failed”] [err_code=KV:PD:gRPC] [err=“Grpc(RpcFailure(RpcStatus { code: 2-UNKNOWN, message: “invalid store ID 1, not found”, details: [] }))”]

[2022/04/20 12:24:19.853 +08:00] [ERROR] [util.rs:469] [“reconnect failed”] [err_code=KV:PD:Unknown] [err=“Other(”[components/pd_client/src/util.rs:306]: cancel reconnection due to too small interval")"]

我认为其中错误日志1属于正常现象，而后续sync_request错误的同时会较为严重影响集群读写时延，且从PD监控中可以看到operator执行时间严重变大。

【复现路径】做过哪些操作出现的问题
经过线上和测试环境复现验证，对TiKV扩缩容就会出现如上问题。
其中可能有影响的其他因素为：
扩缩容过程中为加速节点上线、下线
对 replica-schedule-limit，max-pending-peer-count 以及 max-snapshot-count
下线前增加evict-leader-scheduler到待下线节点将leader全部迁走

但经过测试验证，仅执行store delete等待默认参数下的调度均衡，然后移除TiKV节点同样会出现该问题。
【问题现象及影响】
现象：
1.集群中TiKV节点向已移除节点发送大量请求，对应如上错误日志
2.读写峰刺增大 operator执行变慢

是否TiKV扩缩容操作不正确，劳烦解答

1 个赞
2

你没有进行强制上下线？都是正常下线操作吗？

1 个赞
3

个人猜测，你上面是不同的问题，你可以用 jq 命令（官网直接搜 jq 就行），找一下 还有没有store 1 的 region peer（这是看 store 1 not found 错误的），至于 region not found 错误，只能看 pd 和 tikv 日志了（直接 按照 时间 grep 9642 pd.log /tikv.log就OK）
– store 1 的问题，感觉不会影响使用（记得你的版本也早没这个问题了才对，以前有这个问题）
– region not found 问题，需要先看看日志了（大概率是正常的。分裂了）

1 个赞
4

都是正常的下线操作
在回收节点前都确保，pd-ctl查看到store 对应状态已经转为tombstone 并执行remove-tombstone
对应id 的store 在pd-ctl中不存在后进行的回收

1 个赞
5

没prune?

1 个赞
6

这个是没有的，没有使用TiDB因而没有使用tiup
使用pd-ctl不能替代prune吗？

1 个赞
7

prune 和 remove tombstone 差不多，我觉得你可以看看 request 时，读写延迟上升时的 SQL 执行详情，类似场景，我建议哪具体的问题来分析（比如具体慢日志或具体 operator）

1 个赞
8

TiKV 和 TiFlash 的下线是异步的，整个过程会分为多个环节，大致流程如下：
1、使用 tiup cluster scale-in 命令通过 PD API 开始下线流程，此操作仅是一个“ 触发开关”，API 成 功返回仅代表开始下线。
2、PD 在通过 API 收到下线请求后，会触发下线流程，首先会将对应的 Store 的状态从 Up —> Offline。
3、 对应的 Store 在状态变为 Offline 后，会开始：
・ 将其上的 leader 转移到其他 Store（Evict leader，由 TiUP 手动添加）
・ 将其上的 Region 转移到其他 Store
4、 在当前 Store 的 Region 全部被驱逐完毕后，PD 会将对应 Store 的状态从 Offline —> Tombstone
5、 过程中可以使用 tiup cluster display 命令查看下线节点的状态，等待其变为 Tombstone
6、 使用 tiup cluster prune 命令清理 Tombstone 节点，该命令会执行以下操作：
・ 停止已经下线掉的节点的服务
・ 清理已经下线掉的节点的相关数据文件
・ 更新元数据信息和集群拓扑，移除已经下线掉的节点

这是之前技术月刊上一篇文章描述的。 经常碰到的情况是prune之后 tiup里的看不到，但grafana监控显示tombstone，然后使用remove tombstone清理

9

我后续会在测试环境模拟一下，主要看看下线节点region peer
慢日志这部分因为我们tikv上层是类似redis-proxy对redis的支持，目前还不能提供慢日志
operator可以看到发生该异常期间 AddLearner AddPeer 这种需要发送snapshot的从监控中看到finish duration可以达到4分钟以上

10

感谢，由于没有使用tiup而是将该流程自行运维，暂时没有感受到“经常碰到的情况是prune之后 tiup里的看不到，但grafana监控显示tombstone，然后使用remove tombstone清理”这一现象。从pd中获取store节点的tombstone状态目前感觉没有leader_count region_count清零不能下线的还算比较正常。

11

我理解是 2 个问题，想确认下这帖子是否可以关闭

  1. 相关报错是否有问题，结论应该是不影响使用是吧？
  2. 对于发送 snapshot 略慢的现象有优化吗？
12

我看了下tikv对应位置的代码，关于问题：错误信息中含有向已下线的节点store id 的request
可以看到在send msg中从msg的to_peer获取store id
其中的resolve store id即使是 tombstone 也会报错，而观察日志中仅有
request failed”] [err_code=KV:PD:gRPC] [err=“Grpc(RpcFailure(RpcStatus { code: 2-UNKNOWN, message: “invalid store ID 1, not found”, details: [] }))”]
整个过程中没有 Err(pd_client::Error::StoreTombstone(_))对应的错误信息

所以，是否可以认为pd-ctl查询到tombstone，执行remove-tombstone只是删除了pd维护的StoresInfo中对应id，并没有作用于tikv集群的raft信息里呢？

13

在执行store remove-tombstone的时候region --jq=".regions[] | {id: .id, peer_stores: [.peers[].store_id] |select(any(.==(1)))}"
已确认没有peer落在待下线节点上

14

一样的问题，版本5.0.0.下线tikv使用pdctl delete待store状态变为tombstone后,执行remove tombstone,监控看store都正常，但是tikv日志中大量报错rpc 到已经下线的store 下线时已确认所有store均变为tombstone ，并且上面leader count .region count为0，

15

老哥，你这个tikv 的问题搞定了吗