tidb集群错误执行了缩容

🪐 TiDB 技术问题
1

【 TiDB 使用环境】
生产环境
【概述】场景+问题概述
我们的环境是v4.0.0 有三个副本，大概30个tikv实例
当时有一台tikv机器有点问题,之前有3个tikv实例。后面处理过后有2个tikv实例，集群正常工作了
后面又需要执行下线操作。
我对2个实例进行了缩容操作
tiup cluster scale-in 集群名称 -N XXX:20160 --force
tiup cluster scale-in 集群名称 -N XXX:20162 --force
后面导致数据库部分不可用
后面没有操作，等待这2个实例中的 region_count 满满减少

【业务影响】
导致数据库部分不可用
【TiDB 版本】
v.4.0.0
【附件】
» store 67706533
{
“store”: {
“id”: 67706533,
“address”: “192.168.100.145:20162”,
“state”: 1,
“version”: “4.0.0”,
“status_address”: “192.168.100.145:20182”,
“git_hash”: “198a2cea01734ce8f46d55a29708f123f9133944”,
“start_timestamp”: 1643970851,
“deploy_path”: “/data3/deploy/install/deploy/tikv-20162/bin”,
“last_heartbeat”: 1644282076446565695,
“state_name”: “Offline”
},
“status”: {
“capacity”: “1.433TiB”,
“available”: “611.4GiB”,
“used_size”: “839.6GiB”,
“leader_count”: 1252,
“leader_weight”: 1,
“leader_score”: 1252,
“leader_size”: 97935,
“region_count”: 19382,
“region_weight”: 1,
“region_score”: 1393586,
“region_size”: 1393586,
“start_ts”: “2022-02-04T18:34:11+08:00”,
“last_heartbeat_ts”: “2022-02-08T09:01:16.446565695+08:00”,
“uptime”: “86h27m5.446565695s”
}
}

现在我应该怎么办，数据能全部复原吗

3

30个tikv. 强制下线两个 导致部分数据不可用，可以先 region check一下

4

这种情况有可能丢失数据
1、如果主机上部署多个tikv实例，还是通过label保证同一个region的 peers 不会部署在同一个主机上，相当于rack隔离一样
2、这种情况下 需要有损恢复，可以参考这里
https://asktug.com/t/topic/183387
3、如果丢失的region 副本数据是业务数据，有可能会导致部分业务数据丢失，如果是tidb元数据，那就有可能导致集群不可用。

1 个赞
6

region check offline-peer 会有很多打印

7

region check offline-peer
执行这个打印有很多，昨天刚开始一个store上又39000个region需要迁移
现在还有19000多个

8

这样会丢数据吗，我好紧张啊
我看有的资料说不会因为有一个副本肯定在的
但是有的说会丢数据

9

现在是有问题？不是30个kv吗？可以查一下 是否有down-peer

10

现在还在等region迁移，数据库操作还是有部分失败的。缩容后还有30个kv

11

用tiup cluster display还有30个kv状态都是up,但是用pd-ctl查看，被缩容的2个tikv实例还在，就是上面67706533这样，他里面的region_count还在缓慢地减少

12

可以参考这个看下有没有丢掉多副本的情况。如果没有的话，可以放心了。有的话再考虑用1副本修复。

https://docs.pingcap.com/zh/tidb/v4.0/pd-control#恢复数据时寻找相关-region
例如当 [store1, store30, store31] 宕机时不可用时，我们可以通过查找所有 Down 副本数量大于正常副本数量的所有 Region：

>> region --jq=".regions[] | {id: .id, peer_stores: [.peers[].store_id] | select(length as $total | map(if .==(1,30,31) then . else empty end) | length>=$total-length) }"
3 个赞
13

好的 感谢 我先看一下这个命令

14

我们宕机地2个tikv实例地storeid是67706533,67706532。
用下面的能查出来很多。
region --jq=".regions[] | {id: .id, peer_stores: [.peers[].store_id] | select(length as $total | map(if .==(67706533,67706532) then . else empty end) | length>=$total-length) }"
例如这样的打印
{“id”:79936021,“peer_stores”:[67706533,12,67706532]}
{“id”:42863065,“peer_stores”:[8,67706532,67706533]}
{“id”:65903180,“peer_stores”:[11,67706533,67706532]}
但是 store6,store8,store11都是正常的up状态，这样数据能完全恢复吗

15

数据不会丢，现在的现象可能由于force下线 导致的部分region 还没有调度完成。

16

太感谢了 你的这句话是我今天听到最暖心的话:sob: 太感谢你了

1 个赞
17

我们用config show查看配置参数"replica-schedule-limit": 64
然后用operator show 查看里面的replace-offline-replica正好是64个。
我们可以增加这个参数 加快副本的迁移吗，我们现在看每小时这能迁移走300个左右。19000多个region要60个小时

18

这个根据集群情况，可以适当调整，由于是强制下线两个 可能会造成有损恢复。 这个链接可以参考
血泪教训 TiKV多副本丢失unsafe-recover恢复记录

19

pd的日志里还有很多这样的timeout的打印，这个哪里能调整下吗
[2022/02/09 09:37:15.636 +08:00] [INFO] [operator_controller.go:549] [“operator timeout”] [region-id=41962156] [takes=10m1.984238503s] [operator="“replace-offline-replica {mv peer: store [67706533] to [67706529]} (kind:region,replica, region:41962156(10980,53903), createAt:2022-02-09 09:27:13.652227479 +0800 CST m=+44645454.731936565, startAt:2022-02-09 09:27:13.652403589 +0800 CST m=+44645454.732112665, currentStep:0, steps:[add learner peer 91799175 on store 67706529, promote learner peer 91799175 on store 67706529 to voter, remove peer on store 67706533]) timeout”"]

20

你说的这个--------这个根据集群情况，可以适当调整，由于是强制下线两个 可能会造成有损恢复
跟之前的这个-----数据不会丢，现在的现象可能由于force下线 导致的部分region 还没有调度完成
。。。
该怎么理解数据不会丢有损回复怎么理解呢。。

21

按你这个结果看，2个副本在你要下线的tikv上，1个副本在别处。tiup我不熟悉，不知道force会怎样。如果是断电式的，那这些region就丢了多数副本，会受影响。其他同学回复说不会丢，那就是不会丢了。

22

感谢你们了，我心里稳定了很多，我一整天整个人都不好了:scream: