一篇文章带你玩转TiDB灾难恢复
一、背景
高可用是 TiDB 的另一大特点，TiDB/TiKV/PD 这三个组件都能容忍部分实例失效，不影响整个集群的可用性。下面分别说明这三个组件的可用性、单个实例失效后的后果以及如何恢复。
TiDB
TiDB 是无状态的，推荐至少部署两个实例，前端通过负载均衡组件对外提供服务。当单个实例失效时，会影响正在这个实例上进行的 Session，从应用的角度看，会出现单次请求失败的情况，重新连接后即可继续获得服务。单个实例失效后，可以重启这个实例或者部署一个新的实例。
PD
PD 是一个集群，通过 Raft 协议保持数据的一致性，单个实例失效时，如果这个实例不是 Raft 的 leader，那么服务完全不受影响；如果这个实例是 Raft 的 leader，会重新选出新的 Raft leader，自动恢复服务。PD 在选举的过程中无法对外提供服务，这个时间大约是3秒钟。推荐至少部署三个 PD 实例，单个实例失效后，重启这个实例或者添加新的实例。
TiKV
TiKV 是一个集群，通过 Raft 协议保持数据的一致性（副本数量可配置，默认保存三副本），并通过 PD 做负载均衡调度。单个节点失效时，会影响这个节点上存储的所有 Region。对于 Region 中的 Leader 节点，会中断服务，等待重新选举；对于 Region 中的 Follower 节点，不会影响服务。当某个 TiKV 节点失效，并且在一段时间内（默认 30 分钟）无法恢复，PD 会将其上的数据迁移到其他的 TiKV 节点上。
二、架构
wtidb28.add.shbt.qihoo.net 192.168.1.1 TiDB/PD/pump/prometheus/grafana/CCS
wtidb27.add.shbt.qihoo.net 192.168.1.2 TiDB
wtidb26.add.shbt.qihoo.net 192.168.1.3 TiDB
wtidb22.add.shbt.qihoo.net 192.168.1.4 TiKV
wtidb21.add.shbt.qihoo.net 192.168.1.5 TiKV
wtidb20.add.shbt.qihoo.net 192.168.1.6 TiKV
wtidb19.add.shbt.qihoo.net 192.168.1.7 TiKV
wtidb18.add.shbt.qihoo.net 192.168.1.8 TiKV
wtidb17.add.shbt.qihoo.net 192.168.1.9 TiFlash
wtidb16.add.shbt.qihoo.net 192.168.1.10 TiFlash集群采用3TiDB节点，5TiKV，2TiFlash架构来测试灾难恢复，TiFlash采用的方式是先部署集群，后部署TiFlash的方式，版本3.1.0GA
三、宕机两台测试
集群默认3副本，5台机器宕机任意两台，理论上存在三种情况，一种是3副本中，有两个副本正巧在宕机的这两台上，一种是3副本中，只有一个region在宕机的两台机器上，还一种就是宕机的两台机器里不存在某些内容的任何副本，本次我们测试让wtidb21和wtidb22两个TiKV节点宕机。
我们先看一下宕机前测试表的状况
mysql> select count(*) from rpt_qdas_show_shoujizhushou_channelver_mix_daily;
+----------+
| count(*) |
+----------+
| 1653394 |
+----------+
1 row in set (0.91 sec)
mysql> select count(*) from rpt_qdas_show_shoujizhushou_channelver_mix_daily force index (idx_day_ver_ch);
+----------+
| count(*) |
+----------+
| 1653394 |
+----------+
1 row in set (0.98 sec)
两台同时宕机后：
mysql> select count(*) from rpt_qdas_show_shoujizhushou_channelver_mix_daily;
ERROR 9002 (HY000): TiKV server timeout
mysql> select count(*) from rpt_qdas_show_shoujizhushou_channelver_mix_daily force index (idx_day_ver_ch);
ERROR 9005 (HY000): Region is unavailable
看一下宕机的两台store_id
/data1/tidb-ansible-3.1.0/resources/bin/pd-ctl -i -u http://192.168.1.1:2379
» store知道是1和4
检查大于等于一半副本数在故障节点上的region
[tidb@wtidb28 bin]$ /data1/tidb-ansible-3.1.0/resources/bin/pd-ctl -u http://192.168.1.1:2379 -d region --jq='.regions[] | {id: .id, peer_stores: [.peers[].store_id] | select(length as $total | map(if .==(1,4) then . else empty end) | length>=$total-length)}'
{"id":18,"peer_stores":[4,6,1]}
{"id":405,"peer_stores":[7,4,1]}
{"id":120,"peer_stores":[4,1,6]}
{"id":337,"peer_stores":[4,5,1]}
{"id":128,"peer_stores":[4,1,6]}
{"id":112,"peer_stores":[1,4,6]}
{"id":22,"peer_stores":[4,6,1]}
{"id":222,"peer_stores":[7,4,1]}
{"id":571,"peer_stores":[4,6,1]}在剩余正常的kv节点上执行停kv的脚本：
ps -ef|grep tikv
sh /data1/tidb/deploy/scripts/stop_tikv.sh
ps -ef|grep tikv变更其属主，将其拷贝至tidb目录下chown -R tidb. /home/helei/tikv-ctl
这个分情况, 如果是 region 数量太多，那么按照 region 来修复的话，速度会比较慢，并且繁琐，这个使用使用 all 操作比较便捷，但是有可能误杀有两个 peer 的副本，也就是说可能你坏的这台机器，有个region只有一个在这台机器上，但他也会只保留一个region副本在集群里
下面的操作要在所有存活的节点先执行stop kv操作（要求kv是关闭状态），然后执行
[tidb@wtidb20 tidb]$ ./tikv-ctl --db /data1/tidb/deploy/data/db unsafe-recover remove-fail-stores -s 1,4 --all-regions
removing stores [1, 4] from configrations...
success重启pd节点
ansible-playbook stop.yml --tags=pd
这里如果pd都关了的话，你是登不上库的
[helei@db-admin01 ~]$ /usr/local/mysql56/bin/mysql -u mydba -h 10.217.36.146 -P 43000 -p4c41b9
6c7687f66d
…
…
…
ansible-playbook start.yml --tags=pd重启存活的kv节点
sh /data1/tidb/deploy/scripts/start_tikv.sh
检查没有处于leader状态的region[tidb@wtidb28 bin]$ /data1/tidb-ansible-3.1.0/resources/bin/pd-ctl -u http://192.168.1.1:2379 -d region --jq '.regions[]|select(has("leader")|not)|{id: .id,peer_stores: [.peers[].store_id]}'
这里我没有搜到任何的非leader region，只有副本数是3，且同时挂3台机器以上，且正巧有些region全部的region都在这3台机器上，前面步骤是unsafe all-region，pd这个检查没有处于leader状态的region步骤才会显示出来，才会需要对应到表查询丢了那些数据，才需要去创建空region啥的，我这个情况，只要还保留一个副本，不管unsafe执行的是all-regions，还是指定的具体的region号，都是不需要后面的步骤
正常启动集群后，可以通过pd-ctl来观看之前的region数，理论上在使用unsafe --all-regions后，仅剩的1个region成为leader，剩余的kv节点通过raft协议将其再次复制出2个follower拷贝到其他store上
例如本案例里的{"id":18,"peer_stores":[4,6,1]}
通过pd-ctl可以看到他现在在犹豫1,4kv节点损坏，在执行unsafe-recover remove-fail-stores --all-regions后，将1,4的移除，仅剩的6成为leader，利用raft协议在5,7节点复制出新的follower，达成3副本顺利启动集群
» region 18
{
"id": 18,
"start_key": "7480000000000000FF0700000000000000F8",
"end_key": "7480000000000000FF0900000000000000F8",
"epoch": {
"conf_ver": 60,
"version": 4
},
"peers": [
{
"id": 717,
"store_id": 6
},
{
"id": 59803,
"store_id": 7
},
{
"id": 62001,
"store_id": 5
}
],
"leader": {
"id": 717,
"store_id": 6
},
"written_bytes": 0,
"read_bytes": 0,
"written_keys": 0,
"read_keys": 0,
"approximate_size": 1,
"approximate_keys": 0
}如果只同时挂了2台机器，那么到这里就结束了，如果只挂1台那么不用处理的
先看一下数据现在是没问题的，之前的步骤恢复的很顺利
mysql> select count(*) from rpt_qdas_show_shoujizhushou_channelver_mix_daily;
+----------+
| count(*) |
+----------+
| 1653394 |
+----------+
1 row in set (0.86 sec)
mysql> select count(*) from rpt_qdas_show_shoujizhushou_channelver_mix_daily force index (idx_day_ver_ch);
+----------+
| count(*) |
+----------+
| 1653394 |
+----------+
1 row in set (0.98 sec)这里有个插曲
当我把1,4宕掉的节点恢复，这期间集群一直没有新的数据写入，原本是6作为leader，新生成的5，7作为follower作为副本，而恢复后，将5,7剔除，重新将1,4作为follower了，region 18还是1,4,6的store_id。
四、宕机3台测试
如果同时挂了3台及以上，那么上面的非leader步骤检查是会有内容的
我们这次让如下三台宕机：
wtidb22.add.shbt.qihoo.net 192.168.1.4 TiKV
wtidb21.add.shbt.qihoo.net 192.168.1.5 TiKV
wtidb20.add.shbt.qihoo.net 192.168.1.6 TiKV首先，停止所有正常的tikv，本案例是wtidb19,wtidb18
看一下宕机的两台store_id
/data1/tidb-ansible-3.1.0/resources/bin/pd-ctl -i -u http://192.168.1.1:2379
» store知道是1、4、5
检查大于等于一半副本数在故障节点上的region
[tidb@wtidb28 bin]$ /data1/tidb-ansible-3.1.0/resources/bin/pd-ctl -u http://192.168.1.1:2379 -d region --jq='.regions[] | {id: .id, peer_stores: [.peers[].store_id] | select(length as $total | map(if .==(1,4,5) then . else empty end) | length>=$total-length)}'
{"id":156,"peer_stores":[1,4,6]}
{"id":14,"peer_stores":[6,1,4]}
{"id":89,"peer_stores":[5,4,1]}
{"id":144,"peer_stores":[1,4,6]}
{"id":148,"peer_stores":[6,1,4]}
{"id":152,"peer_stores":[7,1,4]}
{"id":260,"peer_stores":[6,1,4]}
{"id":480,"peer_stores":[7,1,4]}
{"id":132,"peer_stores":[5,4,6]}
{"id":22,"peer_stores":[6,1,4]}
{"id":27,"peer_stores":[4,1,6]}
{"id":37,"peer_stores":[1,4,6]}
{"id":42,"peer_stores":[5,4,6]}
{"id":77,"peer_stores":[5,4,6]}
{"id":116,"peer_stores":[5,4,6]}
{"id":222,"peer_stores":[6,1,4]}
{"id":69,"peer_stores":[5,4,6]}
{"id":73,"peer_stores":[7,4,1]}
{"id":81,"peer_stores":[5,4,1]}
{"id":128,"peer_stores":[6,1,4]}
{"id":2,"peer_stores":[5,6,4]}
{"id":10,"peer_stores":[7,4,1]}
{"id":18,"peer_stores":[6,1,4]}
{"id":571,"peer_stores":[6,5,4]}
{"id":618,"peer_stores":[7,1,4]}
{"id":218,"peer_stores":[6,5,1]}
{"id":47,"peer_stores":[1,4,6]}
{"id":52,"peer_stores":[6,1,4]}
{"id":57,"peer_stores":[4,7,1]}
{"id":120,"peer_stores":[6,1,4]}
{"id":179,"peer_stores":[5,1,4]}
{"id":460,"peer_stores":[5,7,1]}
{"id":93,"peer_stores":[6,1,4]}
{"id":112,"peer_stores":[6,1,4]}
{"id":337,"peer_stores":[5,6,4]}
{"id":400,"peer_stores":[5,7,1]}现在还剩两台存活
wtidb19.add.shbt.qihoo.net 192.168.1.7 TiKV
wtidb18.add.shbt.qihoo.net 192.168.1.8 TiKV下面的操作要在所有存活的节(本案例是wtidb19和wtidb18)点先执行stop kv操作（要求kv是关闭状态），然后执行
[tidb@wtidb19 tidb]$ ./tikv-ctl --db /data1/tidb/deploy/data/db unsafe-recover remove-fail-stores -s 1,4,5 --all-regions
removing stores [1, 4, 5] from configrations...
success重启pd节点
ansible-playbook stop.yml --tags=pd
ansible-playbook start.yml --tags=pd重启存活的kv节点sh /data1/tidb/deploy/scripts/start_tikv.sh
检查没有处于leader状态的region，这里看到，1,4,5因为所有的region都在损坏的3台机器上，这些region丢弃后数据是恢复不了的
[tidb@wtidb28 tidb-ansible-3.1.0]$ /data1/tidb-ansible-3.1.0/resources/bin/pd-ctl -u http://192.168.1.1:2379 -d region --jq '.regions[]|select(has("leader")|not)|{id: .id,peer_stores: [.peers[].store_id]}'
{"id":179,"peer_stores":[5,1,4]}
{"id":81,"peer_stores":[5,4,1]}
{"id":89,"peer_stores":[5,4,1]}根据region ID，确认region属于哪张表
[tidb@wtidb28 tidb-ansible-3.1.0]$ curl http://192.168.1.1:10080/regions/179
{
"region_id": 179,
"start_key": "dIAAAAAAAAA7X2mAAAAAAAAAAwOAAAAAATQXJwE4LjQuMAAAAPwBYWxsAAAAAAD6A4AAAAAAAqs0",
"end_key": "dIAAAAAAAAA7X3KAAAAAAAODBA==",
"frames": [
{
"db_name": "hl",
"table_name": "rpt_qdas_show_shoujizhushou_channelver_mix_daily(p201910)",
"table_id": 59,
"is_record": false,
"index_name": "key2",
"index_id": 3,
"index_values": [
"20191015",
"8.4.0",
"all",
"174900"
]
},
{
"db_name": "hl",
"table_name": "rpt_qdas_show_shoujizhushou_channelver_mix_daily(p201910)",
"table_id": 59,
"is_record": true,
"record_id": 230148
}
]
}这时候去看集群状态的话，
» store
{
"count": 5,
"stores": [
{
"store": {
"id": 1,
"address": "192.168.1.4:20160",
"version": "3.1.0",
"state_name": "Down"
},
"status": {
"leader_weight": 1,
"region_count": 3,
"region_weight": 1,
"start_ts": "1970-01-01T08:00:00+08:00"
}
},
{
"store": {
"id": 4,
"address": "192.168.1.5:20160",
"version": "3.1.0",
"state_name": "Down"
},
"status": {
"leader_weight": 1,
"region_count": 3,
"region_weight": 1,
"start_ts": "1970-01-01T08:00:00+08:00"
}
},
{
"store": {
"id": 5,
"address": "192.168.1.6:20160",
"version": "3.1.0",
"state_name": "Down"监控也是没数据
库里查询也依旧被阻塞
mysql> use hl
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> select count(*) from rpt_qdas_show_shoujizhushou_channelver_mix_daily;创建空region解决unavaliable状态，这个命令要求pd，kv处于关闭状态
这里必须一个一个-r的写，要不报错：
[tidb@wtidb19 tidb]$ ./tikv-ctl --db /data1/tidb/deploy/data/db recreate-region -p 192.168.1.1:2379 -r 89,179,81
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ParseIntError { kind: InvalidDigit }', src/libcore/result.rs:1188:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
Aborted
./tikv-ctl --db /data1/tidb/deploy/data/db recreate-region -p '192.168.1.1:2379' -r 89
./tikv-ctl --db /data1/tidb/deploy/data/db recreate-region -p '192.168.1.1:2379' -r 81
./tikv-ctl --db /data1/tidb/deploy/data/db recreate-region -p '192.168.1.1:2379' -r 179启动pd和tikv后，再次运行[tidb@wtidb28 tidb-ansible-3.1.0]$ /data1/tidb-ansible-3.1.0/resources/bin/pd-ctl -u http://192.168.1.1:2379 -d region --jq '.regions[]|select(has("leader")|not)|{id: .id,peer_stores: [.peers[].store_id]}'
没有任何结果则符合预期
这里再次查询可以看到丢了数据，因为我们有几个region（81,89,179）都丢失了
mysql> select count(*) from rpt_qdas_show_shoujizhushou_channelver_mix_daily;
+----------+
| count(*) |
+----------+
| 1262523 |
+----------+
1 row in set (0.92 sec)这里可以看到索引数据不再region（81,89,179）中，所以还跟之前一样
mysql> select count(*) from rpt_qdas_show_shoujizhushou_channelver_mix_daily force index (idx_day_ver_ch);
+----------+
| count(*) |
+----------+
| 1653394 |
+----------+
1 row in set (1.01 sec)至此，测试完成
五、总结
看完这篇文章，相信你不会再虚TiDB的多点掉电问题的数据恢复了，正常情况下，极少数出现集群同时宕机多台机器的，如果只宕机了一台，那么并不影响集群的运行，他会自动处理，当某个 TiKV 节点失效，并且在一段时间内（默认 30 分钟）无法恢复，PD 会将其上的数据迁移到其他的 TiKV 节点上。但如果同时宕机两台，甚至3台及以上，那么看过这篇文章的你相信你一定不会再手忙脚乱不知所措了！~
原文地址：https://www.cnblogs.com/pi12/p/12876835.html
- 高效开发 MVVM 和 databinding 你需要使用的工具
- ASP.NET AJAX(9)__Profile Service什么是ASP.NET Profile如何使用ASP.NET ProfileProfile ServiceProfile Service预
- 设计模式专题（三）——装饰模式
- ASP.NET AJAX(8)__Microsoft AJAX Library中异步通信层的使用什么是异步通信层Micorsoft AJAX Library异步通信层的组成WebRequestExec
- ASP.NET AJAX（7）_Microsoft AJAX Library扩展客户端组件继承时需要注意的问题扩展类型如何修改已有类型
- ASP.NET AJAX（6）__Microsoft AJAX Library中的面向对象类型系统命名空间类类——构造函数类——定义方法类——定义属性类——注册类类——抽象类类——继承类——调用父类方
- 设计模式专题（四）——代理模式
- Array数组函数(一)
- ASP.NET AJAX(5)__JavaScript原生类型以及Microsoft AJAX Library什么是Microsoft AJAX LibraryObject原生类型Object.pro
- 使用 Octave 来学习 Machine Learning(一)
- ASP.NET AJAX（4）__客户端访问WebService服务器端释放WebService方法客户端访问WebService客户端访问PageMethod错误处理复杂数据类型使用基础客户端代理的
- 讲真，你该做备份的有效性校验了
- memcache安装方法
- 设计模式专题（五）——工厂方法模式
- JavaScript 教程
- JavaScript 编辑工具
- JavaScript 与HTML
- JavaScript 与Java
- JavaScript 数据结构
- JavaScript 基本数据类型
- JavaScript 特殊数据类型
- JavaScript 运算符
- JavaScript typeof 运算符
- JavaScript 表达式
- JavaScript 类型转换
- JavaScript 基本语法
- JavaScript 注释
- Javascript 基本处理流程
- Javascript 选择结构
- Javascript if 语句
- Javascript if 语句的嵌套
- Javascript switch 语句
- Javascript 循环结构
- Javascript 循环结构实例
- Javascript 跳转语句
- Javascript 控制语句总结
- Javascript 函数介绍
- Javascript 函数的定义
- Javascript 函数调用
- Javascript 几种特殊的函数
- JavaScript 内置函数简介
- Javascript eval() 函数
- Javascript isFinite() 函数
- Javascript isNaN() 函数
- parseInt() 与 parseFloat()
- escape() 与 unescape()
- Javascript 字符串介绍
- Javascript length属性
- javascript 字符串函数
- Javascript 日期对象简介
- Javascript 日期对象用途
- Date 对象属性和方法
- Javascript 数组是什么
- Javascript 创建数组
- Javascript 数组赋值与取值
- Javascript 数组属性和方法
- Android中的颜色表示的详解
- android使用SoundPool播放音效的方法
- android中Context深入详解
- Android中Notification通知用法详解
- Android build文件的删除的方法
- Android自定义Notification添加点击事件
- 深入理解Android Bitmap
- Android基于AlarmManager实现用户在线心跳功能示例
- 详解Android中获取软键盘状态和软键盘高度
- Android流式布局FlowLayout详解
- Linux 专题
- Go语言实现UDP通信
- Android多渠道打包的方法步骤
- Android编程实现压缩图片并加载显示的方法
- Android串口通信封装之OkUSB的示例代码