TIKV 节点实例挂掉恢复

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:

【TiDB 版本】4.0GA

【问题描述】

11111

架构如上图。问题描述:由于node4节点的TiKV1-2实例磁盘出现故障,导致TiKV1-2挂掉,现在已更换磁盘。请问怎么才能恢复TiKV1-2实例呢?

可以按照先缩容再扩容的流程操作,参考文档
https://docs.pingcap.com/zh/tidb/stable/scale-tidb-using-tiup

好的 我研究下。这个文档也适用单机多实例的情况吧?

适用的,如果文档不完善的地方,欢迎提意见

疑问如下:
1:刚通过文档进行缩容执行:tidb>$ resources/bin/pd-ctl -u “http://172.16.10.3:20182” store
Failed to get store: Get http://172.16.10.3:20182/pd/api/v1/stores: dial tcp 172.16.10.3:20182: connect: connection refused 错误

2:通过Grafana发现已经没有了node4节点的TiKV1-2实例监控,是不是可以不用进行缩容操作呢? 是否可以直接进行扩容呢?

3:是不是需要对node4整个节点进行缩容然后再进行扩容,不能对单个实例进行缩容和扩容。

  1. pd-ctl -u 指定的 pd 的 ip 以及端口
  2. 建议走完完整缩容步骤再扩容
  3. 可以针对单个实例进行扩缩容的

已经处理好了,谢谢两位大佬指点:grin:

:handshake::handshake::handshake:

对node4节点的TiKV1-2实例重新扩容之后发现tikv日志一直报之前172.16.10.3:20172端口错误(初始化文件中已经注释了这个端口),扩容的新端口是20173。错误如下:
[2021/03/03 16:40:05.583 +08:00] [WARN] [raft_client.rs:296] [“RPC batch_raft fail”] [err=“Some(RpcFailure(RpcStatus { status: 14-UNAVAILABLE, details: Some(“failed to connect to all addresses”) }))”] [sink_err=“Some(RpcFinished(Some(RpcStatus { status: 14-UNAVAILABLE, details: Some(“failed to connect to all addresses”) })))”] [to_addr=172.16.10.3:20172]
[2021/03/03 16:40:05.591 +08:00] [WARN] [raft_client.rs:199] [“send to 172.16.10.3:20172 fail, the gRPC connection could be broken”]
[2021/03/03 16:40:05.591 +08:00] [ERROR] [transport.rs:163] [“send raft msg err”] [err=“Other(”[src/server/raft_client.rs:208]: RaftClient send fail")"]

pd-ctl -u 指定的 pd 的 ip 以及端口看下各个 store 的状态是不是正常

从TIDB Dashboard监控上看都是正常的。上面报错的端口是已经下线了的实例,疑问是为啥还会不断去连已经下线的这个端口呢?

172.16.10.3 这个 ip 不是对应的 pd 节点,是更早之前部署的 tikv 实例吗,可以查查日志是什么时候开始报的

旧点节点我已经使用pd-ctl delete了并且状态也是offline。是之前tikv实例。最近两周吧!昨天才更换好磁盘,重新做了扩容。现在不知道为什么还会去连旧的实例端口:joy:

offline 的话还没有完成下线流程,这个 store instance 是启动的吗,目前应该在补副本,需等待 region count 降到 0 并且状态变成 tombstone。

没有启动,这个实例已经完全废了,因为这个实例的磁盘坏了。更换新的磁盘后新部署了一个实例在新盘上端口由20172变成20173了。有没有办法清除旧的实例的region count 。看错误是没有办法连接上旧的实例端口,才导致tikv内部一直刷连接错误的日志。

通过

curl -X POST http://{pd_ip}:{pd_port}/pd/api/v1/store/${store_id}/state?state=Tombstone

状态变成了Tombstone,但是region count数据有办法清除吗?:joy:

这个命令慎用吧,可能导致副本丢失,可以查一下当前的 pd 监控 region health 面板有没有异常的 region

嗯,应该是我第一次操作缩容和扩容不规范,导致了旧的实例信息没有清除干净,出现了现在的一些问题。执行了curl -X POST http://{pd_ip}:{pd_port}/pd/api/v1/store/${store_id}/state?state=Tombstone和pd-ctl store remove-tombstone操作后又出现了[2021/03/04 09:30:23.518 +08:00] [ERROR] [util.rs:327] [“request failed”] [err=“Grpc(RpcFailure(RpcStatus { status: 2-UNKNOWN, details: Some("invalid store ID 6, not found") }))”]错误。

pd 监控 region health 信息:

报错的 store 6 就是之前下线了的 store 吧,下线时是还有 region 的副本在这个 store 上,可以用 pd-ctl 导出当前的 store 以及上面看到的异常 region check down-peer/pending-peer

报错的 store 6 就是之前下线了的 store 吧 ----> 是的。
下线时是还有 region 的副本在这个 store 上,可以用 pd-ctl 导出当前的 store 以及上面看到的异常 region check down-peer/pending-peer ---->这个有点不是很明白,能否给下命令呢?谢谢。通过resources/bin/pd-ctl -u “http://IP:2379” store命令没有看到相关信息。
‘’’
[2021/03/04 09:30:23.518 +08:00] [ERROR] [util.rs:327] [“request failed”] [err=“Grpc(RpcFailure(RpcStatus { status: 2-UNKNOWN, details: Some(“invalid store ID 6, not found”) }))”]
‘’’’
这个错误重启tidb集群能解决吗?