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 使用环境`】生产\测试环境
【 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 个赞

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

1 个赞

个人猜测,你上面是不同的问题,你可以用 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 个赞

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

1 个赞

没prune?

1 个赞

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

1 个赞

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

1 个赞

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清理

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

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

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

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

我看了下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信息里呢?

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