CN107402841A - 大规模分布式文件系统数据修复方法及设备 - Google Patents
大规模分布式文件系统数据修复方法及设备 Download PDFInfo
- Publication number
- CN107402841A CN107402841A CN201710198342.2A CN201710198342A CN107402841A CN 107402841 A CN107402841 A CN 107402841A CN 201710198342 A CN201710198342 A CN 201710198342A CN 107402841 A CN107402841 A CN 107402841A
- Authority
- CN
- China
- Prior art keywords
- data
- data block
- damage
- file
- length
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1435—Saving, restoring, recovering or retrying at system level using file system or storage system metadata
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/182—Distributed file systems
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Library & Information Science (AREA)
- Quality & Reliability (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明的目的是提供一种大规模分布式文件系统数据修复方法及设备，根据每个数据块管理模块视角的损坏的数据块及其最长可修复长度，和所述文件系统命名空间管理模块视角的损坏的数据块能够准确地确定实际损坏的数据块及其最长可修复长度，进而精确确定每个损坏文件中实际损坏的数据块及其最长可修复长度，在供电故障导致的分布式文件系统集群掉电重启进行数据修复的过程中，根据每个损坏文件中实际损坏的数据块及其最长可修复长度，对该损坏文件实现快速和有效数据修复，可以有效增大RPO、缩短RTO，即提高数据修复能力，减少数据修复耗时。
Description
技术领域
本发明涉及计算机领域，尤其涉及一种大规模分布式文件系统数据修复方法及设备。
背景技术
近年来，云计算技术日益普及，云计算产品线日益丰富，带来了巨大的社会价值。云存储产品是云计算产品线中的重要组成部分。各种云存储产品通常采用大规模分布式文件系统作为底层支撑系统来存储用户的数据。
典型分布式文件系统主要包含三个模块，以三种角色部署在由普通商用服务器构成的集群上。分布式文件系统的三个模块是指：
1.Client：客户端库，为用户提供访问分布式文件系统的各种接口；
2.Chunkserver：数据块(Chunk)管理模块，管理分布式文件系统的数据块及相关元数据，执行Master指派的任务；
3.Master：文件系统命名空间管理模块，管理分布式文件系统的元数据，如文件名到数据块元数据的映射等。
典型分布式文件系统的架构如图1所示，图1中，File name表示文件名，chunkindex表示数据块编号，chunk hadle表示数据块的唯一ID,chunk locations表示数据块位置，instructions to chunkserver表示向chunkserver发出的指令，chunkserver state表示向master反馈的指令执行状态，byte range表示用户一次写入的字节范围，是用户视角的内容，不涉及底层数据块的概念。数据块存储时，物理上表现为一个文件；逻辑上会按照固定大小切片计算校验和。
成本、性能等指标是衡量大规模分布式文件系统设计和实现优劣的重要指标，也是决定其所支撑公有云产品市场竞争力的重要因素。
为了降低成本，大规模分布式文件系统通常部署在由普通商用服务器构成的集群上。普通商用服务器通常不配备UPS、RAID卡等高端设备，普遍采用SATA磁盘作为持久存储设备。也就是说，普通商用服务器没有配备后备电源/电池等保护设备，机器断电后易失性存储器中存储的内容会立即丢失。
为了提高系统性能，大规模分布式文件系统在其文件读写路径上采用了多项优化性能的技术，简要介绍以下两种：
1.改进分布式文件系统层写协议。
在分布式文件系统中关于文件的信息分为两部分：元数据信息和数据信息(数据块)。其中元数据信息存储在Master中，数据信息存储在Chunkserver中。为了保证可靠写入，系统首先将数据信息写入Chunkserver中，然后将相关元数据信息写入Master中，并返回用户写入成功。为了减少与Master的交互，系统会向Chunkserver中写入若干次数据信息，并向用户返回写入成功，然后再将元数据信息写入Master。写入一组数据信息后只写入一次元数据信息可以有效降低写延迟，降低Master负载。
2.利用Linux文件系统提供的能力优化写操作性能。
Chunkserver负责管理分布式文件系统的数据块及相关元数据，即Chunk和OpLog。其中，OpLog即操作日志(Operation Log)，记录对存储系统数据结构的操作，数据库等存储系统通常采用OpLog来保证原子性和持久性，OpLog文件是存储系统数据结构变迁过程的一个增量视图。Chunk和OpLog以文件的形式写入Chunkserver进程所在机器(简称本机)的Linux文件系统，Linux文件系统进一步将数据写入本机持久存储设备中。为了提高写入Chunk文件和OpLog文件的性能，Chunkserver一般不会采用同步(sync)写，而是在数据写入Linux文件系统页面缓存(Page Cache)时就认为写操作已经成功。Linux文件系统页面缓存会被Linux文件系统后台线程周期性的持久化到存储设备上。Chunkserver进程利用Linux文件系统提供的Write Back机制有效提升了写操作的性能。
然而，各项优化技术带来性能提升的同时，也在一定程度上增加了数据丢失的可能性，损失了存储可靠性。上述两个优化机制带来的相应潜在问题表现如下：
1.改进的分布式文件系统层写协议将一组数据信息分若干次写入Chunkserver，然后只写一次元数据信息到Master。这将导致Chunkserver和Master两端的信息不同步，存在一个时间间隙。如果供电故障导致系统故障，那么Master存储的文件元数据表征的文件数据量将小于用户实际写入分布式文件系统的数据量。
2.Linux文件系统的Page Cache(页面缓存)的Write Back(回写)机制使得在Chunkserver返回Clinet数据写入成功到Chunkserver所在机器的文件系统将数据异步持久化到存储设备上存在一个时间差。如果分布式系统在这个时间差中因为供电故障等因素突然终止，缓存中的数据(Chunk文件)尚未持久化到存储设备中，就会发生数据丢失。如果丢失的数据是元数据(OpLog文件)，也会导致数据丢失。
出于降低系统成本、提高系统性能这两方面的考虑，供电故障导致的大规模分布式文件系统整体掉电，会使得存储的在易失性存储器里的元数据和数据信息来不及持久化到持久存储器中，进而导致一定程度上的数据损失。
在实际生产环境下，出于成本和性能的权衡，通常可以容忍一定限度的数据损失，并希望在集群掉电后可以尽可能快地修复数据，使系统可以重新对外提供服务。也就是说，生产环境中通常对存储系统设定了RPO和RTO。集群掉电重启后，为了满足设定的RPO和RTO，需要执行数据修复程序来尽最大能力修复数据，使系统恢复服务。
在介绍已有的数据修复流程之前，先简要总结一下相关的大规模分布式文件系统背景知识。大规模分布式文件系统有两个服务器角色：Master存储文件系统元数据信息，其中包括数据块的版本信息；Chunkserver存储文件系统的数据信息。这两个服务器角色均将要数据内容存储为Linux本地文件系统的文件，但安全级别是不同的。Master保证存储的内容同步(sync)更新到磁盘，可以认为集群掉电不会导致Master数据丢失。Chunkserver只保证存储的内容写入Linux操作系统的PageCache，在整机房掉电的场景下，Chunkserver存储在易失性存储器中的数据会丢失。另外Chunkserver会写OpLog，按照默认配置OpLog也只进PageCache，掉电后也会丢失。如果Chunkserver端OpLog丢失，造成的直接影响是Chunkserver端记录的Chunk版本(version)要小于Master端记录的Chunk version，Master会把这些version小的Chunkserver地址删掉。如果一个Chunk所在的所有location都被删掉了，那即使这个Chunk还有一部分数据，用现有的输入流也无法读出数据。
下面简要介绍一下现有的数据修复执行流程：
1.重启分布式存储系统集群，触发集群中各台Chunkserver完成Scrubbing。Scrubbing过程中，Chunkserver会校验所有数据块，并记录损坏数据块信息。其中，Scrubbing是指分布式存储系统ChunkServer结点校验本机所存储的所有数据块的过程。
2.等待Master完成Sniff过程。Sniff过程中Chunkserver会向Master报告本机存储的数据块(Chunk)的元信息，如版本号、是否损坏等。其中，Sniff是指分布式存储系统Master结点从系统中所有ChunkServer结点收集数据块(chunk)元信息的过程。
3.通过系统管理工具获取损坏文件列表FL。
4.从损坏文件列表FL中获取一个文件路径F，转5。
5.构造损坏文件F的输入流I，构造对应新文件NF的输出流O。
6.从输入流I中读取数据并写入输出流O。
7.如果在读取数据的过程中遇到没有合法副本信息的损坏Chunk，Client向集群中所有Chunkserver发起一次查询，询问所有Chunkserver上是否有该Chunk的副本以及Chunk的version。
8.Client得到所有Chunkserver的响应后，获取损坏Chunk对应的所有副本信息，其中包括一个version号的列表VL。
9.Client根据列表VL计算得到损坏Chunk的最大可读长度，并根据该长度修正Client中缓存的文件元数据信息，如文件长度、Chunk副本位置等信息。
10.根据所述最大可读长度读取当前损坏Chunk中的可信数据，并写入输出流。
11.根据文件类型，如果需要继续修复当前文件，转6；否则转12，在此文件类型包括LogFile(日志文件)和非LogFile(非日志文件)两种，其中，日志文件是一种文件格式。
12.如果FL为空，流程结束；否则，转4。
其中第11步根据文件类型判断是否需要修复当前文件的含义是：对于数据丢失来说，LogFile和非LogFile有所不同。LogFile以日志(Log)为单位存储数据，支持变长Chunk，非LogFile以Chunk为单位存储数据，Chunk长度固定。因为LogFile支持变长Chunk且以Log为单位存储数据，为了尽量多的修复数据，可以跨Chunk进行数据修复，即允许文件丢失数据散布在多个Chunk中，只要不存在损坏的Log即可；但非LogFile的Chunk是定长的(最后一个Chunk可以补足定长额度)，假设可以跨Chunk修复，那就必须要对不满定长额度且不是文件最后一个Chunk的Chunk进行补0，但又没有办法将补0的信息通知用户，用户可能将补0的部分当做真实数据，造成错误。所以对于LogFile来说，如果一个Chunk的所有副本读的RPC都失败，则跳过这个Chunk，继续读下一个Chunk，尽量去恢复数据。对于非LogFile的文件来说，如果一个Chunk的所有副本读的RPC(请求)都失败，则放弃掉后面所有的Chunk，即如果一个Chunk修复不了，这个Chunk后面的所有Chunk都不修复了。
根据上述背景知识和数据修复流程介绍可知现有数据修复流程存在以下缺陷：
1.修复能力有限。
(1)LogFile采用了“写入一组数据信息后只写入一次元数据信息”这一写协议优化。如果某LogFile已经写入一组Log数据信息，在更新文件元数据信息前系统整体掉电，那么Chunkserver端记录的可靠写入长度会大于Master端记录的可靠写入长度。
(2)现有文件输入流在读取Chunk数据前，会从Master请求Chunk元数据，并且为了优化性能会预取一组Chunk的元数据。在获取Chunk元数据后，会一次性解析所有元数据并更新到Client端的缓存中。如果在解析这组Chunk元数据的过程中遇到某个Chunk副本信息不足，会导致输入流状态异常，会导致即便这组Chunk中有未损坏Chunk也直接终止读取过程。
2.修复耗时较长。
(1)现有数据修复流程第1步中，触发集群中各台Chunkserver完成Scrubbing。Scrubbing过程中，Chunkserver会校验所有数据块，并记录损坏数据块信息。大规模分布式存储系统单台Chunkserver存储的数据块通常会存储数百万个数据块，完成一轮Scrubbing通常需要数十小时，成为整个数据修复流程中耗时最多的部分。
(2)现有数据修复流程的第6步中，“Client向集群中所有Chunkserver发起一次查询，询问所有Chunkserver上是否有该Chunk的副本以及Chunk的version”。大规模分布式存储集群通常由数百台乃至上千台Chunkserver构成，一次全Chunkserver集合的查询需要消耗Client大量资源，并且需要较长时间。而且，分布式文件系统中Chunk副本数默认值为3，即便存在Chunk副本复制，瞬间副本数也最多翻倍。因此数百上千个查询只会返回3～6个真实有价值的响应，消耗了系统资源和等待时间。
发明内容
本发明的一个目的是提供一种大规模分布式文件系统数据修复方法及设备，能够解决现有数据修复流程的修复能力有限和修复耗时较长的问题。
根据本发明的一个方面，提供了一种大规模分布式文件系统数据修复方法，该方法包括：
根据每个数据块管理模块视角的损坏的数据块及其最长可修复长度，和所述文件系统命名空间管理模块视角的损坏的数据块，确定每个损坏文件中实际损坏的数据块及其最长可修复长度；
根据每个损坏文件中实际损坏的数据块及其最长可修复长度，对该损坏文件进行数据修复。
进一步的，上述方法中，所述每个数据块管理模块视角的损坏的数据块及其最长可修复长度的获取，包括：
根据每个数据块管理模块上预设时间段内的操作日志，获取每个数据块管理模块该时间段内更新过的数据块；
校验每个更新过的数据块内的各个数据片，如果某个数据块内至少有一个数据片校验不通过，则将该数据片所在的数据块确定为损坏的数据块，确定每个损坏的数据块的最长可恢复长度，并在对应的数据块管理模块上将该数据块标记为损坏的数据块。
进一步的，上述方法中，校验每个更新过的数据块内的各个数据片，如果某个数据块内至少有一个数据片校验不通过，则将该数据片所在的数据块确定为损坏的数据块，确定每个损坏的数据块的最长可恢复长度，包括：
从数据块管理模块获取每个更新过的数据块的长度；
根据所述长度及数据片的规定长度，确定满足规定长度的数据片；
对每个满足规定长度的数据片计算新的校验和，并将所述新的校验和与之前存储该数据片的校验和作比较，如果不匹配，标记该损坏的数据片所在的数据块为损坏的数据块，该损坏的数据块的最大可修复长度＝至第一个不匹配的数据片之前的位置。
进一步的，上述方法中，该损坏的数据块的最大可修复长度＝所述第一个损坏的数据片之前的所有未损坏的数据片的长度之和的步骤之后还包括：
扫描该损坏的数据块对应的日志，如果存在一条日志，其记录的数据偏移量在该数据块的所述第一个不匹配的数据片的规定长度的区间之内，则读取从所述第一个不匹配的数据片的开始位置至所述偏移量结束位置的对应的数据，计算校验和，并与日志中记录的校验和作比较，如果一致，则更新该损坏的数据块的最大可修复长度＝偏移量处的位置。
进一步的，上述方法中，所述预设时间段内的操作日志的获取，包括：
在日志目录中查找是否有所述预设时间段内的快照，
若有，将所述快照转化为对应的日志，并从日志目录中读取在所述预设时间段内且在所述快照之后的日志，并将所述快照转化得到的日志和所述快照之后的日志作为所述预设时间段内的操作日志；
若无，在日志目录中读取所述预设时间段内的操作日志。
进一步的，上述方法中，所述文件系统命名空间管理模块视角的损坏的数据块的获取，包括：
根据所述数据块管理模块上标记为损坏的数据块，获取所述文件系统命名空间管理模块视角的损坏的数据块。
进一步的，上述方法中，确定每个损坏文件中实际损坏的数据块及其最长可修复长度，包括：
根据所述文件系统命名空间管理模块视角的损坏的数据块，过滤数据块管理模块视角的损坏的数据块中实际未损坏的数据块，并将未过滤掉的实际上损坏的数据块按照所在文件聚合，得到每个损坏文件中实际损坏的数据块及其最长可修复长度。
进一步的，上述方法中，根据每个损坏文件中实际损坏的数据块及其最长可修复长度，对该损坏文件进行数据修复，包括：
获取每个损坏文件的全集群视角的数据块元信息，其中，所述全集群视角的数据块元信息由文件系统命名空间管理模块视角的每个损坏文件所有数据块的存储位置，与该损坏文件中实际损坏的数据块的存储位置和最长可修复长度合并得到；
根据每个损坏文件的全集群视角的数据块元信息，对该损坏文件进行数据修复。
进一步的，上述方法中，根据每个损坏文件的全集群视角的数据块元信息，对该损坏文件进行数据修复，包括：
根据每个损坏文件的文件类型和全集群视角的数据块元信息，计算每个损坏文件的最长可修复长度；
根据每个损坏文件的最长可修复长度，对该损坏文件进行数据修复。
进一步的，上述方法中，根据每个损坏文件的文件类型和全集群视角的数据块元信息，计算每个损坏文件的最长可修复长度，包括：
根据全集群视角的数据块元信息中实际损坏的数据块的最长可修复长度，计算每个损坏文件中各实际损坏的数据块的实际最长可修复长度，其中，损坏文件的文件类型包括非日志文件和日志文件；
对于非日志文件，该非日志文件的最长可修复长度＝第一个实际损坏的数据块之前未损坏的数据块的长度+第一个实际损坏的数据块的实际最长可修复长度；
对于日志文件，该日志文件的最长可修复长度＝所有未损坏的数据块的长度+所有实际损坏的数据块的实际最长可修复长度。
进一步的，上述方法中，根据如下公式计算每个损坏文件中各实际损坏的数据块的实际最长可修复长度，
数据块的实际最长可修复长度＝min(Master_version,max(VL))，其中，VL表示各数据块管理模块视角的损坏的数据块的最长可修复长度，Master_version表示文件系统命名空间管理模块视角的该损坏的数据块的最长可修复长度。
根据本发明的另一方面，还提供了一种大规模分布式文件系统数据修复设备，该设备包括：
信息聚合模块，用于根据每个数据块管理模块视角的损坏的数据块及其最长可修复长度，和所述文件系统命名空间管理模块视角的损坏的数据块，确定每个损坏文件中实际损坏的数据块及其最长可修复长度；
数据修复模块，用于根据每个损坏文件中实际损坏的数据块及其最长可修复长度，对该损坏文件进行数据修复。
进一步的，上述设备中，还包括扫描模块，用于根据每个数据块管理模块上预设时间段内的操作日志，获取每个数据块管理模块该时间段内更新过的数据块；校验每个更新过的数据块内的各个数据片，如果某个数据块内至少有一个数据片校验不通过，则将该数据片所在的数据块确定为损坏的数据块，确定每个损坏的数据块的最长可恢复长度，并在对应的数据块管理模块上将该数据块标记为损坏的数据块。
进一步的，上述设备中，所述扫描模块，用于从数据块管理模块获取每个更新过的数据块的长度；根据所述长度及数据片的规定长度，确定满足规定长度的数据片；对每个满足规定长度的数据片计算新的校验和，并将所述新的校验和与之前存储该数据片的校验和作比较，如果不匹配，标记该损坏的数据片所在的数据块为损坏的数据块，该损坏的数据块的最大可修复长度＝至第一个不匹配的数据片之前的位置。
进一步的，上述设备中，所述扫描模块，还用于扫描该损坏的数据块对应的日志，如果存在一条日志，其记录的数据偏移量在该数据块的所述第一个不匹配的数据片的规定长度的区间之内，则读取从所述第一个不匹配的数据片的开始位置至所述偏移量结束位置的对应的数据，计算校验和，并与日志中记录的校验和作比较，如果一致，则更新该损坏的数据块的最大可修复长度＝偏移量处的位置。
进一步的，上述设备中，所述扫描模块，用于在日志目录中查找是否有所述预设时间段内的快照，
若有，将所述快照转化为对应的日志，并从日志目录中读取在所述预设时间段内且在所述快照之后的日志，并将所述快照转化得到的日志和所述快照之后的日志作为所述预设时间段内的操作日志；
若无，在日志目录中读取所述预设时间段内的操作日志。
进一步的，上述设备中，所述信息聚合模块，用于根据所述数据块管理模块上标记为损坏的数据块，获取所述文件系统命名空间管理模块视角的损坏的数据块。
进一步的，上述设备中，所述信息聚合模块，用于根据所述文件系统命名空间管理模块视角的损坏的数据块，过滤数据块管理模块视角的损坏的数据块中实际未损坏的数据块，并将未过滤掉的实际上损坏的数据块按照所在文件聚合，得到每个损坏文件中实际损坏的数据块及其最长可修复长度。
进一步的，上述设备中，所述数据修复模块，用于获取每个损坏文件的全集群视角的数据块元信息，其中，所述全集群视角的数据块元信息，由文件系统命名空间管理模块视角的每个损坏文件所有数据块的存储位置，与该损坏文件中实际损坏的数据块的存储位置和最长可修复长度合并得到；根据每个损坏文件的全集群视角的数据块元信息，对该损坏文件进行数据修复。
进一步的，上述设备中，所述数据修复模块，用于根据每个损坏文件的文件类型和全集群视角的数据块元信息，计算每个损坏文件的最长可修复长度；根据每个损坏文件的最长可修复长度，对该损坏文件进行数据修复。
进一步的，上述设备中，所述数据修复模块，用于根据全集群视角的数据块元信息中实际损坏的数据块的最长可修复长度，计算每个损坏文件中各实际损坏的数据块的实际最长可修复长度，其中，损坏文件的文件类型包括非日志文件和日志文件；
对于非日志文件，该非日志文件的最长可修复长度＝第一个实际损坏的数据块之前未损坏的数据块的长度+第一个实际损坏的数据块的实际最长可修复长度；
对于日志文件，该日志文件的最长可修复长度＝所有未损坏的数据块的长度+所有实际损坏的数据块的实际最长可修复长度。
进一步的，上述设备中，所述数据修复模块根据如下公式计算每个损坏文件中各实际损坏的数据块的实际最长可修复长度，
数据块的实际最长可修复长度＝min(Master_version,max(VL))，其中，VL表示各数据块管理模块视角的损坏的数据块的最长可修复长度，Master_version表示文件系统命名空间管理模块视角的该损坏的数据块的最长可修复长度。
根据本申请的另一方面，还提供了一种大规模分布式文件系统数据修复设备，其中，该设备包括：
处理器；
以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：
根据数据块管理模块视角的损坏的数据块及其最长可修复长度，和所述文件系统命名空间管理模块视角的损坏的数据块，确定损坏文件中实际损坏的数据块及其最长可修复长度；
根据损坏文件中实际损坏的数据块及其最长可修复长度，对该损坏文件进行数据修复。
与现有技术相比，本申请根据每个数据块管理模块视角的损坏的数据块及其最长可修复长度，和所述文件系统命名空间管理模块视角的损坏的数据块能够准确地确定实际损坏的数据块及其最长可修复长度，进而精确确定每个损坏文件中实际损坏的数据块及其最长可修复长度，在供电故障导致的分布式文件系统集群掉电重启进行数据修复的过程中，根据每个损坏文件中实际损坏的数据块及其最长可修复长度，对该损坏文件实现快速和有效数据修复，可以有效增大RPO、缩短RTO，即提高数据修复能力，减少数据修复耗时。
附图说明
通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显：
图1示出现有的典型分布式存储系统架构图；
图2示出根据本发明一个方面的一种大规模分布式文件系统数据修复方法的流程图；
图3示出本发明一优选的实施例的数据块扫描示意图；
图4示出本发明一优选的实施例的数据块数据布局示意图；
图5示出本发明一优选的实施例的获取有效OpLog的流程图；
图6示出本发明一优选的实施例的数据修复工具的部署结构图。
附图中相同或相似的附图标记代表相同或相似的部件。
具体实施方式
下面结合附图对本发明作进一步详细描述。
在本申请一个典型的配置中，终端、服务网络的设备和可信方均包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
如图2所示，本申请提供一种大规模分布式文件系统数据修复方法，该方法包括：
步骤S1，根据每个数据块管理模块视角的损坏的数据块及其最长可修复长度，和所述文件系统命名空间管理模块视角的损坏的数据块，确定每个损坏文件中实际损坏的数据块及其最长可修复长度；具体的，最大可修复长度是指数据块出错后，其数据可以修复的最大长度，由于一个数据块可能在多个Chunkserver(数据块管理模块)上存有副本，只有当所有Chunkserver上的同一数据块的副本都损坏时，从Master(文件系统命名空间管理模块)视角这个数据块才是实际损坏的，在此，根据每个数据块管理模块视角的损坏的数据块及其最长可修复长度，和所述文件系统命名空间管理模块视角的损坏的数据块能够准确地确定实际损坏的数据块及其最长可修复长度，进而精确确定每个损坏文件中实际损坏的数据块及其最长可修复长度；
步骤S2，根据每个损坏文件中实际损坏的数据块及其最长可修复长度，对该损坏文件进行数据修复。大规模分布式文件系统由多个软件模块构成，实现了多种文件类型，支撑了大量公有云产品。为了最大程度保护用户数据，提供更好的系统可用性，在分布式文件系统集群掉电后需要进行及时、有效的数据修复，即缩短RTO、增大RPO。其中，RPO为恢复点目标(Recovery Point Objective)，即离系统故障时间点最近的数据可恢复时间点，是衡量系统在灾难发生后将损失多少数据的指标；RTO为恢复时间目标(Recovery TimeObjective)，即从系统发生故障的时间点开始到恢复出RPO要求恢复的数为止所需要的时长，是衡量系统在灾难发生后服务恢复速度的指标。本实施例能够解决现在的修复方案修复能力有限，且修复耗时较长的问题，在供电故障导致的分布式文件系统集群掉电重启进行数据修复的过程中，根据每个损坏文件中实际损坏的数据块及其最长可修复长度，对该损坏文件实现快速和有效数据修复，可以有效增大RPO、缩短RTO，即提高数据修复能力，减少数据修复耗时。另外，可通过一系统管理命令模块，为系统管理员提供可以使用的管理命令，用于启动数据修复流程。
如图3所示，本申请一种大规模分布式文件系统数据修复方法一优选的实施例中，步骤S1中的所述每个数据块管理模块视角的损坏的数据块及其最长可修复长度的获取，包括：
根据每个数据块管理模块上预设时间段内的操作日志，获取每个数据块管理模块该时间段内更新过的数据块；具体的，根据设定时间段解析预设时间段内如默认为1小时内，数据块管理模块上的操作日志(OpLog)，取得1小时内更新过的数据块列表CL，图2中有效的OpLog是指：在约束时间范围内的OpLog，定义为有效的，比如1小时以内的OpLog；
校验每个更新过的数据块内的各个数据片，如果某个数据块内至少有一个数据片校验不通过，则将该数据片所在的数据块确定为损坏的数据块，确定每个损坏的数据块的最长可恢复长度，并在对应的数据块管理模块上将该数据块标记为损坏的数据块。在此，校验数据块管理模块磁盘上数据块(chunk)内的各个数据片，如果数据块内至少有一个数据片校验不通过，则将该数据片所在的数据块确定为损坏的数据块，并确定该损坏的数据块的最长可恢复长度，如果数据块内包含校验不通过的数据片，通知数据块管理模块将数据块标记为损坏数据块，便于后续Master完成Sniff发现数据块副本损坏信息，最后，汇总CL中每个Chunk的最大可修复长度，写到一个以数据块管理模块(Chunkserver)主机名命名的损坏Chunk列表文件中，文件名不妨记为CS_F，即一个Chunkserver对应一个CS_F文件，它存储在分布式存储系统中。本实施例类似于现有的Scrubbing，但比现有的Scrubbing方式简单本实施例只校验更新过的数据块，相比于原有数据修复流程第1步中ChunkserverScrubbing过程，Chunkserver根据OpLog得到设定时间段内更新过的数据块列表List，并对List内的数据块进行校验。解析OpLog获取已可靠写入的数据量，并以该长度校验数据块从而得到真实无错可靠的最大可修复长度，由于这个List内的数据块数量远小于Chunkserver所存储的所有数据块的数量，所以可以极大降低发现损坏数据块的时间，极大减少了需要处理的数据量，有效工作不再针对Chunkserver上的全部数据块，而是针对OpLog中设定时间段内有更新的数据块。实际系统中，运行时间低于1小时，极大降低了原有数据修复流程Scrubbing所需要的时间。将损坏数据块信息写入分布式文件系统的文件中，文件不妨记为CS_F，实际实现可以使用Chunkserver自己的IP地址来唯一标识。文件内容格式如下：
1.每个损坏数据块在CS_F文件中对应于一条记录。
2.每条记录有四个字段，即：
ChunkserverAddress、ChunkId、ChunkVersion、MaxRecoveryLength。
3.各个字段之间使用Tab字符分割，一条记录占用一行(即以“\n”作为记录的分隔符)。
其中，ChunkserverAddress表示数据块服务地址，ChunkId表示数据块的唯一编号，ChunkVersion表示数据块的最大可修复长度，MaxRecoveryLength是指数据块的最大可修复长度，即数据块出错后，数据块可以修复的最大长度，该长度必须得到ChunkserverOpLog的支持，主要因为OpLog中数据块的长度的是执行一条完整持久化产生的数据长度，方便开展后续的数据修复工作，即数据块的最大可修复长度必须小于等于日志中记录的该数据块持久化下来的长度。
本申请一种大规模分布式文件系统数据修复方法一优选的实施例中，校验每个更新过的数据块内的各个数据片，如果某个数据块内至少有一个数据片校验不通过，则将该数据片所在的数据块确定为损坏的数据块，确定每个损坏的数据块的最长可恢复长度，包括：
从数据块管理模块获取每个更新过的数据块的长度；
根据所述长度及数据片的规定长度，确定满足规定长度的数据片；
对每个满足规定长度的数据片计算新的校验和，并将所述新的校验和与之前存储该数据片的校验和作比较，如果不匹配，标记该损坏的数据片所在的数据块为损坏的数据块，该损坏的数据块的最大可修复长度＝至第一个不匹配的数据片之前的位置。具体的，如图4所示，是一个数据块的底层数据布局示意图。数据块底层以固定长度划分为数据片，每个数据片的规定长度为4KB，每个数据片对应一个4字节的校验和，在数据写入时一起写入，数据块最后一个数据片可能不足4KB，这个数据片被称为Tail，Tail对应的校验和记录在OpLog文件中。最大可修复长度是指数据块出错后，其数据可以修复的最大长度，该长度必须得到OpLog文件的支持。主要因为OpLog中数据块的长度的是执行一条完整持久化产生的数据长度，方便开展后续的数据修复工作。校验数据块，判定最大可修复长度的伪代码如下：
1.从Chunkserver获取数据块的长度Length。
2.根据Length，计算满足4KB的数据片的个数Count。
3.对每个满足4KB的数据片计算新的校验和，跟之前存储的校验和作比较，如果不匹配，标记该第一个损坏的数据片所在的数据块损坏，Chunkserver记录它为损坏数据块。记录损坏数据片索引为Index(序号)，所述序号从0开始编号。数据块的最大可修复长度MaxRecoveryLength＝4KB*Index。Chunkserver对List中的所有数据块执行上述流程，即可判定出数据块是否损坏及其最大可修复长度。
本申请一种大规模分布式文件系统数据修复方法一优选的实施例中，该损坏的数据块的最大可修复长度＝所述第一个损坏的数据片之前的所有未损坏的数据片的长度之和的步骤之后还包括：
扫描该损坏的数据块对应的日志，如果存在一条日志，其记录的数据偏移量在该数据块的所述第一个不匹配的数据片的规定长度的区间之内，则读取从所述第一个不匹配的数据片的开始位置至所述偏移量结束位置的对应的数据，计算校验和，并与日志中记录的校验和作比较，如果一致，则更新该损坏的数据块的最大可修复长度＝偏移量处的位置。例如，扫描该数据块对应的OpLog，如果存在一条Log，其记录的数据偏移Offset在[4KB*Index,4KB*(Index+1)]内，说明这条Log是某次持久化瞬间对应的Tail，这里的Tail可能是一个实际的Tail，也有可能是一个损坏的数据片的前半段可恢复部分，把这两种情况都认为是Tail，说明修复到满足4KB的数据片之后的数据片是个Tail，这个Tail的也是可修复的。读取[4KB*Index，Offset]对应的数据，计算校验和，并与OpLog中记录的校验和做比较。如果一致，MaxRecoveryLength＝Offset，否则，MaxRecoveryLength＝4KB*Index，保持不变。Chunkserver对List中的所有数据块执行上述流程，即可判定出数据块是否损坏及其最大可修复长度。
如图5所示，本申请一种大规模分布式文件系统数据修复方法一优选的实施例中，所述预设时间段内的操作日志的获取，包括：
在日志目录中查找是否有所述预设时间段内的快照(checkpoint)，在此，为了加快系统重启后重放OpLog的速度，定期对系统数据结构做一次Checkpoint，输出一个Checkpoint文件，Checkpoint文件是存储系统数据结构的一个全量视图；
若有，将所述快照转化为对应的日志，并从日志目录中读取在所述预设时间段内且在所述快照之后的日志，并将所述快照转化得到的日志和所述快照之后的日志作为所述预设时间段内的操作日志；
若无，在日志目录中读取所述预设时间段内的操作日志。
本申请一种大规模分布式文件系统数据修复方法一优选的实施例中，所述文件系统命名空间管理模块视角的损坏的数据块的获取，包括：
根据所述数据块管理模块上标记为损坏的数据块，获取所述文件系统命名空间管理模块视角的损坏的数据块。具体的，由于一个数据块可能在多个Chunkserver上存有副本，只有当从Master(文件系统命名空间管理模块)视角所有Chunkserver上的同一数据块的副本都损坏时，从Master视角这个数据块才是实际损坏的，Master根据前述Chunkserver中标记为损坏数据块进行Sniff，等待Master完成Sniff，从而精确获取到所述文件系统命名空间管理模块视角的损坏的数据块。
本申请一种大规模分布式文件系统数据修复方法一优选的实施例中，确定每个损坏文件中实际损坏的数据块及其最长可修复长度，包括：根据所述文件系统命名空间管理模块视角的损坏的数据块，过滤数据块管理模块视角的损坏的数据块中实际未损坏的数据块，并将未过滤掉的实际上损坏的数据块按照所在文件聚合，得到每个损坏文件中实际损坏的数据块及其最长可修复长度。具体的，由于一个数据块可能在多个Chunkserver上存有副本，只有当所有Chunkserver上的同一数据块的副本都损坏时，从Master视角这个数据块才是实际损坏，Master根据前述Chunkserver中标记为损坏数据块进行Sniff，等待Master完成Sniff，查询Master(文件系统命名空间管理模块)，获得Master视角已经发生损坏的Chunk集合MA_Chunks及相关元数据，元数据的记载的格式同CS_F文件中的格式。然后，从分布式存储系统中读取所有Chunkserver对应的CS_F，汇总各Chunkserver可能发生损坏的Chunk集合CS_Chunks及相关元数据。最后，根据MA_Chunks过滤CS_Chunks中实际未损坏的Chunk，并将实际上损坏的Chunk按照Chunk所在文件进行聚合，并将信息写入以文件ID命名的集合中，这个集合不妨记为Summary集合，这里的文件是指数据块所属的文件，一个文件包含多个数据块，一个数据块包含多个数据片，文件A对应有Summary_A集合，文件B对应有Summary_B集合。例如，聚合信息显示文件file损坏，那么分布式文件系统中将存在Summary集合//fileid/summary记录文件file损坏chunk的信息。Summary集合信息记录格式：
1.每个损坏数据块在Summary集合中对应于一条记录；
2.每条记录有四个字段：
ChunkserverAddress、ChunkId、ChunkVersion、MaxRecoveryLength；
3.各个字段之间使用Tab字符分割，一条记录占用一行(即以“\n”作为记录的分隔符)。
其中，多行损坏数据块信息按照ChunkId从小到大的顺序进行排序。
本申请一种大规模分布式文件系统数据修复方法一优选的实施例中，根据每个损坏文件中实际损坏的数据块及其最长可修复长度，对该损坏文件进行数据修复，包括：
获取每个损坏文件的全集群视角的数据块元信息，其中，所述全集群视角的数据块元信息，由文件系统命名空间管理模块视角的每个损坏文件所有数据块的存储位置，与该损坏文件中实际损坏的数据块的存储位置和最长可修复长度合并得到；具体的，文件系统命名空间管理模块(Master)视角的每个损坏文件所有数据块包括未发生损坏的和已经发生损坏的数据块，例如，Client文件输入流向Master请求数据块信息，获取Master视角的同一个文件内的所有的Chunk元信息。Client读取损坏文件对应的Summary集合中损坏Chunk信息，合并Master视角的Chunk元信息和Chunkserver视角的Chunk元信息(Summary集合中的元信息)，得到每个损坏文件的全集群视角的数据块元信息，将每个损坏文件的全集群视角的数据块元信息作为Client输入流缓存中；
根据每个损坏文件的全集群视角的数据块元信息，对该损坏文件进行数据修复。
本申请一种大规模分布式文件系统数据修复方法一优选的实施例中，根据每个损坏文件的全集群视角的数据块元信息，对该损坏文件进行数据修复，包括：
根据每个损坏文件的文件类型和全集群视角的数据块元信息，计算每个损坏文件的最长可修复长度；例如，根据文件类型和Client输入流缓存的全集群视角的数据块元信息，计算损坏文件最大可修复长度；
根据每个损坏文件的最长可修复长度，对该损坏文件进行数据修复。在此，Client得到了更新后的全集群视角的关于文件和数据块的元信息，按照更新后的文件层面的元数据及更新后的数据块层面的元信息，读取损坏文件，并将修复出的数据写入新文件中，由于所有数据块的元信息已经是最新的，不再需要向集群中的全部Chunkserver查询损坏数据块的信息，从而提高了数据修复能力，并且避免发起效用低下的全集群查询，减少数据修复所需的时间，提升了数据修复能力。
本申请一种大规模分布式文件系统数据修复方法一优选的实施例中，根据每个损坏文件的文件类型和全集群视角的数据块元信息，计算每个损坏文件的最长可修复长度，包括：
根据全集群视角的数据块元信息中实际损坏的数据块的最长可修复长度，计算每个损坏文件中各实际损坏的数据块的实际最长可修复长度，其中，损坏文件的文件类型包括非日志文件和日志文件；
对于非日志文件，该非日志文件的最长可修复长度＝第一个实际损坏的数据块之前未损坏的数据块的长度+第一个实际损坏的数据块的实际最长可修复长度；
对于日志文件，该日志文件的最长可修复长度＝所有未损坏的数据块的长度+所有实际损坏的数据块的实际最长可修复长度。具体的，根据文件类型和Client端缓存的Chunk元信息，计算文件的最大可修复长度。对于非LogFile只修复第一个损坏Chunk，采用summary集合中第一个损坏Chunk的最大可修复长度更新Client视角的文件长度(可靠写入且未发生损坏的长度)，非LogFile文件中修复的长度包括：之前未损坏的数据块和第一损坏的数据块的最大可修复长度。对于LogFile，Summary集合中的所有损坏Chunk均看做是可修复的，且最大可修复长度已经存储在Summary集合中，只需要解析到Client缓存中即可，LogFile文件中修复的长度包括：之前未损坏的数据块和所有损坏的数据块的最大可修复长度。
本申请一种大规模分布式文件系统数据修复方法一优选的实施例中，根据如下公式计算每个损坏文件中各实际损坏的数据块的实际最长可修复长度，
数据块的实际最长可修复长度＝min(Master_version,max(VL))，其中，VL表示各数据块管理模块视角的损坏的数据块的最长可修复长度，Master_version表示文件系统命名空间管理模块视角的该损坏的数据块的最长可修复长度。
根据本申请的另一面，还提供一种大规模分布式文件系统数据修复设备，该设备包括：
信息聚合模块，用于根据每个数据块管理模块视角的损坏的数据块及其最长可修复长度，和所述文件系统命名空间管理模块视角的损坏的数据块，确定每个损坏文件中实际损坏的数据块及其最长可修复长度；具体的，最大可修复长度是指数据块出错后，其数据可以修复的最大长度，由于一个数据块可能在多个Chunkserver(数据块管理模块)上存有副本，只有当所有Chunkserver上的同一数据块的副本都损坏时，从Master(文件系统命名空间管理模块)视角这个数据块才是实际损坏的，在此，根据每个数据块管理模块视角的损坏的数据块及其最长可修复长度，和所述文件系统命名空间管理模块视角的损坏的数据块能够准确地确定实际损坏的数据块及其最长可修复长度，进而精确确定每个损坏文件中实际损坏的数据块及其最长可修复长度；
数据修复模块，用于根据每个损坏文件中实际损坏的数据块及其最长可修复长度，对该损坏文件进行数据修复。大规模分布式文件系统由多个软件模块构成，实现了多种文件类型，支撑了大量公有云产品。为了最大程度保护用户数据，提供更好的系统可用性，在分布式文件系统集群掉电后需要进行及时、有效的数据修复，即缩短RTO、增大RPO。其中，RPO为恢复点目标(Recovery Point Objective)，即离系统故障时间点最近的数据可恢复时间点，是衡量系统在灾难发生后将损失多少数据的指标；RTO为恢复时间目标(RecoveryTime Objective)，即从系统发生故障的时间点开始到恢复出RPO要求恢复的数为止所需要的时长，是衡量系统在灾难发生后服务恢复速度的指标。本实施例能够解决现在的修复方案修复能力有限，且修复耗时较长的问题，在供电故障导致的分布式文件系统集群掉电重启进行数据修复的过程中，根据每个损坏文件中实际损坏的数据块及其最长可修复长度，对该损坏文件实现快速和有效数据修复，可以有效增大RPO、缩短RTO，即提高数据修复能力，减少数据修复耗时。另外，可通过一系统管理命令模块，为系统管理员提供可以使用的管理命令，用于启动数据修复流程。
本申请大规模分布式文件系统数据修复设备一优选的实施例中，还包括扫描模块，用于根据每个数据块管理模块上预设时间段内的操作日志，获取每个数据块管理模块该时间段内更新过的数据块；校验每个更新过的数据块内的各个数据片，如果某个数据块内至少有一个数据片校验不通过，则将该数据片所在的数据块确定为损坏的数据块，确定每个损坏的数据块的最长可恢复长度，并在对应的数据块管理模块上将该数据块标记为损坏的数据块。具体的，根据设定时间段解析预设时间段内如默认为1小时内，数据块管理模块上的操作日志(OpLog)，取得1小时内更新过的数据块列表CL，图2中有效的OpLog是指：在约束时间范围内的OpLog，定义为有效的，比如1小时以内的OpLog；在此，校验数据块管理模块磁盘上数据块(chunk)内的各个数据片，如果数据块内至少有一个数据片校验不通过，则将该数据片所在的数据块确定为损坏的数据块，并确定该损坏的数据块的最长可恢复长度，如果数据块内包含校验不通过的数据片，通知数据块管理模块将数据块标记为损坏数据块，便于后续Master完成Sniff发现数据块副本损坏信息，最后，汇总CL中每个Chunk的最大可修复长度，写到一个以数据块管理模块(Chunkserver)主机名命名的损坏Chunk列表文件中，文件名不妨记为CS_F，即一个Chunkserver对应一个CS_F文件，它存储在分布式存储系统中。本实施例类似于现有的Scrubbing，但比现有的Scrubbing方式简单本实施例只校验更新过的数据块，相比于原有数据修复流程第1步中Chunkserver Scrubbing过程，Chunkserver根据OpLog得到设定时间段内更新过的数据块列表List，并对List内的数据块进行校验。解析OpLog获取已可靠写入的数据量，并以该长度校验数据块从而得到真实无错可靠的最大可修复长度，由于这个List内的数据块数量远小于Chunkserver所存储的所有数据块的数量，所以可以极大降低发现损坏数据块的时间，极大减少了需要处理的数据量，有效工作不再针对Chunkserver上的全部数据块，而是针对OpLog中设定时间段内有更新的数据块。实际系统中，运行时间低于1小时，极大降低了原有数据修复流程Scrubbing所需要的时间。将损坏数据块信息写入分布式文件系统的文件中，文件不妨记为CS_F，实际实现可以使用Chunkserver自己的IP地址来唯一标识。文件内容格式如下：
1.每个损坏数据块在CS_F文件中对应于一条记录。
2.每条记录有四个字段，即：
ChunkserverAddress、ChunkId、ChunkVersion、MaxRecoveryLength。3.各个字段之间使用Tab字符分割，一条记录占用一行(即以“\n”作为记录的分隔符)。其中，ChunkserverAddress表示数据块服务地址，ChunkId表示数据块的唯一编号，ChunkVersion表示数据块的最大可修复长度，MaxRecoveryLength是指数据块的最大可修复长度，即数据块出错后，数据块可以修复的最大长度，该长度必须得到Chunkserver OpLog的支持，主要因为OpLog中数据块的长度的是执行一条完整持久化产生的数据长度，方便开展后续的数据修复工作，即数据块的最大可修复长度必须小于等于日志中记录的该数据块持久化下来的长度。详细的，如图6所示，所述Chunkserver数据扫描模块部署在分布式文件系统集群中的每台Chunkserver上，信息聚合模块、数据修复模块和系统管理命令模块均部署在集群的AG机器上。扫描模块，用于判定数据块文件的最大可修长度，AG等待所有扫描工具完成扫描，等待master完成一轮新的sniff，得到损坏chunk列表，汇总损坏chunk及其最大可修复长度，以数据块所在的文件为单位，写入Summary集合中，根据Summary集全中的信息修复损坏文件。另外，还可以把数据修复模块部署在集群中所有Chunkserver上，每个数据修复模块领取一部分损坏文件，进行修复，缩短修复时间，有效利用集群资源，实现负载均衡。此外，可使用MapReduce模型实现扫描模块、信息聚合模块和数据修复模块。
按照一定格式写入分布式存储系统的文件中。
本申请大规模分布式文件系统数据修复设备一优选的实施例中，所述扫描模块，用于从数据块管理模块获取每个更新过的数据块的长度；根据所述长度及数据片的规定长度，确定满足规定长度的数据片；对每个满足规定长度的数据片计算新的校验和，并将所述新的校验和与之前存储该数据片的校验和作比较，如果不匹配，标记该损坏的数据片所在的数据块为损坏的数据块，该损坏的数据块的最大可修复长度＝至第一个不匹配的数据片之前的位置。具体的，如图4所示，是一个数据块的底层数据布局示意图。数据块底层以固定长度划分为数据片，每个数据片的规定长度为4KB，每个数据片对应一个4字节的校验和，在数据写入时一起写入，数据块最后一个数据片可能不足4KB，这个数据片被称为Tail，Tail对应的校验和记录在OpLog文件中。最大可修复长度是指数据块出错后，其数据可以修复的最大长度，该长度必须得到OpLog文件的支持。主要因为OpLog中数据块的长度的是执行一条完整持久化产生的数据长度，方便开展后续的数据修复工作。校验数据块，判定最大可修复长度的伪代码如下：
1.从Chunkserver获取数据块的长度Length。
2.根据Length，计算满足4KB的数据片的个数Count。
3.对每个满足4KB的数据片计算新的校验和，跟之前存储的校验和作比较，如果不匹配，标记该第一个损坏的数据片所在的数据块损坏，Chunkserver记录它为损坏数据块。记录损坏数据片索引为Index(序号)，所述序号从0开始编号。数据块的最大可修复长度MaxRecoveryLength＝4KB*Index。Chunkserver对List中的所有数据块执行上述流程，即可判定出数据块是否损坏及其最大可修复长度。
本申请大规模分布式文件系统数据修复设备一优选的实施例中，所述扫描模块，还用于扫描该损坏的数据块对应的日志，如果存在一条日志，其记录的数据偏移量在该数据块的所述第一个不匹配的数据片的规定长度的区间之内，则读取从所述第一个不匹配的数据片的开始位置至所述偏移量结束位置的对应的数据，计算校验和，并与日志中记录的校验和作比较，如果一致，则更新该损坏的数据块的最大可修复长度＝偏移量处的位置。例如，扫描该数据块对应的OpLog，如果存在一条Log，其记录的数据偏移Offset在[4KB*Index,4KB*(Index+1)]内，说明这条Log是某次持久化瞬间对应的Tail，这里的Tail可能是一个实际的Tail，也有可能是一个损坏的数据片的前半段可恢复部分，把这两种情况都认为是Tail，说明修复到满足4KB的数据片之后的数据片是个Tail，这个Tail的也是可修复的。读取[4KB*Index，Offset]对应的数据，计算校验和，并与OpLog中记录的校验和做比较。如果一致，MaxRecoveryLength＝Offset，否则，MaxRecoveryLength＝4KB*Index，保持不变。Chunkserver对List中的所有数据块执行上述流程，即可判定出数据块是否损坏及其最大可修复长度。
如图5所示，本申请大规模分布式文件系统数据修复设备一优选的实施例中，所述扫描模块，用于在日志目录中查找是否有所述预设时间段内的快照(checkpoint)，在此，为了加快系统重启后重放OpLog的速度，定期对系统数据结构做一次Checkpoint，输出一个Checkpoint文件，Checkpoint文件是存储系统数据结构的一个全量视图；
若有，将所述快照转化为对应的日志，并从日志目录中读取在所述预设时间段内且在所述快照之后的日志，并将所述快照转化得到的日志和所述快照之后的日志作为所述预设时间段内的操作日志；
若无，在日志目录中读取所述预设时间段内的操作日志。
本申请大规模分布式文件系统数据修复设备一优选的实施例中，所述信息聚合模块，用于根据所述数据块管理模块上标记为损坏的数据块，获取所述文件系统命名空间管理模块视角的损坏的数据块。具体的，由于一个数据块可能在多个Chunkserver上存有副本，只有当从Master(文件系统命名空间管理模块)视角所有Chunkserver上的同一数据块的副本都损坏时，从Master视角这个数据块才是实际损坏的，Master根据前述Chunkserver中标记为损坏数据块进行Sniff，等待Master完成Sniff，从而精确获取到所述文件系统命名空间管理模块视角的损坏的数据块。
本申请大规模分布式文件系统数据修复设备一优选的实施例中，所述信息聚合模块，用于根据所述文件系统命名空间管理模块视角的损坏的数据块，过滤数据块管理模块视角的损坏的数据块中实际未损坏的数据块，并将未过滤掉的实际上损坏的数据块按照所在文件聚合，得到每个损坏文件中实际损坏的数据块及其最长可修复长度。具体的，由于一个数据块可能在多个Chunkserver上存有副本，只有当所有Chunkserver上的同一数据块的副本都损坏时，从Master视角这个数据块才是实际损坏，Master根据前述Chunkserver中标记为损坏数据块进行Sniff，等待Master完成Sniff，查询Master(文件系统命名空间管理模块)，获得Master视角已经发生损坏的Chunk集合MA_Chunks及相关元数据，元数据的记载的格式同CS_F文件中的格式。然后，从分布式存储系统中读取所有Chunkserver对应的CS_F，汇总各Chunkserver可能发生损坏的Chunk集合CS_Chunks及相关元数据。最后，根据MA_Chunks过滤CS_Chunks中实际未损坏的Chunk，并将实际上损坏的Chunk按照Chunk所在文件进行聚合，并将信息写入以文件ID命名的集合中，这个集合不妨记为Summary集合，这里的文件是指数据块所属的文件，一个文件包含多个数据块，一个数据块包含多个数据片，文件A对应有Summary_A集合，文件B对应有Summary_B集合。例如，聚合信息显示文件file损坏，那么分布式文件系统中将存在Summary集合//fileid/summary记录文件file损坏chunk的信息。Summary集合信息记录格式：
1.每个损坏数据块在Summary集合中对应于一条记录；
2.每条记录有四个字段：
ChunkserverAddress、ChunkId、ChunkVersion、MaxRecoveryLength；
3.各个字段之间使用Tab字符分割，一条记录占用一行(即以“\n”作为记录的分隔符)。
其中，多行损坏数据块信息按照ChunkId从小到大的顺序进行排序。
本申请大规模分布式文件系统数据修复设备一优选的实施例中，所述数据修复模块，用于获取每个损坏文件的全集群视角的数据块元信息，其中，所述全集群视角的数据块元信息，由文件系统命名空间管理模块视角的每个损坏文件所有数据块的存储位置，与该损坏文件中实际损坏的数据块的存储位置和最长可修复长度合并得到；根据每个损坏文件的全集群视角的数据块元信息，对该损坏文件进行数据修复。具体的，文件系统命名空间管理模块(Master)视角的每个损坏文件所有数据块包括未发生损坏的和已经发生损坏的数据块，例如，Client文件输入流向Master请求数据块信息，获取Master视角的同一个文件内的所有的Chunk元信息。Client读取损坏文件对应的Summary集合中损坏Chunk信息，合并Master视角的Chunk元信息和Chunkserver视角的Chunk元信息(Summary集合中的元信息)，得到每个损坏文件的全集群视角的数据块元信息，将每个损坏文件的全集群视角的数据块元信息作为Client输入流缓存中。
本申请大规模分布式文件系统数据修复设备一优选的实施例中，所述数据修复模块，用于根据每个损坏文件的文件类型和全集群视角的数据块元信息，计算每个损坏文件的最长可修复长度；根据每个损坏文件的最长可修复长度，对该损坏文件进行数据修复。例如，根据文件类型和Client输入流缓存的全集群视角的数据块元信息，计算损坏文件最大可修复长度。在此，Client得到了更新后的全集群视角的关于文件和数据块的元信息，按照更新后的文件层面的元数据及更新后的数据块层面的元信息，读取损坏文件，并将修复出的数据写入新文件中，由于所有数据块的元信息已经是最新的，不再需要向集群中的全部Chunkserver查询损坏数据块的信息，从而提高了数据修复能力，并且避免发起效用低下的全集群查询，减少数据修复所需的时间，提升了数据修复能力。
本申请大规模分布式文件系统数据修复设备一优选的实施例中，所述数据修复模块，用于根据全集群视角的数据块元信息中实际损坏的数据块的最长可修复长度，计算每个损坏文件中各实际损坏的数据块的实际最长可修复长度，其中，损坏文件的文件类型包括非日志文件和日志文件；
对于非日志文件，该非日志文件的最长可修复长度＝第一个实际损坏的数据块之前未损坏的数据块的长度+第一个实际损坏的数据块的实际最长可修复长度；
对于日志文件，该日志文件的最长可修复长度＝所有未损坏的数据块的长度+所有实际损坏的数据块的实际最长可修复长度。具体的，根据文件类型和Client端缓存的Chunk元信息，计算文件的最大可修复长度。对于非LogFile只修复第一个损坏Chunk，采用summary集合中第一个损坏Chunk的最大可修复长度更新Client视角的文件长度(可靠写入且未发生损坏的长度)，非LogFile文件中修复的长度包括：之前未损坏的数据块和第一损坏的数据块的最大可修复长度。对于LogFile，Summary集合中的所有损坏Chunk均看做是可修复的，且最大可修复长度已经存储在Summary集合中，只需要解析到Client缓存中即可，LogFile文件中修复的长度包括：之前未损坏的数据块和所有损坏的数据块的最大可修复长度。
本申请大规模分布式文件系统数据修复设备一优选的实施例中，所述数据修复模块根据如下公式计算每个损坏文件中各实际损坏的数据块的实际最长可修复长度，
数据块的实际最长可修复长度＝min(Master_version,max(VL))，其中，VL表示各数据块管理模块视角的损坏的数据块的最长可修复长度，Master_version表示文件系统命名空间管理模块视角的该损坏的数据块的最长可修复长度。
综上所述，本申请根据每个数据块管理模块视角的损坏的数据块及其最长可修复长度，和所述文件系统命名空间管理模块视角的损坏的数据块能够准确地确定实际损坏的数据块及其最长可修复长度，进而精确确定每个损坏文件中实际损坏的数据块及其最长可修复长度，在供电故障导致的分布式文件系统集群掉电重启进行数据修复的过程中，根据每个损坏文件中实际损坏的数据块及其最长可修复长度，对该损坏文件实现快速和有效数据修复，可以有效增大RPO、缩短RTO，即提高数据修复能力，减少数据修复耗时。
此外，本申请还提供了一种大规模分布式文件系统数据修复设备，其中，该设备包括：
处理器；
以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：
根据数据块管理模块视角的损坏的数据块及其最长可修复长度，和所述文件系统命名空间管理模块视角的损坏的数据块，确定损坏文件中实际损坏的数据块及其最长可修复长度；
根据损坏文件中实际损坏的数据块及其最长可修复长度，对该损坏文件进行数据修复。
显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。
需要注意的是，本发明可在软件和/或软件与硬件的组合体中被实施，例如，可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一个实施例中，本发明的软件程序可以通过处理器执行以实现上文所述步骤或功能。同样地，本发明的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本发明的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。
另外，本发明的一部分可被应用为计算机程序产品，例如计算机程序指令，当其被计算机执行时，通过该计算机的操作，可以调用或提供根据本发明的方法和/或技术方案。而调用本发明的方法的程序指令，可能被存储在固定的或可移动的记录介质中，和/或通过广播或其他信号承载媒体中的数据流而被传输，和/或被存储在根据所述程序指令运行的计算机设备的工作存储器中。在此，根据本发明的一个实施例包括一个装置，该装置包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发该装置运行基于前述根据本发明的多个实施例的方法和/或技术方案。
对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。
Claims (23)
1.一种大规模分布式文件系统数据修复方法，其中，该方法包括：
根据数据块管理模块视角的损坏的数据块及其最长可修复长度，和所述文件系统命名空间管理模块视角的损坏的数据块，确定损坏文件中实际损坏的数据块及其最长可修复长度；
根据损坏文件中实际损坏的数据块及其最长可修复长度，对该损坏文件进行数据修复。
2.根据权利要求1所述的方法，其中，所述数据块管理模块视角的损坏的数据块及其最长可修复长度的获取，包括：
根据数据块管理模块上预设时间段内的操作日志，获取数据块管理模块该时间段内更新过的数据块；
校验更新过的数据块内的各个数据片，如果某个数据块内至少有一个数据片校验不通过，则将该数据片所在的数据块确定为损坏的数据块，确定损坏的数据块的最长可恢复长度，并在对应的数据块管理模块上将该数据块标记为损坏的数据块。
3.根据权利要求2所述的方法，其中，校验更新过的数据块内的各个数据片，如果某个数据块内至少有一个数据片校验不通过，则将该数据片所在的数据块确定为损坏的数据块，确定损坏的数据块的最长可恢复长度，包括：
从数据块管理模块获取更新过的数据块的长度；
根据所述长度及数据片的规定长度，确定满足规定长度的数据片；
对满足规定长度的数据片计算新的校验和，并将所述新的校验和与之前存储该数据片的校验和作比较，如果不匹配，标记该损坏的数据片所在的数据块为损坏的数据块，该损坏的数据块的最大可修复长度＝至第一个不匹配的数据片之前的位置。
4.根据权利要求3所述的方法，其中，该损坏的数据块的最大可修复长度＝所述第一个损坏的数据片之前的未损坏的数据片的长度之和的步骤之后还包括：
扫描该损坏的数据块对应的日志，如果存在一条日志，其记录的数据偏移量在该数据块的所述第一个不匹配的数据片的规定长度的区间之内，则读取从所述第一个不匹配的数据片的开始位置至所述偏移量结束位置的对应的数据，计算校验和，并与日志中记录的校验和作比较，如果一致，则更新该损坏的数据块的最大可修复长度＝偏移量处的位置。
5.根据权利要求2所述的方法，其中，所述预设时间段内的操作日志的获取，包括：
在日志目录中查找是否有所述预设时间段内的快照，
若有，将所述快照转化为对应的日志，并从日志目录中读取在所述预设时间段内且在所述快照之后的日志，并将所述快照转化得到的日志和所述快照之后的日志作为所述预设时间段内的操作日志；
若无，在日志目录中读取所述预设时间段内的操作日志。
6.根据权利要求2所述的方法，其中，所述文件系统命名空间管理模块视角的损坏的数据块的获取，包括：
根据所述数据块管理模块上标记为损坏的数据块，获取所述文件系统命名空间管理模块视角的损坏的数据块。
7.根据权利要求1所述的方法，其中，确定损坏文件中实际损坏的数据块及其最长可修复长度，包括：
根据所述文件系统命名空间管理模块视角的损坏的数据块，过滤数据块管理模块视角的损坏的数据块中实际未损坏的数据块，并将未过滤掉的实际上损坏的数据块按照所在文件聚合，得到损坏文件中实际损坏的数据块及其最长可修复长度。
8.根据权利要求1所述的方法，其中，根据损坏文件中实际损坏的数据块及其最长可修复长度，对该损坏文件进行数据修复，包括：
获取损坏文件的全集群视角的数据块元信息，其中，所述全集群视角的数据块元信息由文件系统命名空间管理模块视角的损坏文件数据块的存储位置，与该损坏文件中实际损坏的数据块的存储位置和最长可修复长度合并得到；
根据损坏文件的全集群视角的数据块元信息，对该损坏文件进行数据修复。
9.根据权利要求8所述的方法，其中，根据损坏文件的全集群视角的数据块元信息，对该损坏文件进行数据修复，包括：
根据损坏文件的文件类型和全集群视角的数据块元信息，计算损坏文件的最长可修复长度；
根据损坏文件的最长可修复长度，对该损坏文件进行数据修复。
10.根据权利要求9所述的方法，其中，根据损坏文件的文件类型和全集群视角的数据块元信息，计算损坏文件的最长可修复长度，包括：
根据全集群视角的数据块元信息中实际损坏的数据块的最长可修复长度，计算损坏文件中各实际损坏的数据块的实际最长可修复长度，其中，损坏文件的文件类型包括非日志文件和日志文件；
对于非日志文件，该非日志文件的最长可修复长度＝第一个实际损坏的数据块之前未损坏的数据块的长度+第一个实际损坏的数据块的实际最长可修复长度；
对于日志文件，该日志文件的最长可修复长度＝未损坏的数据块的长度+实际损坏的数据块的实际最长可修复长度。
11.根据权利要求10所述的方法，其中，根据如下公式计算损坏文件中各实际损坏的数据块的实际最长可修复长度，
数据块的实际最长可修复长度＝min(Master_version,max(VL))，其中，VL表示各数据块管理模块视角的损坏的数据块的最长可修复长度，Master_version表示文件系统命名空间管理模块视角的该损坏的数据块的最长可修复长度。
12.一种大规模分布式文件系统数据修复设备，其中，该设备包括：
信息聚合模块，用于根据数据块管理模块视角的损坏的数据块及其最长可修复长度，和所述文件系统命名空间管理模块视角的损坏的数据块，确定损坏文件中实际损坏的数据块及其最长可修复长度；
数据修复模块，用于根据损坏文件中实际损坏的数据块及其最长可修复长度，对该损坏文件进行数据修复。
13.根据权利要求12所述的设备，其中，还包括扫描模块，用于根据数据块管理模块上预设时间段内的操作日志，获取数据块管理模块该时间段内更新过的数据块；校验更新过的数据块内的各个数据片，如果某个数据块内至少有一个数据片校验不通过，则将该数据片所在的数据块确定为损坏的数据块，确定损坏的数据块的最长可恢复长度，并在对应的数据块管理模块上将该数据块标记为损坏的数据块。
14.根据权利要求13所述的设备，其中，所述扫描模块，用于从数据块管理模块获取更新过的数据块的长度；根据所述长度及数据片的规定长度，确定满足规定长度的数据片；对满足规定长度的数据片计算新的校验和，并将所述新的校验和与之前存储该数据片的校验和作比较，如果不匹配，标记该损坏的数据片所在的数据块为损坏的数据块，该损坏的数据块的最大可修复长度＝至第一个不匹配的数据片之前的位置。
15.根据权利要求14所述的设备，其中，所述扫描模块，还用于扫描该损坏的数据块对应的日志，如果存在一条日志，其记录的数据偏移量在该数据块的所述第一个不匹配的数据片的规定长度的区间之内，则读取从所述第一个不匹配的数据片的开始位置至所述偏移量结束位置的对应的数据，计算校验和，并与日志中记录的校验和作比较，如果一致，则更新该损坏的数据块的最大可修复长度＝偏移量处的位置。
16.根据权利要求13所述的设备，其中，所述扫描模块，用于在日志目录中查找是否有所述预设时间段内的快照，
若有，将所述快照转化为对应的日志，并从日志目录中读取在所述预设时间段内且在所述快照之后的日志，并将所述快照转化得到的日志和所述快照之后的日志作为所述预设时间段内的操作日志；
若无，在日志目录中读取所述预设时间段内的操作日志。
17.根据权利要求13所述的设备，其中，所述信息聚合模块，用于根据所述数据块管理模块上标记为损坏的数据块，获取所述文件系统命名空间管理模块视角的损坏的数据块。
18.根据权利要求12所述的设备，其中，所述信息聚合模块，用于根据所述文件系统命名空间管理模块视角的损坏的数据块，过滤数据块管理模块视角的损坏的数据块中实际未损坏的数据块，并将未过滤掉的实际上损坏的数据块按照所在文件聚合，得到损坏文件中实际损坏的数据块及其最长可修复长度。
19.根据权利要求12所述的设备，其中，所述数据修复模块，用于获取损坏文件的全集群视角的数据块元信息，其中，所述全集群视角的数据块元信息，由文件系统命名空间管理模块视角的损坏文件数据块的存储位置，与该损坏文件中实际损坏的数据块的存储位置和最长可修复长度合并得到；根据损坏文件的全集群视角的数据块元信息，对该损坏文件进行数据修复。
20.根据权利要求19所述的设备，其中，所述数据修复模块，用于根据损坏文件的文件类型和全集群视角的数据块元信息，计算损坏文件的最长可修复长度；根据损坏文件的最长可修复长度，对该损坏文件进行数据修复。
21.根据权利要求20所述的设备，其中，所述数据修复模块，用于根据全集群视角的数据块元信息中实际损坏的数据块的最长可修复长度，计算损坏文件中各实际损坏的数据块的实际最长可修复长度，其中，损坏文件的文件类型包括非日志文件和日志文件；
对于非日志文件，该非日志文件的最长可修复长度＝第一个实际损坏的数据块之前未损坏的数据块的长度+第一个实际损坏的数据块的实际最长可修复长度；
对于日志文件，该日志文件的最长可修复长度＝未损坏的数据块的长度+实际损坏的数据块的实际最长可修复长度。
22.根据权利要求21所述的设备，其中，所述数据修复模块根据如下公式计算损坏文件中各实际损坏的数据块的实际最长可修复长度，
数据块的实际最长可修复长度＝min(Master_version,max(VL))，其中，VL表示各数据块管理模块视角的损坏的数据块的最长可修复长度，Master_version表示文件系统命名空间管理模块视角的该损坏的数据块的最长可修复长度。
23.一种大规模分布式文件系统数据修复设备，其中，该设备包括：
处理器；
以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：
根据数据块管理模块视角的损坏的数据块及其最长可修复长度，和所述文件系统命名空间管理模块视角的损坏的数据块，确定损坏文件中实际损坏的数据块及其最长可修复长度；
根据损坏文件中实际损坏的数据块及其最长可修复长度，对该损坏文件进行数据修复。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610191794 | 2016-03-30 | ||
| CN2016101917943 | 2016-03-30 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107402841A true CN107402841A (zh) | 2017-11-28 |
| CN107402841B CN107402841B (zh) | 2021-01-29 |
Family
ID=60404321
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710198342.2A Active CN107402841B (zh) | 2016-03-30 | 2017-03-29 | 大规模分布式文件系统数据修复方法及设备 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107402841B (zh) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109656929A (zh) * | 2018-12-25 | 2019-04-19 | 四川效率源信息安全技术股份有限公司 | 一种雕复关系型数据库文件的方法及装置 |
| CN110874345A (zh) * | 2018-08-29 | 2020-03-10 | 阿里巴巴集团控股有限公司 | 分布式存储系统中的数据处理方法、装置和系统 |
| CN114780021A (zh) * | 2022-03-25 | 2022-07-22 | 北京百度网讯科技有限公司 | 副本修复方法、装置、电子设备及存储介质 |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2002033551A1 (en) * | 2000-10-18 | 2002-04-25 | Tricord Systems, Inc. | Controller fault recovery system for a distributed file system |
| CN1352427A (zh) * | 2001-11-26 | 2002-06-05 | 北京实达铭泰计算机应用技术开发有限公司 | 一种计算机系统恢复方法 |
| CN102279777A (zh) * | 2011-08-18 | 2011-12-14 | 成都市华为赛门铁克科技有限公司 | 数据冗余处理方法、装置和分布式存储系统 |
| CN103034567A (zh) * | 2012-12-06 | 2013-04-10 | 华为技术有限公司 | 发现并修复损坏数据的装置和方法 |
| KR20150061314A (ko) * | 2013-11-27 | 2015-06-04 | 주식회사 유투앤 | 네트워크 분산 파일 시스템 기반 iSCSI 스토리지 시스템에서의 장애 복구 방법 및 시스템 |
| CN104978336A (zh) * | 2014-04-08 | 2015-10-14 | 云南电力试验研究院（集团）有限公司电力研究院 | 基于Hadoop分布式计算平台的非结构化数据存储系统 |
-
2017
- 2017-03-29 CN CN201710198342.2A patent/CN107402841B/zh active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2002033551A1 (en) * | 2000-10-18 | 2002-04-25 | Tricord Systems, Inc. | Controller fault recovery system for a distributed file system |
| CN1352427A (zh) * | 2001-11-26 | 2002-06-05 | 北京实达铭泰计算机应用技术开发有限公司 | 一种计算机系统恢复方法 |
| CN102279777A (zh) * | 2011-08-18 | 2011-12-14 | 成都市华为赛门铁克科技有限公司 | 数据冗余处理方法、装置和分布式存储系统 |
| CN103034567A (zh) * | 2012-12-06 | 2013-04-10 | 华为技术有限公司 | 发现并修复损坏数据的装置和方法 |
| KR20150061314A (ko) * | 2013-11-27 | 2015-06-04 | 주식회사 유투앤 | 네트워크 분산 파일 시스템 기반 iSCSI 스토리지 시스템에서의 장애 복구 방법 및 시스템 |
| CN104978336A (zh) * | 2014-04-08 | 2015-10-14 | 云南电力试验研究院（集团）有限公司电力研究院 | 基于Hadoop分布式计算平台的非结构化数据存储系统 |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110874345A (zh) * | 2018-08-29 | 2020-03-10 | 阿里巴巴集团控股有限公司 | 分布式存储系统中的数据处理方法、装置和系统 |
| CN110874345B (zh) * | 2018-08-29 | 2023-04-11 | 阿里巴巴集团控股有限公司 | 分布式存储系统中的数据处理方法、装置和系统 |
| CN109656929A (zh) * | 2018-12-25 | 2019-04-19 | 四川效率源信息安全技术股份有限公司 | 一种雕复关系型数据库文件的方法及装置 |
| CN109656929B (zh) * | 2018-12-25 | 2023-06-02 | 四川效率源信息安全技术股份有限公司 | 一种雕复关系型数据库文件的方法及装置 |
| CN114780021A (zh) * | 2022-03-25 | 2022-07-22 | 北京百度网讯科技有限公司 | 副本修复方法、装置、电子设备及存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107402841B (zh) | 2021-01-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8108343B2 (en) | De-duplication and completeness in multi-log based replication | |
| US9727273B1 (en) | Scalable clusterwide de-duplication | |
| US10146643B2 (en) | Database recovery and index rebuilds | |
| US8250033B1 (en) | Replication of a data set using differential snapshots | |
| US9495370B1 (en) | Data recovery point review in a continuous data protection system | |
| CA2933790C (en) | Apparatus and method for creating a real time database replica | |
| US9009428B2 (en) | Data store page recovery | |
| US9588858B2 (en) | Periodic data replication | |
| US7681001B2 (en) | Storage system | |
| US7913044B1 (en) | Efficient incremental backups using a change database | |
| US7900088B1 (en) | System for performing incremental file system check | |
| EP2590078B1 (en) | Shadow paging based log segment directory | |
| KR20150070134A (ko) | 가상 데이터베이스를 생성하기 위한 소스 데이터베이스의 지정 시간 복사의 검색 | |
| US7487385B2 (en) | Apparatus and method for recovering destroyed data volumes | |
| CN101243446A (zh) | 从数据库镜像进行在线页还原 | |
| US10976942B2 (en) | Versioning a configuration of data storage equipment | |
| CN105573859A (zh) | 一种数据库的数据恢复方法和设备 | |
| US10705920B1 (en) | Method and system for implementing current, consistent, and complete backups | |
| US11704335B2 (en) | Data synchronization in a data analysis system | |
| US11625303B2 (en) | Automatic incremental repair of granular filesystem objects | |
| CN106445643A (zh) | 克隆、升级虚拟机的方法及设备 | |
| CN107402841A (zh) | 大规模分布式文件系统数据修复方法及设备 | |
| US10664361B1 (en) | Transactionally consistent backup of partitioned storage | |
| US7801859B1 (en) | Tracking filesystem backups | |
| CN105956046A (zh) | 一种字典的更新方法、系统和服务器 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |