高可用是 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 xxxx -h xxxx -P xxx -pxxxx
xxxx…
…
…
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]}"
没有任何结果则符合预期。郑州试管婴儿医院:http://yyk.39.net/hospital/fc964_detail.html
这里再次查询可以看到丢了数据,因为我们有几个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台及以上,那么看过这篇文章的你相信你一定不会再手忙脚乱不知所措了!~
郑州妇科医院:http://jbk.39.net/yiyuanfengcai/yyjs_sysdfkyy/