idb单副本时-TiKV节点损坏后有损数据恢复的方法

Tidb单副本时-TiKV节点损坏后有损数据恢复的方法

---

背景

UAT环境下,为了减少存储. 搭建了一套单副本的TiDB集群
但是随着数据量的增多, UAT上面的数据可以丢失,但是表结构等信息是无法接受丢失和损坏的. 

因为很多不太均衡的问题, 导致. 部分TiKV节点不稳定. 甚至会出现TiKV宕机的问题.
单副本时出现异常肯定会有部分数据丢失.  但是至少希望能够将环境挽救回来. 

所以重要的事情说三遍
至少三副本, 至少三副本, 至少三副本
必须有备份
必须有备份
必须有备份

---

环境说明

1. 环境信息
四台服务器
6个TiDB
16个TiKV
4个TiFlash
需要注意:
一共 8块SSD用于存储TiKV
这里存在一个问题. TiDB其实是默认每个tikv 独占一个SSD的.
所以数据存储的capacity 是翻倍的. 

2. 问题复盘
同事发现某一个TiKV总是出现disconnect的状态
然后执行了sacle-in的操作.
因为是单副本, 所以运行一段时间后发现机器都在报
9005 regions is unavailable的操作.
所以终止了scale-in
节点直接到了 down的状态.
然后再scale-in 节点存在数据的 表 都会报9005的错误
环境基本不可用.

---

修复思路

学习思路:
https://tidb.net/blog/ad45bad9

区别是, 我们是单副本, 某个tikv节点出现异常会丢失该节点上所有的regions.
思路主要是两个:
1. 删除所有regions的映射关系. 但是删除可能会导致更不可控的问题.
2. 将损坏tikv节点上面的regions 在其他节点创建一个空的regions. 诱导tidb查询过去.
   不会出现 9005的错误, 返回空, 虽然丢失数据, 但是会查询返回. 

思路1 不太可取. 删除操作可能带来更多的不可控
所以主要思路就在方案2 上面了.

---

环境准备

注意, 我这边的版本是 6.5.3
很多方式跟之前的操作步骤是不太相同的
为了快捷处理, 第一步是在tidb环境上面进行相关工具的创建与环境变量维护使用.
第一步: 安装
tiup ctl:v6.5.3
默认情况下会在
 /root/.tiup/components/ctl/v6.5.3/ctl
目录下面创建一些ctl的工具. 

修改环境变量
cat > /etc/profile.d/tidb.sh <<EOF
PATH=\$PATH:/root/.tiup/components/ctl/v6.5.3/
EOF
source /etc/profile.d/tidb.sh 

工具验证
pd-ctl config show 

停止调度:
pd-ctl config set region-schedule-limit 0
pd-ctl config set replica-schedule-limit 0
pd-ctl config set leader-schedule-limit 0
pd-ctl config set merge-schedule-limit 0

scale-out 一个tikv节点
yaml文件为:
tikv_servers:
  - host: 192.168.xxx.xxx
    port: 50160
    status_port: 50180
    data_dir: /nvme03/tidb/data/tikv-50160

tiup cluster scale-out erptidb xxx.yaml 

查看tidb的信息
tiup cluster display erptidb 

停止新增加的节点
tiup cluster stop erptidb -N 192.168.xxx.xxx:50160

---

处理过程

1. 查询宕机的tikv节点上面的 所有的regions.
   查询所有的tikv对应的storeid
   select * from information_schema.TIKV_STORE_STATUS
   获取异常的store 的id.

2. 根据storeid 获取所有的regions id
   	select * from TIKV_REGION_PEERS where store_id = '258384'
   注意,需要保存所有的 regions_id 我这次宕机有 25000 个regions. 

3. 在tidb的主机上面创建空的regions .
   tikv-ctl --data-dir /nvme03/tidb/data/tikv-50160 recreate-region -p 192.168.xxx.xxx:2379 -r 321115128
   注意 -r 后面是 异常损坏的 regions-id 

4. 注意时间可能会非常漫长, 创建完成后 可以删除掉之前有问题的store-id
   然后开起来关闭的那个stop节点:
   tiup cluster start erptidb -N 192.168.xxx.xxx:50160
   pd-ctl store delete 258384

5. 验证集群是否可用, 之前保存的表是否可以正常 select 或者是执行delete 操作. 

6. 恢复调度
pd-ctl config set region-schedule-limit  2048
pd-ctl config set replica-schedule-limit 1024
pd-ctl config set leader-schedule-limit  64
pd-ctl config set merge-schedule-limit   64

---

存在问题

怀疑是 6.5.3的bug 我有一个节点的容量特别高, 我也开启了 调度, 但是他死活调度不出来. 

也可能是开源版本的一些限制, 搞不太明白. 

使用minio 进行备份操作

now=`date +%Y%m%d%H`
export AWS_ACCESS_KEY_ID=miniouserpassword
export AWS_SECRET_ACCESS_KEY=miniouserpassword

mkdir /nvme02/minio/tidb255119${now}

time /root/.tiup/components/br/v7.2.0/br backup full  -f '*.*'  -f '!information_schema.*'   -f '!emetrics_schema.*'    --pd "192.168.xxx.xxx:2379" --storage "s3://tidb255119${now}" --s3.endpoint "http://192.168.xxx.xxy:9901"  --send-credentials-to-tikv=true  --log-file backupfull.log