数据库是每个企业的重中之重，存储着公司业务数据，一旦出现永久性损坏，对公司的打击会是灾难性的（从这两年删库跑路，企业经受的损失就可以感知）。分布式数据库虽然采用数据多副本备份机制来保证数据的可靠性，但同样也会面临多副本丢失的风险。灾难出现如何快速恢复也是DBA需要面对的问题，本案通过对具体示例的理解与操作介绍了分布式NEWSQL数据库Tidb对多副本丢失的问题的处理。
TiDB 集群主要包括三个核心组件：TiDBServer，PDServer 和 TiKVServer。
TiDBServer
TiDB Server 负责接收 SQL请求，处理 SQL相关的逻辑，并通过 PD找到存储计算所需数据的TiKV 地址，与TiKV 交互获取数据，最终返回结果。TiDBServer 是无状态的，其本身并不存储数据，只负责计算，可以无限水平扩展，可以通过负载均衡组件（如LVS、HAProxy或 F5）对外提供统一的接入地址。
PDServer
Placement Driver (简称 PD)是整个集群的管理模块，其主要工作有三个：一是存储集群的元信息（某个Key 存储在哪个TiKV 节点）；二是对TiKV 集群进行调度和负载均衡（如数据的迁移、Raftgroup leader 的迁移等）；三是分配全局唯一且递增的事务ID。PD 通过 Raft协议保证数据的安全性。Raft的 leaderserver 负责处理所有操作，其余的PD server 仅用于保证高可用。
TiKVServer
TiKV Server 负责存储数据，从外部看TiKV 是一个分布式的提供事务的Key-Value 存储引擎。存储数据的基本单位是Region，每个Region 负责存储一个Key Range（从StartKey 到EndKey 的左闭右开区间）的数据，每个TiKV 节点会负责多个Region。TiKV使用 Raft协议做复制，保持数据的一致性和容灾。副本以Region 为单位进行管理，不同节点上的多个Region 构成一个Raft Group，互为副本。数据在多个TiKV 之间的负载均衡由PD 调度，这里也是以Region 为单位进行调度。
TiDB 默认配置为3 副本，每一个Region 都会在集群中保存3 份，它们之间通过Raft 协议来选举Leader 并同步数据。Raft协议可以保证在数量小于副本数（注意，不是节点数）一半的节点挂掉或者隔离的情况下，仍然能够提供服务，并且不丢失任何数据。图1中紫色部分为3副本的region。
对于 3副本集群，挂掉一个节点除了可能会导致性能有抖动之外，可用性和正确性理论上不会受影响；但是挂掉 2个副本，一些region 就会不可用，而且如果这2个副本无法完整地找回了，还存在永久丢失部分数据的可能。
图1
在实际生产环境中，TiDB集群是可能会出现丢失数据情况，如：
一个 TiDB 集群可能会出现多台 TiKV 机器短时间内接连故障且无法短期内恢复
一个双机房部署的 TiDB 集群的其中一个机房整体故障等
在上述这些情形下，会出现部分Region的多个副本（包含全部副本的情况）同时故障，进而导致Region的数据部分或全部丢失的问题。这个时候，最重要的是快速地最大程度地恢复数据并恢复TiDB 集群正常服务。
本次演练采用较新的数据库软件版本v4.0.0-rc，主要关注Tikv中region的处理，此架构设计时将PD、TIDB、监控部署在一台机器之上，并未做冗余处理，Tikv选择5台机器，采用Tiup进行部署。下图为部署设计：
为更好的理解，我们将以拥有三百万条数据的t_user表作为操作的对象，在测试环境中模拟两副本以及三副本丢失的灾难场景，并进行对应的数据灾难恢复。
T_user表结构：
CreateTable: CREATE TABLE `t_user` (
`id` int(11) NOT NULL,
`c_user_id` varchar(36) DEFAULT NULL,
`c_name` varchar(22) DEFAULT NULL,
`c_province_id` int(11) DEFAULT NULL,
`c_city_id` int(11) DEFAULT NULL,
`create_time` datetime DEFAULT NULL,
PRIMARY KEY (`id`)
)ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin
查看t_user表在store的分布：
SHOWTABLE REGIONS 语句用于显示TiDB 中某个表的Region 信息。
从信息可以发现，t_user表有四个region，但是SQL命令未能详细列出region在不同的store上的分布，例如region的leader以及folloer如何在store进行分布，这里信息有助于我们更好理解region的分布。
通过pd-ctl工具可以找到更加详细的信息：
[root@tidb1bin]# ./pd-ctl -i -u http://172.16.134.133:2379
»region 4009
{
"id": 4009,
"start_key":"7480000000000000FF4D5F728000000000FF224A9A0000000000FA",
"end_key": "",
"epoch": {
"conf_ver": 23,
"version": 36
},
"peers": [
{
"id": 4010,
"store_id": 5
},
{
"id": 4011,
"store_id": 6
},
{
"id": 4012,
"store_id": 4
}
],
"leader": {
"id": 4010,
"store_id": 5
},
"written_bytes": 0,
"read_bytes": 0,
"written_keys": 0,
"read_keys": 0,
"approximate_size": 99,
"approximate_keys": 773985
}
为更好的理解，根据以上的多个region信息我们可以绘制针对表t_user的数据region的分布图：
结合表t_user的region分布图，我们可以推论出如下的情况：
1、如果只宕掉一台机器：
由于是三副本集群，始终只有一个副本或者没有副本挂掉，tikv可用性和正确性理论上不会受影响。
2、如果同时宕掉两台机器：
三副本集群中，存在只有一个副本挂掉，也会存在两个副本同时挂掉的情况，当然只用一个副本挂掉，Tikv可用性和正确性理论上不会受影响。当有两个副本挂掉，Tikv集群将不可用。
例如：在此例中，宕掉Tikv2135和宕掉Tikb5138这两台机器，只有两个region的一个副本挂掉，并不会影响到整个集群，但是如果是宕掉Tikv3136和Tikv4137，则会出现两个region的两个副本均挂掉，对此表的SQL无法查询，但由于还有一个副本的存在，通过复制幸存的副本进行复制并重新进行Leader的选举进行灾难恢复后数据任然能够被找回，当然可能挂掉的两个副本其中一个为Leader，部分数据未能从Leader同步到Follower则存在有少量未提交的数据的丢失。
3、如果同时宕掉三台或更多机器：
理论上，一、二、三个副本挂掉的情况都有可能出现，然而会出现最为严重的情况，即为三副本的数据全部丢失，整个表的数据会因为某个region的丢失而出现数据库灾难恢复后表数据的丢失。例如如果是宕掉Tikv1 134、Tikv2135和Tikv3136，会出现region的两副本挂掉的情况，通过灾难恢复可以找回，但是如果挂掉的是Tikv1 134、Tikv3136和Tikv4137，将会有2个region的所有副本均丢失的情况，数据将出现丢失。
这里我们只是以一张表的region分布为例，实际环境中，表的region分布远比此复杂，在三副本设置的情况下，同时两台主机宕掉的情况下，出现两副本丢失的概率还是较大，当然实际生产中同时宕掉两台机器的情况较小，如果对容灾有更高要求，也可以选择五副本。
副本数据恢复包含两个部分：故障Region 处理和丢失数据处理故障 Region处理，针对 Region数据丢失的严重情况，可分为两种：
Region 至少还有 1个副本，恢复思路是在Region的剩余副本上移除掉所有位于故障节点上的副本，这样可以用这些剩余副本来重新选举和补充副本来恢复，但这些剩余副本中可能不包含最新的Raft Log 更新，这个时候就会丢失部分数据Region 的所有副本都丢失了，这个Region 的数据就丢失了，无法恢复。
可以通过创建1 个空 Region来解决 Region不可用的问题在恢复 Region故障的过程中，要详细记录下所处理Region 的信息，如Region ID、Region丢失副本的数量等丢失数据处理
根据故障 RegionID 找到对应的表，找到相关用户并询问用户在故障前的某一段时间内（比如5 min），大概写入了哪些数据表，是否有DDL 操作，是否可以重新消费更上游的数据来再次写入，等等。
如果可以重导，则是最简单的处理方式。否则的话，则只能对重要的数据表，检查数据索引的一致性，保证还在的数据是正确无误的。至此我们对Tidb副本的作用以及限制有也一定的了解，接下来我们会对region的两副本丢失和三副本丢失的场景进行演练，下回见。
参考文档https://book.tidb.io/session3/chapter5/recover-quorum.html
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/130204.html
摘要：为云计算灾难做好准备要为云计算灾难做好准备，企业需要不断测试其数据恢复框架。与内部部署的灾难恢复相比，云计算灾难恢复更加简单。云计算灾难恢复的最佳实践选择合适的灾难恢复计划方法要制定合适的灾难恢复计划，企业了解其基础设施非常重要。考虑到当今商业环境中采用的云计算技术迅速增加，从导致服务中断和停机的灾难中有效恢复的能力变得更加重要。基于云计算的灾难恢复可以确保企业在尽可能短的时间内恢复其数据和...
摘要：基于云迁移的三个阶段细分为八个主要步骤，评估阶段主要包括项目启动现状梳理以及应用系统关联关系分析三个步骤，设计阶段包括云架构优化设计和云迁移方案设计，实施阶段包括目标架构迁移演练及实施和试运行三个步骤。 在云计算市场规模不断扩大的大背景下，云迁移的需求越来越大且面临挑战。云迁移不是一个迁移软件工具，而是一种服务。前IBM资深架构师姜亚杰从云迁移的三个阶段、四个维度到八个步骤的方法，简述...
摘要：物联网也影响着数据中心的安全性，主要是随着资源和数据数量和质量的增长，人们增加了对数据中心安全性的需求。新的物联网设备是和执行数据分析的其他系统的常见补充，这些设备会导致网络使用和需求增加。网络威胁对于数据中心来说是一个不幸的现实，这些数据中心在防止违规事件方面面临许多挑战。近年来，这种风险一直在增加，超过40％的受访者在Carbonite公司进行的调查报告中表示，所面临的黑客、勒索软件和其...
摘要：在全世界的聚焦之下，为年伦敦奥运会运行基础设施的团队将更多重点放在了可靠性上，而不会展示尖端技术。这意味着热门技术例如云计算将不会成为奥运会基础设施的核心部分。表示，每届奥运会相隔四年，这使确保基础设施保持状况成为非常棘手的事情。 在全世界的聚焦之下，为2012年伦敦奥运会运行IT基础设施的团队将更多重点放在了可靠性上，而不会展示尖端技术。 这意味着热门技术(例如云计算)将不会成为奥运会I...
摘要：日前，广东华兴银行总行与科华恒盛就总行灾备数据中心规划建设展开深入合作。项目建成后将全面提升广东华兴银行数据安全保障及运维服务水平，为其总行全球业务提供小时不间断的同城灾备服务，为银行业务稳定运行实现高速增长奠定牢固的信息化基础。随着云计算、大数据等新ICT技术的高速发展，银行业信息化建设的步伐愈行愈快。日前，广东华兴银行总行与科华恒盛就总行灾备数据中心规划建设展开深入合作。科华恒盛将为其提...
阅读 1346·2023-01-11 13:20
阅读 1684·2023-01-11 13:20
阅读 1132·2023-01-11 13:20
阅读 1858·2023-01-11 13:20
阅读 4099·2023-01-11 13:20
阅读 2704·2023-01-11 13:20
阅读 1385·2023-01-11 13:20
阅读 3594·2023-01-11 13:20
