关于数据库:TiKV-缩容不掉如何解决

56次阅读

共计 5736 个字符，预计需要花费 15 分钟才能阅读完成。

TiKV 节点缩容不掉，通常遇到的状况：

  • 1、常常遇到的状况是：3 个节点的 tikv 集群缩容必定会始终卡着，因为没有新节点承受要下线 kv 的 region peer。
  • 2、另外就是除缩容 tikv 外，剩下的 KV 硬盘应用状况比拟高，达到 schedule.high-space-ratio=0.6 的限度，导致该 tikv 的 region 无奈迁徙。

然而明天要探讨的是：我先执行了扩容，而后再进行的缩容，依然卡着就说不过去了。

问题现场

版本：TiDB v5.2.1 状况阐明：这个 tidb 是有 tiflash 节点的，并且这个集群是一路从 3.X 降级到 5.2.1 版本 问题现场：为了下线一个 3kv 集群中的一个 kv，咱们在 24 号扩容了一个新 kv，而后扩容结束后，下线某个 kv，都过了 2 天，该 kv 还是处于 pending offline 的状态，看监控 leader+reigon 曾经切走了，为啥该 kv 的状态依然没有 tombstone？

下图是扩容和缩容 tikv 的监控，从下图能够发现扩容和缩容都曾经结束了。

问题排查

（1）先看看有缩容问题的 TIKV 节点日志

查看日志发现有：KvService::batch\_raft send response fail 报错，查了下 asktug，发现这些报错指向一个 4.X 的 bug：raft 大小限度的过大，超过 gRPC 传输通信限度导致 raft message 卡住的问题，所以影响了 region 的调度。将 TiKV 集群的 raft-max-size-per-msg 这个配置调小，升高 raft message 大小来看是否能复原 region 调度。

如果其他人的 4.X 版本遇到这个问题能够通过下面形式搞定，然而目前我曾经降级到了 5.2.1，所以下面办法不适宜解决我的这个问题。相干的报错日志如下：

$ grep 'ERROR' tikv.log
[2022/03/28 09:34:38.062 +08:00] [ERROR] [kv.rs:729] ["KvService::batch_raft send response fail"] [err=RemoteStopped]
[2022/03/28 09:34:38.062 +08:00] [ERROR] [kv.rs:729] ["KvService::batch_raft send response fail"] [err=RemoteStopped]
[2022/03/28 09:34:38.227 +08:00] [ERROR] [pd.rs:83] ["Failed to send read flow statistics"] [err="channel has been closed"]
[2022/03/28 09:34:38.261 +08:00] [ERROR] [kv.rs:729] ["KvService::batch_raft send response fail"] [err=RemoteStopped]
[2022/03/28 09:34:38.261 +08:00] [ERROR] [kv.rs:729] ["KvService::batch_raft send response fail"] [err=RemoteStopped]
[2022/03/28 09:34:55.711 +08:00] [ERROR] [server.rs:1030] ["failed to init io snooper"] [err_code=KV:Unknown] [err="\"IO snooper is not started due to not compiling with BCC\""]

（2）查看节点状况，发现该节点除了状态为 Offline 外，leader\_count/region\_count 都为 0，为啥都为 0 了，等了 2 天还是 pending offline？没有变 tombstone？

tiup ctl:v5.2.1 pd -u http://pd-ip:2379 store 5
{
  "store": {
    "id": 5,
    "address": "xxxx:20160",
    "state": 1,
    "version": "5.2.1",
    "status_address": "xxxxx:20180",
    "git_hash": "2c99f317d4ba125b772a8b94a6c3c0eb9d07ac59",
    "start_timestamp": 1648465247,
    "deploy_path": "/data/deploy/bin",
    "last_heartbeat": 1648517045511041818,
    "state_name": "Offline"
  },
  "status": {
    "capacity": "0B",
    "available": "0B",
    "used_size": "0B",
    "leader_count": 0,
    "leader_weight": 1,
    "leader_score": 0,
    "leader_size": 0,
    "region_count": 0,
    "region_weight": 1,
    "region_score": 0,
    "region_size": 0,
    "slow_score": 0,
    "start_ts": "2022-03-28T19:00:47+08:00",
    "last_heartbeat_ts": "2022-03-29T09:24:05.511041818+08:00",
    "uptime": "14h23m18.511041818s"
  }
}

（3）查看有问题 tikv 节点的 region 信息。

后果发现不得了的后果，这个不能胜利下线的 tikv store 5，居然还有一个 id 为 434317 的 region，这个 region 没有 leader，有 3 个 voter(在 store 5、1、4 上) 和 2 个 Learner（在 tiflash store 390553 和 390554 上），并且这 2 个 tiflash store 还是集群降级前 4.0.9 版本的 store id，并且之前对 tikv/tiflash 节点执行过 scale-in –force 等暴力下线的操作，至于该 region 为啥没有选出 leader，一则可能是 bug，二则可能是暴力下线 tikv/tiflash 导致。

也就是说：这个没有 leader 的 region：434317，因为他在 store\_id：5 上还有记录，这个问题成为了妨碍该 tikv 始终卡到 offline 状态无奈胜利下线的起因。

$ tiup ctl:v5.2.1 pd -u http://pd-ip:2379 region store 5
{
  "count": 1,
  "regions": [
    {
      "id": 434317,
      "start_key": "748000000000002DFFB95F720000000000FA",
      "end_key": "748000000000002DFFB95F728000000003FF3F16990000000000FA",
      "epoch": {
        "conf_ver": 7,
        "version": 4204
      },
      "peers": [
        {
          "id": 434318,
          "store_id": 1,
          "role_name": "Voter"
        },
        {
          "id": 434319,
          "store_id": 4,
          "role_name": "Voter"
        },
        {
          "id": 434320,
          "store_id": 5,
          "role_name": "Voter"
        },
        {
          "id": 434321,
          "store_id": 390553,
          "role": 1,
          "role_name": "Learner",
          "is_learner": true
        },
        {
          "id": 434322,
          "store_id": 390554,
          "role": 1,
          "role_name": "Learner",
          "is_learner": true
        }
      ],
      "leader": {"role_name": "Voter"},
      "written_bytes": 0,
      "read_bytes": 0,
      "written_keys": 0,
      "read_keys": 0,
      "approximate_size": 0,
      "approximate_keys": 0
    }
  ]
}

（4）查看下该 region 对应的库表信息，看是否对业务有影响，执行后发现是个空 region：

$ curl http://tidb-server-ip:10080/regions/434317
{
 "start_key": "dIAAAAAAAC25X3I=",
 "end_key": "dIAAAAAAAC25X3KAAAAAAz8WmQ==",
 "start_key_hex": "748000000000002db95f72",
 "end_key_hex": "748000000000002db95f7280000000033f1699",
 "region_id": 434317,
 "frames": null
}

问题曾经定位，上面是如何解决了

问题解决

(1) 应用 pd-ctl，看看是否能让 434317 选出 leader，或者通过增加 peer，删除 peer 等形式解决问题。

执行尝试如下 

// 把 Region 434317 的 leader 调度到 store 4
$tiup ctl:v5.2.1 pd -u http://pd-ip:2379 operator add transfer-leader 434317 4
    Failed! [500] "cannot build operator for region with no leader"

// 在 store 1094772 上新增 Region 434317 的正本
$tiup ctl:v5.2.1 pd -u http://pd-ip:2379 operator add add-peer 434317 1094772
    Failed! [500] "cannot build operator for region with no leader"

// 移除要下线 store 5 上的 Region 434317 的正本
$ tiup ctl:v5.2.1 pd -u http://pd-ip:2379 operator add remove-peer 434317 5
    Failed! [500] "cannot build operator for region with no leader"

发现通过 pd-ctl 折腾的这条路走不通，因为要想实现上述操作，须要在 region 有 leader 的状况下能力操作。

（2）那我应用 pd-ctl 去把这个 store delete 如何？

tiup ctl:v5.2.1 pd -u http://pd-ip:2379 store delete 5
Success!

看到 Sucess 很冲动，然而 pd-ctl store 一看，store 5 还是在记录外面。发现这一招也不论用。

（3）tiup scale-in –force 强制 / 暴力下线该 tikv 如何？

tiup cluster scale-in dsp_report -N 10.203.93.36:20160 --force

执行结束，tiup 外面的确没了。尽管说眼不见心不烦，然而 pd-ctl store 查看 tikv 信息还是有，解体！

（4）最初只能祭出 tikv-ctl 工具，来删除这个 region，因为我上文提到了这个 region 本是空 reigon，删除也不影响业务。具体 tikv-ctl 的应用和介绍就不具体阐明了，能够参见我之前的公众号文章：TiDB 集群复原之 TiKV 集群不可用 

./tikv-ctl --db /data/deploy/data/db tombstone -r 434317 --force

这么操作后，整个世界宁静了，我的“强迫症”也失去满足，这个 region 终于“洁净”了。

PS: 其他人遇到相似的问题，该排查计划能够参考；也能够先进行下线操作，先降级到高阶版本后再尝试缩容的，这里通知大家一个小妙招：我如何发出正在执行的 scale-in 呢？看上面：

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

store 的状态转换

最初这个小结讲讲 Store 状态，TiKV Store 的状态具体分为 Up，Disconnect，Offline，Down，Tombstone。各状态的关系如下：

  • Up：示意以后的 TiKV Store 处于提供服务的状态。
  • Disconnect：当 PD 和 TiKV Store 的心跳信息失落超过 20 秒后，该 Store 的状态会变为 Disconnect 状态，当工夫超过 max-store-down-time 指定的工夫后，该 Store 会变为 Down 状态。
  • Down：示意该 TiKV Store 与集群失去连贯的工夫曾经超过了 max-store-down-time 指定的工夫，默认 30 分钟。超过该工夫后，对应的 Store 会变为 Down，并且开始在存活的 Store 上补足各个 Region 的正本。
  • Offline：当对某个 TiKV Store 通过 PD Control 进行手动下线操作，该 Store 会变为 Offline 状态。该状态只是 Store 下线的中间状态，处于该状态的 Store 会将其上的所有 Region 搬离至其它满足搬迁条件的 Up 状态 Store。当该 Store 的 leadercount 和 regioncount (在 PD Control 中获取) 均显示为 0 后，该 Store 会由 Offline 状态变为 Tombstone 状态。在 Offline 状态下，禁止敞开该 Store 服务以及其所在的物理服务器。下线过程中，如果集群里不存在满足搬迁条件的其它指标 Store（例如没有足够的 Store 可能持续满足集群的正本数量要求），该 Store 将始终处于 Offline 状态。
  • Tombstone：示意该 TiKV Store 已处于齐全下线状态，能够应用 remove-tombstone 接口平安地清理该状态的 TiKV。

本大节来自官网：https\://docs.pingcap.com/zh/tidb/stable/tidb-scheduling#%E4%BF%A1%E6%81%AF%E6%94%B6%E9%9B%86

自己作者：@代晓磊_360
发表工夫：2022/4/25 原文链接：https://tidb.net/blog/ec7009ac

正文完
数据库
发表至： 数据库
2022-04-25
 0
关于数据库:MySQL更新锁表超时-Lock-wait-timeout-exceeded
关于数据库:计算讲谈社第一讲支撑-10-万人同时在线互动是实现元宇宙的基本前提
关于数据库:如何应对数字时代的网络安全新挑战
关于数据库:给你一本武林秘籍和KeeWiDB一起登顶高性能