正文
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
