TIDB灾难恢复演练三部曲（下）

IT那活儿发布于2023-01-11 13:20 / 636人阅读

TIDB灾难恢复演练三部曲（下）

TIDB灾难恢复演练三部曲（上）

接上回，我们开始对三副本丢失进行演练。

同时宕掉三台机器

便于理解，先看表t_user新的region分布：

我们这次选择宕掉Tikv2135、Tikv3136和Tikv4137，从分布图可以判断有两region会丢失三副本，一个region丢失两个副本，最后一个region丢失一个副本的情况。

同样的先检查宕机前测试表的状况:

MySQL[sbtest2]> select count(*) from t_user;

+----------+

|count(*) |

+----------+

| 3000000 |

+----------+

1row in set (1.88 sec)

同时宕掉Tikv2135、Tikv3136和Tikv4137两台机器后测试表的情况：

MySQL[sbtest2]> select count(*) from t_user;

ERROR9005 (HY000): Region is unavailable

集群状态：

检查宕机的两台机器对应的store_id：

[root@tidb1bin]# /root/tidb-v4.0.0-linux-amd64/bin/pd-ctl -i -uhttp://172.16.134.133:2379

»store

这里是1，5，6

通过 pd-ctlconfig get 获取region-schedule-limit、replica-schedule-limit、leader-schedule-limit、merge-schedule-limit并通过 pd-ctlconfig set 将这 4个参数设为 0

使用pd-ctl 检查大于等于一半副本数在故障节点上的Region，并记录它们的ID（故障节点为storeid 1，5，6）：

» region --jq=".regions[] | {id: .id,peer_stores: [.peers[].store_id] | select(length as $total | map(if.==(1,5,6) then . else empty end) | length>=$total-length) }"

{"id":3089,"peer_stores":[5,4,6]}

{"id":47,"peer_stores":[4,5,6]}

{"id":75,"peer_stores":[4,5,6]}

{"id":30,"peer_stores":[6,4,5]}

{"id":135,"peer_stores":[6,4,5]}

{"id":4017,"peer_stores":[6,7,5]}

{"id":67,"peer_stores":[4,5,1]}

{"id":2289,"peer_stores":[4,6,5]}

{"id":18,"peer_stores":[6,4,5]}

{"id":39,"peer_stores":[6,4,5]}

{"id":51,"peer_stores":[4,6,5]}

{"id":10,"peer_stores":[4,5,6]}

{"id":14,"peer_stores":[6,5,4]}

{"id":83,"peer_stores":[6,4,5]}

{"id":59,"peer_stores":[6,4,5]}

{"id":6768,"peer_stores":[1,6,4]}

{"id":22,"peer_stores":[4,5,6]}

{"id":26,"peer_stores":[6,4,5]}

{"id":43,"peer_stores":[6,4,5]}

{"id":131,"peer_stores":[6,4,5]}

{"id":4009,"peer_stores":[6,1,5]}

{"id":2,"peer_stores":[7,6,5]}

{"id":63,"peer_stores":[4,5,1]}

{"id":87,"peer_stores":[6,4,5]}

{"id":6734,"peer_stores":[6,1,5]}

{"id":3080,"peer_stores":[6,4,5]}

{"id":3084,"peer_stores":[6,4,5]}

{"id":3076,"peer_stores":[6,4,5]}

{"id":34,"peer_stores":[6,4,5]}

{"id":127,"peer_stores":[6,4,5]}

{"id":3070,"peer_stores":[6,4,5]}

向上滑动查看更多内容

我们可以看到表的三个regionID均在列表中，另外的一个region由于只丢失一个副本，并未出现在列表中。

在剩余正常的kv节点上执行停Tikv的操作：

[root@tidb1bin]# tiup cluster stop tidb-test -R=tikv

在所有健康的节点上执行(操作需要确保健康的节点关闭了Tikv)：

[root@tidb2 bin]# ./tikv-ctl --db /data1/tidb-data/tikv-20160/dbunsafe-recover remove-fail-stores -s 1,5,6 --all-regions

removingstores [1, 5, 6] from configurations...

success

[root@tidb6bin]# ./tikv-ctl --db /data1/tidb-data/tikv-20160/db unsafe-recoverremove-fail-stores -s 1,5,6 --all-regions

removingstores [1, 5, 6] from configurations...

success

停止PD节点：

[root@tidb1~]# tiup cluster stop tidb-test -R=pd

Startingcomponent `cluster`: /root/.tiup/component

重启启动PDtikv节点：

[root@tidb1~]# tiup cluster start tidb-test -R=pd,tikv

检查没有处于leader状态的region（要保持没有）：

[root@tidb1~]# pd-ctl -i -u http://172.16.134.133:2379

»region --jq .regions[]|select(has("leader")|not)|{id:.id,peer_stores: [.peers[].store_id]}

{"id":4009,"peer_stores":[6,1,5]}

{"id":6734,"peer_stores":[6,1,5]}

这里没有发现任然有两个region处于没有leader的状态。另外丢失两副本的一个region以及通过unsafe-recover的方式进行了复制。

尝试访问表t_user

MySQL[sbtest2]> select count(*) from t_user;

ERROR9002 (HY000): TiKV server timeout

或者

MySQL[sbtest2]> select count(*) from t_user;

ERROR9005 (HY000): Region is unavailable

两次执行的结果有所不一样。

根据regionID，确认region属于哪张表，以备后续同步数据需要。

[root@tidb1~]# curl http://172.16.134.133:10080/regions/4009

{

"region_id": 4009,

"start_key": "dIAAAAAAAABN",

"end_key": "dIAAAAAAAABNX3KAAAAAAAt8fw==",

"frames": [

{

"db_name": "sbtest2",

"table_name": "t_user",

"table_id": 77,

"is_record": true,

"record_id": 752767

}

]

两个regionID均属于同一张表。

创建空Region 解决Unavailable 报错。任选一个Store，关闭上面的TiKV，然后执行：

[root@tidb2bin]# ./tikv-ctl --db /data1/tidb-data/tikv-20160/db recreate-region-p 172.16.134.133:2379 -r 4009

initingempty region 17001 with peer_id 17002...

success

[root@tidb2bin]# ./tikv-ctl --db /data1/tidb-data/tikv-20160/db recreate-region-p 172.16.134.133:2379 -r 6734

initingempty region 17003 with peer_id 17004...

success

如果不关闭tikv会报错：

[root@tidb2bin]# ./tikv-ctl --db /data1/tidb-data/tikv-20160/db recreate-region-p 172.16.134.133:2379 -r 4009

threadmain panicked at called `Result::unwrap()` on an `Err` value:RocksDb("IO error: While lock file:/data1/tidb-data/tikv-20160/db/LOCK: Resource temporarilyunavailable"), src/libcore/result.rs:1188:5

note:run with `RUST_BACKTRACE=1` environment variable to display abacktrace.

停止PD节点：

[root@tidb1~]# tiup cluster stop tidb-test -R=pd

Startingcomponent `cluster`: /root/.tiup/component

重启启动PDtikv节点：

[root@tidb1~]# tiup cluster start tidb-test -R=pd,tikv

检查没有处于leader状态的region（要保持没有）：

[root@tidb1~]# pd-ctl -i -u http://172.16.134.133:2379

»region --jq .regions[]|select(has("leader")|not)|{id:.id,peer_stores: [.peers[].store_id]}

重新修改PD的参数并尝试访问表t_user

MySQL[sbtest2]> select count(*) from t_user;

+----------+

|count(*) |

+----------+

| 1494555 |

+----------+

1row in set (1.92 sec)

由于丢失掉两个region的所有副本，所以我们查询出的数据量减少，至此恢复测试结束。

我们再看看region的分布情况：

发现原来三副本丢失的regionID发生了改变。

可以看到表t_user的所有region只有两副本。

总结

TiDB集群中数据存储Tikv如果宕了一台机器，那么并不影响集群的运行，数据库自身会进行处理，PD会将其上的数据region迁移到其他的TiKV节点上。但如果同时宕机两台，甚至3台及以上灾难情况，相信通过上文的介绍理解和相关命令的查询以及修复，能迅速进行对应的恢复操作。笔者后续会基于平台将上述过程实现，到时再来和大家分享。

参考文档https://book.tidb.io/session3/chapter5/recover-quorum.html

海外云主机 GPU服务器灾难恢复灾难恢复管理专有网络灾难恢复 sql 灾难恢复

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/130198.html

“怎么做好云迁移”? 深蓝云海资深架构师给你答案

摘要：基于云迁移的三个阶段细分为八个主要步骤，评估阶段主要包括项目启动现状梳理以及应用系统关联关系分析三个步骤，设计阶段包括云架构优化设计和云迁移方案设计，实施阶段包括目标架构迁移演练及实施和试运行三个步骤。在云计算市场规模不断扩大的大背景下，云迁移的需求越来越大且面临挑战。云迁移不是一个迁移软件工具，而是一种服务。前IBM资深架构师姜亚杰从云迁移的三个阶段、四个维度到八个步骤的方法，简述...

kk_miles 2019-06-21 16:47 评论0 收藏0
云计算灾难恢复最佳实践

摘要：为云计算灾难做好准备要为云计算灾难做好准备，企业需要不断测试其数据恢复框架。与内部部署的灾难恢复相比，云计算灾难恢复更加简单。云计算灾难恢复的最佳实践选择合适的灾难恢复计划方法要制定合适的灾难恢复计划，企业了解其基础设施非常重要。考虑到当今商业环境中采用的云计算技术迅速增加，从导致服务中断和停机的灾难中有效恢复的能力变得更加重要。基于云计算的灾难恢复可以确保企业在尽可能短的时间内恢复其数据和...

wenyiweb 2021-11-15 18:11 评论0 收藏0
人们需要了解的数据中心的网络威胁

摘要：物联网也影响着数据中心的安全性，主要是随着资源和数据数量和质量的增长，人们增加了对数据中心安全性的需求。新的物联网设备是和执行数据分析的其他系统的常见补充，这些设备会导致网络使用和需求增加。网络威胁对于数据中心来说是一个不幸的现实，这些数据中心在防止违规事件方面面临许多挑战。近年来，这种风险一直在增加，超过40％的受访者在Carbonite公司进行的调查报告中表示，所面临的黑客、勒索软件和其...

CarlBenjamin 2019-04-28 19:37 评论0 收藏0
为什么云计算在伦敦奥运会无用武之地

摘要：在全世界的聚焦之下，为年伦敦奥运会运行基础设施的团队将更多重点放在了可靠性上，而不会展示尖端技术。这意味着热门技术例如云计算将不会成为奥运会基础设施的核心部分。表示，每届奥运会相隔四年，这使确保基础设施保持状况成为非常棘手的事情。在全世界的聚焦之下，为2012年伦敦奥运会运行IT基础设施的团队将更多重点放在了可靠性上，而不会展示尖端技术。这意味着热门技术(例如云计算)将不会成为奥运会I...

spademan 2019-04-25 16:52 评论0 收藏0
数据“金”钟罩，你值得拥有

摘要：日前，广东华兴银行总行与科华恒盛就总行灾备数据中心规划建设展开深入合作。项目建成后将全面提升广东华兴银行数据安全保障及运维服务水平，为其总行全球业务提供小时不间断的同城灾备服务，为银行业务稳定运行实现高速增长奠定牢固的信息化基础。随着云计算、大数据等新ICT技术的高速发展，银行业信息化建设的步伐愈行愈快。日前，广东华兴银行总行与科华恒盛就总行灾备数据中心规划建设展开深入合作。科华恒盛将为其提...

geekzhou 2019-04-29 15:45 评论0 收藏0