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

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

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

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

同时宕掉两台机器

从表region的分布图可以看到，当宕掉tikv2135、tikv5138两台主机情况下，整个集群并不会受到影响，因为只有一个region副本分布在这两台机器之上，但这仅仅是当数据库的数据两较小情况，当数据量增大PD调度将会对region的分布进行调度。对于挂掉一个副本的情况，在此不进行模拟。采用同时宕掉Tikv1134和Tikv3136这两台机器，会出现region的两个副本丢失：

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

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

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

|count(*) |

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

| 3000000 |

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

1row in set (6.98 sec)

同时宕掉Tikv3 136和Tikv 4137两台机器后测试表的情况：

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

ERROR9005 (HY000): Region is unavailable

正常的SQL语句出现region不可用的报错。

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

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

»store

…

{

"store": {

"id": 5,

"address": "172.16.134.136:20160",

"labels": [

{

"key": "host",

"value": "tikv3"

}

"version": "4.0.0-rc",

"status_address": "172.16.134.136:20180",

"git_hash": "f45d0c963df3ee4b1011caf5eb146cacd1fbbad8",

"start_timestamp": 1594632461,

"binary_path":"/data1/tidb-deploy/tikv-20160/bin/tikv-server",

"last_heartbeat": 1594700897622993541,

"state_name": "Disconnected"

},…

"store": {

"id": 4,

"address": "172.16.134.134:20160",

"labels": [

{

"key": "host",

"value": "tikv1"

}

"version": "4.0.0-rc",

"status_address": "172.16.134.134:20180",

"git_hash": "f45d0c963df3ee4b1011caf5eb146cacd1fbbad8",

"start_timestamp": 1594632462,

"binary_path":"/data1/tidb-deploy/tikv-20160/bin/tikv-server",

"last_heartbeat": 1594700897744383603,

"state_name": "Disconnected"

向上滑动查看更多内容

可以发现storeID 4和5状态名为“Disconnected”，一段时间后状态会成为“DOWN”。

通过 pd-ctlconfig get 获取region-schedule-limit、replica-schedule-limit、leader-schedule-limit、merge-schedule-limit

[root@tidb1bin]# ./pd-ctl -i -u http://172.16.134.133:2379

»config show

{

"replication": {

"enable-placement-rules": "false",

"location-labels": "host",

"max-replicas": 3,

"strictly-match-label": "false"

"schedule": {

"enable-cross-table-merge": "false",

"enable-debug-metrics": "false",

"enable-location-replacement": "true",

"enable-make-up-replica": "true",

"enable-one-way-merge": "false",

"enable-remove-down-replica": "true",

"enable-remove-extra-replica": "true",

"enable-replace-offline-replica": "true",

"high-space-ratio": 0.7,

"hot-region-cache-hits-threshold": 3,

"hot-region-schedule-limit": 4,

"leader-schedule-limit": 4,

"leader-schedule-policy": "count",

"low-space-ratio": 0.8,

"max-merge-region-keys": 200000,

"max-merge-region-size": 20,

"max-pending-peer-count": 16,

"max-snapshot-count": 3,

"max-store-down-time": "30m0s",

"merge-schedule-limit": 8,

"patrol-region-interval": "100ms",

"region-schedule-limit": 2048,

"replica-schedule-limit": 64,

"scheduler-max-waiting-operator": 5,

"split-merge-interval": "1h0m0s",

"store-balance-rate": 15,

"store-limit-mode": "manual",

"tolerant-size-ratio": 0

}

向上滑动查看更多内容

通过 pd-ctlconfig set 将这 4个参数设为 0

»config set region-schedule-limit 0

Success!

»config set replica-schedule-limit 0

Success!

»config set leader-schedule-limit 0

Success!

»config set merge-schedule-limit 0

Success!

关闭调度主要为将恢复过程中可能的异常情况降到最少，需在故障处理期间禁用相关的调度。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Startingcomponent `cluster`: /root/.tiup/components/cluster/v0.6.1/clusterstop tidb-test -R=tikv

+[ Serial ] - SSHKeySet:privateKey=/root/.tiup/storage/cluster/clusters/tidb-test/ssh/id_rsa,publicKey=/root/.tiup/storage/cluster/clusters/tidb-test/ssh/id_rsa.pub

+[Parallel] - UserSSH: user=tidb, host=172.16.134.133

+[Parallel] - UserSSH: user=tidb, host=172.16.134.134

+[Parallel] - UserSSH: user=tidb, host=172.16.134.135

+[Parallel] - UserSSH: user=tidb, host=172.16.134.136

+[Parallel] - UserSSH: user=tidb, host=172.16.134.137

+[Parallel] - UserSSH: user=tidb, host=172.16.134.138

+[Parallel] - UserSSH: user=tidb, host=172.16.134.133

+[ Serial ] - ClusterOperate: operation=StopOperation,options={Roles:[tikv] Nodes:[] Force:false SSHTimeout:5 OptTimeout:60APITimeout:300}

Stoppingcomponent tikv

Stopping instance 172.16.134.138

Stopping instance 172.16.134.134

Stopping instance 172.16.134.135

Stopping instance 172.16.134.136

Stopping instance 172.16.134.137

Stop tikv 172.16.134.135:20160 success

Stop tikv 172.16.134.138:20160 success

Stop tikv 172.16.134.137:20160 success

向上滑动查看更多内容

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

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

removingstores [4, 5] from configurations...

success

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

removingstores [4, 5] from configurations...

success

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

removingstores [4, 5] from configurations...

success

向上滑动查看更多内容

当然Region比较少，则可以在给定Region 的剩余副本上，移除掉所有位于故障节点上的Peer，在这些Region 的未发生掉电故障的机器上运行：

tikv-ctl--db /path/to/tikv-data/db unsafe-recover remove-fail-stores -s -r ，对于region较多的情况，此操作则较为繁琐。

停止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

这里需要启动PD才能连接到数据库。

检查没有处于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]}

这里没有发现没有leader状态的region。

重新修改参数：

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

»config set region-schedule-limit 2048

Success!

»config set replica-schedule-limit 64

Success!

»config set leader-schedule-limit 4

Success!

»config set merge-schedule-limit 8

Success!

检查查询数据是否正常

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

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

|count(*) |

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

| 3000000 |

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

1row in set (9.95 sec)

至此恢复操作结束。

我们再看看region的分布：

Region的副本进行了新的复制和分布。

完成了两副本的丢失的演练，三副本丢失会出现什么情况又该如何恢复？咱下回见。

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

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

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

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

云计算灾难恢复最佳实践

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

wenyiweb 2021-11-15 18:11 评论0 收藏0
“怎么做好云迁移”? 深蓝云海资深架构师给你答案

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

kk_miles 2019-06-21 16:47 评论0 收藏0
人们需要了解的数据中心的网络威胁

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

CarlBenjamin 2019-04-28 19:37 评论0 收藏0
数据“金”钟罩，你值得拥有

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

geekzhou 2019-04-29 15:45 评论0 收藏0
为什么云计算在伦敦奥运会无用武之地

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

spademan 2019-04-25 16:52 评论0 收藏0