CN115292101A - 一种元数据异常状态恢复方法、装置、设备、存储介质 - Google Patents

Abstract

本申请公开了一种元数据异常状态恢复方法、装置、设备、存储介质，涉及数据存储技术领域，包括：通过客户端服务器运行预设状态检查脚本对预设BeeGFS文件系统中的元数据组中的元数据的原始数据状态以及对应的镜像元数据状态进行状态检查；若检查原始数据状态与镜像元数据状态均为异常状态，则将元数据的原始数据状态设置为正常状态；触发对镜像元数据进行的数据同步操作，完成元数据异常状态恢复。通过在客户端执行预设状态检查脚本，检测到可以在元数据Buddy Group出现状态异常后，强制使元数据的原始数据状态变为Good状态来触发镜像元数据进行数据同步并启动客户端服务，挂载BeeGFS文件系统，避免出现因为元数据无法正常同步而造成客户端无法访问BeeGFS文件系统。

Description

一种元数据异常状态恢复方法、装置、设备、存储介质

技术领域

本发明涉及数据存储技术领域，特别涉及一种元数据异常状态恢复方法、装置、设备、存储介质。

背景技术

在大数据和人工智能的时代，超级计算中心或数据中心的存储需求已经从PB级向Exabyte级扩展，许多大数据和智能应用程序都需要在HPC(High Performance Computing，高性能计算系统)上运行，BeeGFS作为HPC行业领先的并行集群文件系统，能够提供高性能、高扩展性和高灵活性的文件存储，同时集群的高可用性也至关重要。BeeGFS文件系统通过Buddy Mirroring实现集群数据和元数据的高可用性，针对元数据节点异常断电重启后可能导致Buddy Group两个存储目标状态异常而无法同步数据的问题，现有技术通过在两台存储服务器上部署BeeGFS文件系统Meta服务后，需要在客户端上配置Meta服务BuddyGroup组，并开启元数据镜像功能来实现高可用性。当两台元数据服务器同时异常断电重启后，元数据Buddy Group组中的两个存储目标的一致性状态均会变成Needs-resync，从而导致元数据无法正常同步。而如果元数据Buddy Group组中两个存储目标的一致性状态均为Needs-resync且无法同步数据时，客户端上client服务会因启动失败而无法挂载BeeGFS文件系统。

综上，如何在BeeGFS文件系统元数据节点断电重后Buddy Group状态异常的情况下实现客户端成功启动挂载BeeGFS文件系统，实现数据同步是本领域有待解决的技术问题。

发明内容

有鉴于此，本发明的目的在于提供一种元数据异常状态恢复方法、装置、设备、存储介质，能够。其具体方案如下：

第一方面，本申请公开了一种元数据异常状态恢复方法，应用于预设BeeGFS文件系统，包括：

通过客户端服务器运行预设状态检查脚本对所述预设BeeGFS文件系统中的元数据组中的元数据的原始数据状态以及对应的镜像元数据状态进行状态检查；

若检查所述原始数据状态与所述镜像元数据状态均为异常状态，则将所述元数据的原始数据状态设置为正常状态；

触发对镜像元数据进行的数据同步操作，完成元数据异常状态恢复。

可选的，所述通过客户端服务器运行预设状态检查脚本对所述预设BeeGFS文件系统中的元数据组中的元数据的原始数据状态以及对应的镜像元数据状态进行状态检查之前，还包括：

启动客户端服务，并在客户端服务器中配置元数据服务的元数据组；

开启元数据镜像服务，以便利用所述元数据镜像服务对所述元数据进行镜像操作得到镜像元数据。

可选的，所述启动客户端服务，并在客户端服务器中配置元数据服务的元数据组之前，还包括：

在所述客户端服务器中安装预设BeeGFS文件系统的辅助服务以及启动客户端服务。

可选的，所述通过客户端服务器运行预设状态检查脚本对所述预设BeeGFS文件系统中的元数据组中的元数据的原始数据状态以及对应的镜像元数据状态进行状态检查，包括：

执行检测原始数据状态等于镜像元数据状态的状态检测指令对所述预设BeeGFS文件系统中的元数据组中的元数据的原始数据状态以及对应的镜像元数据状态进行状态检查。

可选的，所述执行检测原始数据状态等于镜像元数据状态的状态检测指令对所述预设BeeGFS文件系统中的元数据组中的元数据的原始数据状态以及对应的镜像元数据状态进行状态检查之后，还包括：

获取状态检查结果，并对所述状态检查结果进行判断；

判断所述原始数据状态和所述元数据状态均为异常状态和/或均为正常状态。

可选的，所述触发对镜像元数据进行的数据同步操作，包括：

根据设置为正常状态的元数据中的目标数据对镜像元数据进行数据同步操作，并结束执行预设状态检查脚本。

可选的，所述触发对镜像元数据进行的数据同步操作之后，还包括：

将预设BeeGFS文件系统重新挂载至客户端服务。

第二方面，本申请公开了一种元数据异常状态恢复装置，应用于预设BeeGFS文件系统，包括：

状态检查模块，用于通过客户端服务器运行预设状态检查脚本对所述预设BeeGFS文件系统中的元数据组中的元数据的原始数据状态以及对应的镜像元数据状态进行状态检查；

状态设置模块，用于若检查所述原始数据状态与所述镜像元数据状态均为异常状态，则将所述元数据的原始数据状态设置为正常状态；

数据同步模块，用于触发对镜像元数据进行的数据同步操作，完成元数据异常状态恢复。

第三方面，本申请公开了一种电子设备，包括：

存储器，用于保存计算机程序；

处理器，用于执行所述计算机程序，以实现前述公开的元数据异常状态恢复方法的步骤。

第四方面，本申请公开了一种计算机可读存储介质，用于存储计算机程序；其中，所述计算机程序被处理器执行时实现前述公开的元数据异常状态恢复方法的步骤。

由此可见，本申请公开了一种元数据异常状态恢复方法，应用于预设BeeGFS文件系统，包括：通过客户端服务器运行预设状态检查脚本对所述预设BeeGFS文件系统中的元数据组中的元数据的原始数据状态以及对应的镜像元数据状态进行状态检查；若检查所述原始数据状态与所述镜像元数据状态均为异常状态，则将所述元数据的原始数据状态设置为正常状态；触发对镜像元数据进行的数据同步操作，完成元数据异常状态恢复。可见，通过在客户端执行预设状态检查脚本，检查元数据状态与镜像元数据状态，若检测到可以在元数据Buddy Group出现状态异常后，强制使元数据的原始数据状态变为Good状态来触发镜像元数据进行数据同步并启动客户端服务，挂载BeeGFS文件系统，避免出现因为元数据无法正常同步而造成客户端无法访问BeeGFS文件系统。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本申请公开的一种元数据异常状态恢复方法流程图；

图2为本申请公开的一种BeeGFS文件系统元数据Buddy Group状态异常的解决方法流程图；

图3为本申请公开的一种具体的元数据异常状态恢复方法流程图；

图4为本申请公开的一种元数据异常状态恢复装置结构示意图；

图5为本申请公开的一种电子设备结构图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在大数据和人工智能的时代，超级计算中心或数据中心的存储需求已经从PB级向Exabyte级扩展，许多大数据和智能应用程序都需要在HPC(High Performance Computing，高性能计算系统)上运行，BeeGFS作为HPC行业领先的并行集群文件系统，能够提供高性能、高扩展性和高灵活性的文件存储，同时集群的高可用性也至关重要。BeeGFS文件系统通过Buddy Mirroring实现集群数据和元数据的高可用性，针对元数据节点异常断电重启后可能导致Buddy Group两个存储目标状态异常而无法同步数据的问题，现有技术通过在两台存储服务器上部署BeeGFS文件系统Meta服务后，需要在客户端上配置Meta服务BuddyGroup组，并开启元数据镜像功能来实现高可用性。当两台元数据服务器同时异常断电重启后，元数据Buddy Group组中的两个存储目标的一致性状态均会变成Needs-resync，从而导致元数据无法正常同步。而如果元数据Buddy Group组中两个存储目标的一致性状态均为Needs-resync且无法同步数据时，客户端上client服务会因启动失败而无法挂载BeeGFS文件系统。

为此，本申请公开了一种元数据异常状态恢复方案，能够在BeeGFS文件系统元数据节点断电重后Buddy Group状态异常的情况下实现客户端成功启动挂载BeeGFS文件系统，实现数据同步。

参照图1所示，本发明实施例公开了一种元数据异常状态恢复方法，应用于预设BeeGFS文件系统，包括：

步骤S11：通过客户端服务器运行预设状态检查脚本对所述预设BeeGFS文件系统中的元数据组中的元数据的原始数据状态以及对应的镜像元数据状态进行状态检查。

本实施例中，通过客户端服务器运行预设状态检查脚本对所述预设BeeGFS文件系统中的Buddy Group组中的Buddy Group的原始数据状态以及对应的镜像元数据状态进行状态检查，检查的结果可能是组中的元数据的原始数据状态为正常状态，镜像元数据的镜像元数据状态为正常状态；或者组中的元数据的原始数据状态为正常状态，镜像元数据的镜像元数据状态为异常状态；组中的元数据的原始数据状态为异常状态，镜像元数据的镜像元数据状态为正常状态；组中的元数据的原始数据状态为异常状态，镜像元数据的镜像元数据状态为异常状态，针对上述可能出现的状态结果进行后续处理。可以理解的是，如果两台存储服务器同时异常断电重启后，元数据Buddy Group组中两个存储目标的一致性状态均会变成Needs-resync，即两个目标数据都被认为是不同步的，并尝试重新同步中，由于没有存储目标为Good状态，故会导致元数据无法正常完成同步，因此需要对存储目标的状态进行状态检查，由于BeeGFS结合了多个存储服务器，以提供具有条带化文件内容的高度可扩展的共享网络文件系统。通过这种方式，它可以让用户克服单一服务器、单一网络互联、有限数量的硬盘等严格的性能限制。在这样的系统中，可以轻松满足大量客户端的高吞吐量需求，但即使在单个客户端也能从这个存储系统的聚合性能中获益。这是通过元数据和文件内容的分离来实现的。存储服务器负责存储用户文件实际内容的条带，而元数据服务器则负责协调存储服务器之间的文件放置和条带化，并在必要时通知客户端某些文件内容的详细信息。在访问文件内容时，BeeGFS客户端直接与存储服务器建立联系以执行文件I/O并同时与多个服务器通信，使应用程序真正实现对文件数据的并行化访问。为了使元数据访问延迟最小，BeeGFS也允许你在多个服务器上分发元数据，以便使每个元数据服务器能够存储全部文件系统的命名空间的一部分，因此，元数据中的正常的数据状态非常重要。

本实施例中，所述通过客户端服务器运行预设状态检查脚本对所述预设BeeGFS文件系统中的元数据组中的元数据的原始数据状态以及对应的镜像元数据状态进行状态检查之前，还包括：启动客户端服务，并在客户端服务器中配置元数据服务的元数据组；开启元数据镜像服务，以便利用所述元数据镜像服务对所述元数据进行镜像操作得到镜像元数据。可以理解的是，在进行状态检查之前需要在客户端服务器上配置Meta(元数据)服务的Buddy Group组，并开启mirror(镜像)功能。例如：通过下面服务配置指令配置元数据服务以及开启镜像服务，

beegfs-ctl--addmirrorgroup--nodetype＝metadata--groupid＝1--primary＝1--secondary＝2；

beegfs-ctl–mirrormd；

其中，primary代表原目标元数据，secondary代表镜像目标元数据。

本实施例中，所述启动客户端服务，并在客户端服务器中配置元数据服务的元数据组之前，还包括：在所述客户端服务器中安装预设BeeGFS文件系统的辅助服务以及启动客户端服务。可以理解的是，在客户端服务器上使用yum命令安装BeeGFS文件系统helperd和client服务，其中，预设系统服务和启动服务代码如下：yum install beegfs-clientbeegfs-helperd beegfs-utils；

需要注意的是，在客户端服务器安装启动相应服务之前，需要在两台服务端存储服务器上使用yum命令安装BeeGFS文件系统mgmtd(管理服务)、meta(元数据)服务、storage(存储)服务，安装代码如下所示：yum–y install beegfs-mgmtd beegfs-meta beegfs-storage，配置存储服务，像元数据服务进程一样，BeeGFS的数据存储服务进程除了需要知道在哪个路径下存储数据外，还需要知道管理服务进程的运行IP。通常，可以把多个存储服务进程分布在不同的节点以及/或者分配到一个存储服务进程下的不同的设备目标，比如多个逻辑卷中。另外，也可以给每个存储服务进程设置一个唯一标识ID。如果该进程内有多个设备目标，还可以为每个设备目标设置唯一标识ID。设置的原则是：进程标识ID+设备目标标识ID，例如某一个Storage Service的ID是1，而它配置了两个Target，此时就可以给第一个Target的ID设置为“101”，第二个Target的标识ID设置为“102”。

步骤S12：若检查所述原始数据状态与所述镜像元数据状态均为异常状态，则将所述元数据的原始数据状态设置为正常状态。

本实施例中，当通过预设状态检查脚本检查到原始数据状态与镜像元数据状态均为异常状态时，例如：断电重启后Buddy Group的异常状态如下：

然后，强制将元数据的原始数据状态，也即primary目标的状态由Needs-resync变为正常状态，也即Good状态。

步骤S13：触发对镜像元数据进行的数据同步操作，完成元数据异常状态恢复。

本实施例中，当元数据的状态出现为正常状态时，触发对镜像元数据进行数据同步的操作，也即对元数据中的数据进行同步操作，用于方便进行客户端服务器中BeeGFS文件系统的挂载，进而重启客户端，完成元数据异常状态的恢复。参照图2所示，图2为一种BeeGFS文件系统元数据Buddy Group状态异常的解决方法，包括：服务端安装BeeGFS文件系统mgmt、meta、storage服务，客户端安装BeeGFS文件系统helperd、client服务，客户端配置Buddy Group并开启mirror功能，客户端执行元数据状态检查脚本，最后，客户端重启client服务，实现了元数据异常状态时如何进行数据同步，并成功挂载BeeGFS文件系统实现客户端重新启动，可见，通过在客户端执行元数据Buddy Group状态检查脚本，当发现两个元数据存储目标一致性状态均为Needs-resync时，执行beegfs-ctl--setstate命令强制将原primary目标的状态设置为Good，这样secondary目标就能够正常同步数据，而不会因为元数据无法正常同步而造成客户端无法访问BeeGFS文件系统。

由此可见，本申请公开了一种元数据异常状态恢复方法，应用于预设BeeGFS文件系统，包括：通过客户端服务器运行预设状态检查脚本对所述预设BeeGFS文件系统中的元数据组中的元数据的原始数据状态以及对应的镜像元数据状态进行状态检查；若检查所述原始数据状态与所述镜像元数据状态均为异常状态，则将所述元数据的原始数据状态设置为正常状态；触发对镜像元数据进行的数据同步操作，完成元数据异常状态恢复。可见，通过在客户端执行预设状态检查脚本，检查元数据状态与镜像元数据状态，若检测到可以在元数据Buddy Group出现状态异常后，强制使元数据的原始数据状态变为Good状态来触发镜像元数据进行数据同步并启动客户端服务，挂载BeeGFS文件系统，避免出现因为元数据无法正常同步而造成客户端无法访问BeeGFS文件系统。

参照图3所示，本发明实施例公开了一种具体的元数据异常状态恢复方法，相对于上一实施例，本实施例对技术方案作了进一步的说明和优化。具体的：

步骤S21：执行检测原始数据状态等于镜像元数据状态的状态检测指令对所述预设BeeGFS文件系统中的元数据组中的元数据的原始数据状态以及对应的镜像元数据状态进行状态检查。

其中，步骤S21中更加详细的处理过程请参照前述公开的实施例内容，在此不再进行赘述。

步骤S22：获取状态检查结果，并对所述状态检查结果进行判断；判断所述原始数据状态和所述元数据状态均为异常状态和/或均为正常状态。

本实施例中，对所述状态检查结果进行相应的判断，可以理解的是，若检查结果一致，则在对检查结果一致的其中一个目标的状态进行判断，判断是正常状态，还是异常状态，需要注意的是，若是正常状态，则可以直接依赖正常状态的元数据中的数据信息进行数据同步操作。

步骤S23：若检查所述原始数据状态与所述镜像元数据状态均为异常状态，则将所述元数据的原始数据状态设置为正常状态。

本实施例中，若检查所述原始数据状态与所述镜像元数据状态均为异常状态，则说明二者中的状态没有一个是可以正常使用进行同步操作的目标元数据，那么则强制设置元数据的原始数据状态设置为正常状态，也即Good状态，在客户端服务器上执行元数据状态检查脚本，例如：检查脚本如下：sh meta_check.sh。其中，sh脚本的检查逻辑为：首先执行查看元数据Buddy Group状态的命令beegfs-ctl--listtargets--nodetype＝meta--state--mirrorgroups，如果发现两个target的一致性状态均为Needs-resync，则执行beegfs-ctl–setstate--nodetype＝meta--nodeid＝1--state＝good–force命令强制使原primary目标变成由Needs-resync状态强制变更为Good状态。

步骤S24：根据设置为正常状态的元数据中的目标数据对镜像元数据进行数据同步操作，并结束执行预设状态检查脚本，完成元数据异常状态恢复。

本实施例中，等待secondary目标完成数据同步也变成Good状态后，打印出BuddyGroup组状态信息，并结束脚本运行。其中，在触发对镜像元数据进行的数据同步操作之后，还包括：将预设BeeGFS文件系统重新挂载至客户端服务。在客户端服务器上重启client服务，即可重新挂载BeeGFS文件系统，例如通过下面指令进行挂载系统操作：systemctlrestart beegfs-client。

由此可见，本实施例通过解决元数据Buddy Group状态异常而无法同步数据的问题，元数据服务器在异常断电重后会出现Buddy Group组存储目标状态异常，通过强制令原始元数据的状态变更为正常状态，有效的解决了因异常断电重启导致的BeeGFS文件系统元数据Buddy Group状态异常而无法同步数据的问题。

参照图4所示，本发明实施例公开了一种元数据异常状态恢复装置，应用于预设BeeGFS文件系统，包括：

状态检查模块11，用于通过客户端服务器运行预设状态检查脚本对所述预设BeeGFS文件系统中的元数据组中的元数据的原始数据状态以及对应的镜像元数据状态进行状态检查；

状态设置模块12，用于若检查所述原始数据状态与所述镜像元数据状态均为异常状态，则将所述元数据的原始数据状态设置为正常状态；

数据同步模块13，用于触发对镜像元数据进行的数据同步操作，完成元数据异常状态恢复。

所述状态检查模块11，用于通过客户端服务器运行预设状态检查脚本对所述预设BeeGFS文件系统中的Buddy Group组中的Buddy Group的原始数据状态以及对应的镜像元数据状态进行状态检查，检查的结果可能是组中的元数据的原始数据状态为正常状态，镜像元数据的镜像元数据状态为正常状态；或者组中的元数据的原始数据状态为正常状态，镜像元数据的镜像元数据状态为异常状态；组中的元数据的原始数据状态为异常状态，镜像元数据的镜像元数据状态为正常状态；组中的元数据的原始数据状态为异常状态，镜像元数据的镜像元数据状态为异常状态，针对上述可能出现的状态结果进行后续处理。可以理解的是，如果两台存储服务器同时异常断电重启后，元数据Buddy Group组中两个存储目标的一致性状态均会变成Needs-resync，即两个目标数据都被认为是不同步的，并尝试重新同步中，由于没有存储目标为Good状态，故会导致元数据无法正常完成同步，因此需要对存储目标的状态进行状态检查。所述通过客户端服务器运行预设状态检查脚本对所述预设BeeGFS文件系统中的元数据组中的元数据的原始数据状态以及对应的镜像元数据状态进行状态检查之前，还包括：启动客户端服务，并在客户端服务器中配置元数据服务的元数据组；开启元数据镜像服务，以便利用所述元数据镜像服务对所述元数据进行镜像操作得到镜像元数据。可以理解的是，在进行状态检查之前需要在客户端服务器上配置Meta(元数据)服务的Buddy Group组，并开启mirror(镜像)功能。例如：通过下面服务配置指令配置元数据服务以及开启镜像服务，

beegfs-ctl--addmirrorgroup--nodetype＝metadata--groupid＝1--primary＝1--secondary＝2；

beegfs-ctl–mirrormd；

其中，primary代表原目标元数据，secondary代表镜像目标元数据。所述启动客户端服务，并在客户端服务器中配置元数据服务的元数据组之前，还包括：在所述客户端服务器中安装预设BeeGFS文件系统的辅助服务以及启动客户端服务。可以理解的是，在客户端服务器上使用yum命令安装BeeGFS文件系统helperd和client服务，其中，预设系统服务和启动服务代码如下：yum installbeegfs-client beegfs-helperd beegfs-utils；需要注意的是，在客户端服务器安装启动相应服务之前，需要在两台服务端存储服务器上使用yum命令安装BeeGFS文件系统mgmtd(管理服务)、meta(元数据)服务、storage(存储)服务，安装代码如下所示：yum–y install beegfs-mgmtd beegfs-meta beegfs-storage，配置存储服务，像元数据服务进程一样，BeeGFS的数据存储服务进程除了需要知道在哪个路径下存储数据外，还需要知道管理服务进程的运行IP。通常，可以把多个存储服务进程分布在不同的节点以及/或者分配到一个存储服务进程下的不同的设备目标，比如多个逻辑卷中。另外，也可以给每个存储服务进程设置一个唯一标识ID。如果该进程内有多个设备目标，还可以为每个设备目标设置唯一标识ID。设置的原则是：进程标识ID+设备目标标识ID，例如某一个Storage Service的ID是1，而它配置了两个Target，此时就可以给第一个Target的ID设置为“101”，第二个Target的标识ID设置为“102”。

所述状态设置模块12，用于对所述状态检查结果进行相应的判断，可以理解的是，若检查结果一致，则在对检查结果一致的其中一个目标的状态进行判断，判断是正常状态，还是异常状态，需要注意的是，若是正常状态，则可以直接依赖正常状态的元数据中的数据信息进行数据同步操作。若检查所述原始数据状态与所述镜像元数据状态均为异常状态，则说明二者中的状态没有一个是可以正常使用进行同步操作的目标元数据，那么则强制设置元数据的原始数据状态设置为正常状态，也即Good状态，在客户端服务器上执行元数据状态检查脚本，例如：检查脚本如下：sh meta_check.sh。其中，sh脚本的检查逻辑为：首先执行查看元数据Buddy Group状态的命令beegfs-ctl--listtargets--nodetype＝meta--state--mirrorgroups，如果发现两个target的一致性状态均为Needs-resync，则执行beegfs-ctl–setstate--nodetype＝meta--nodeid＝1--state＝good–force命令强制使原primary目标变成由Needs-resync状态强制变更为Good状态。当通过预设状态检查脚本检查到原始数据状态与镜像元数据状态均为异常状态时，例如：断电重启后Buddy Group的异常状态如下：

然后，强制将元数据的原始数据状态，也即primary目标的状态由Needs-resync变为正常状态，也即Good状态。

所述数据同步模块13，用于当元数据的状态出现为正常状态时，触发对镜像元数据进行数据同步的操作，也即对元数据中的数据进行同步操作，用于方便进行客户端服务器中BeeGFS文件系统的挂载，进而重启客户端，完成元数据异常状态的恢复。参照图2所示，图2为一种BeeGFS文件系统元数据Buddy Group状态异常的解决方法，包括：服务端安装BeeGFS文件系统mgmt、meta、storage服务，客户端安装BeeGFS文件系统helperd、client服务，客户端配置Buddy Group并开启mirror功能，客户端执行元数据状态检查脚本，最后，客户端重启client服务，实现了元数据异常状态时如何进行数据同步，并成功挂载BeeGFS文件系统实现客户端重新启动，可见，通过在客户端执行元数据Buddy Group状态检查脚本，当发现两个元数据存储目标一致性状态均为Needs-resync时，执行beegfs-ctl--setstate命令强制将原primary目标的状态设置为Good，这样secondary目标就能够正常同步数据，而不会因为元数据无法正常同步而造成客户端无法访问BeeGFS文件系统。等待secondary目标完成数据同步也变成Good状态后，打印出Buddy Group组状态信息，并结束脚本运行。其中，在触发对镜像元数据进行的数据同步操作之后，还包括：将预设BeeGFS文件系统重新挂载至客户端服务。在客户端服务器上重启client服务，即可重新挂载BeeGFS文件系统，例如通过下面指令进行挂载系统操作：systemctl restart beegfs-client。

由此可见，本申请公开了一种元数据异常状态恢复方法，应用于预设BeeGFS文件系统，包括：通过客户端服务器运行预设状态检查脚本对所述预设BeeGFS文件系统中的元数据组中的元数据的原始数据状态以及对应的镜像元数据状态进行状态检查；若检查所述原始数据状态与所述镜像元数据状态均为异常状态，则将所述元数据的原始数据状态设置为正常状态；触发对镜像元数据进行的数据同步操作，完成元数据异常状态恢复。可见，通过在客户端执行预设状态检查脚本，检查元数据状态与镜像元数据状态，若检测到可以在元数据Buddy Group出现状态异常后，强制使元数据的原始数据状态变为Good状态来触发镜像元数据进行数据同步并启动客户端服务，挂载BeeGFS文件系统，避免出现因为元数据无法正常同步而造成客户端无法访问BeeGFS文件系统。

在一些具体实施例中，所述元数据异常状态恢复装置，具体可以包括：

镜像单元，用于启动客户端服务，并在客户端服务器中配置元数据服务的元数据组；开启元数据镜像服务，以便利用所述元数据镜像服务对所述元数据进行镜像操作得到镜像元数据。

在一些具体实施例中，所述元数据异常状态恢复装置，具体可以包括：

服务安装单元，用于在所述客户端服务器中安装预设BeeGFS文件系统的辅助服务以及启动客户端服务。

在一些具体实施例中，所述状态检查模块11，具体可以包括：

状态检查单元，用于执行检测原始数据状态等于镜像元数据状态的状态检测指令对所述预设BeeGFS文件系统中的元数据组中的元数据的原始数据状态以及对应的镜像元数据状态进行状态检查。

在一些具体实施例中，所述元数据异常状态恢复装置，具体可以包括：

结果判断单元，用于获取状态检查结果，并对所述状态检查结果进行判断；判断所述原始数据状态和所述元数据状态均为异常状态和/或均为正常状态。

在一些具体实施例中，所述数据同步模块，具体可以包括：

数据同步单元，用于根据设置为正常状态的元数据中的目标数据对镜像元数据进行数据同步操作，并结束执行预设状态检查脚本。

在一些具体实施例中，所述元数据异常状态恢复装置，具体可以包括：

系统挂载单元，用于将预设BeeGFS文件系统重新挂载至客户端服务。

进一步的，本申请实施例还公开了一种电子设备，图5是根据一示例性实施例示出的电子设备20结构图，图中的内容不能认为是对本申请的使用范围的任何限制。

图5为本申请实施例提供的一种电子设备20的结构示意图。该电子设备20，具体可以包括：至少一个处理器21、至少一个存储器22、电源23、通信接口24、输入输出接口25和通信总线26。其中，所述存储器22用于存储计算机程序，所述计算机程序由所述处理器21加载并执行，以实现前述任一实施例公开的元数据异常状态恢复方法中的相关步骤。另外，本实施例中的电子设备20具体可以为电子计算机。

本实施例中，电源23用于为电子设备20上的各硬件设备提供工作电压；通信接口24能够为电子设备20创建与外界设备之间的数据传输通道，其所遵循的通信协议是能够适用于本申请技术方案的任意通信协议，在此不对其进行具体限定；输入输出接口25，用于获取外界输入数据或向外界输出数据，其具体的接口类型可以根据具体应用需要进行选取，在此不进行具体限定。

其中，处理器21可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器21可以采用DSP(DigitalSignalProcessing，数字信号处理)、FPGA(Field－Programmable Gate Array，现场可编程门阵列)、PLA(Programmable Logic Array，可编程逻辑阵列)中的至少一种硬件形式来实现。处理器21也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU(CentralProcessingUnit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器21可以在集成有GPU(Graphics Processing Unit，图像处理器)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器21还可以包括AI(ArtificialIntelligence，人工智能)处理器，该AI处理器用于处理有关机器学习的计算操作。

另外，存储器22作为资源存储的载体，可以是只读存储器、随机存储器、磁盘或者光盘等，其上所存储的资源可以包括操作系统221、计算机程序222等，存储方式可以是短暂存储或者永久存储。

其中，操作系统221用于管理与控制电子设备20上的各硬件设备以及计算机程序222，以实现处理器21对存储器22中海量数据223的运算与处理，其可以是Windows Server、Netware、Unix、Linux等。计算机程序222除了包括能够用于完成前述任一实施例公开的由电子设备20执行的元数据异常状态恢复方法的计算机程序之外，还可以进一步包括能够用于完成其他特定工作的计算机程序。数据223除了可以包括电子设备接收到的由外部设备传输进来的数据，也可以包括由自身输入输出接口25采集到的数据等。

进一步的，本申请还公开了一种计算机可读存储介质，用于存储计算机程序；其中，所述计算机程序被处理器执行时实现前述公开的元数据异常状态恢复方法。关于该方法的具体步骤可以参考前述实施例中公开的相应内容，在此不再进行赘述。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上对本发明所提供的一种元数据异常状态恢复方法、装置、设备、存储介质进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (10)

1.一种元数据异常状态恢复方法，其特征在于，应用于预设BeeGFS文件系统，包括：

通过客户端服务器运行预设状态检查脚本对所述预设BeeGFS文件系统中的元数据组中的元数据的原始数据状态以及对应的镜像元数据状态进行状态检查；

若检查所述原始数据状态与所述镜像元数据状态均为异常状态，则将所述元数据的原始数据状态设置为正常状态；

触发对镜像元数据进行的数据同步操作，完成元数据异常状态恢复。

2.根据权利要求1所述的元数据异常状态恢复方法，其特征在于，所述通过客户端服务器运行预设状态检查脚本对所述预设BeeGFS文件系统中的元数据组中的元数据的原始数据状态以及对应的镜像元数据状态进行状态检查之前，还包括：

启动客户端服务，并在客户端服务器中配置元数据服务的元数据组；

开启元数据镜像服务，以便利用所述元数据镜像服务对所述元数据进行镜像操作得到镜像元数据。

3.根据权利要求2所述的元数据异常状态恢复方法，其特征在于，所述启动客户端服务，并在客户端服务器中配置元数据服务的元数据组之前，还包括：

在所述客户端服务器中安装预设BeeGFS文件系统的辅助服务以及启动客户端服务。

4.根据权利要求1所述的元数据异常状态恢复方法，其特征在于，所述通过客户端服务器运行预设状态检查脚本对所述预设BeeGFS文件系统中的元数据组中的元数据的原始数据状态以及对应的镜像元数据状态进行状态检查，包括：

执行检测原始数据状态等于镜像元数据状态的状态检测指令对所述预设BeeGFS文件系统中的元数据组中的元数据的原始数据状态以及对应的镜像元数据状态进行状态检查。

5.根据权利要求4所述的元数据异常状态恢复方法，其特征在于，所述执行检测原始数据状态等于镜像元数据状态的状态检测指令对所述预设BeeGFS文件系统中的元数据组中的元数据的原始数据状态以及对应的镜像元数据状态进行状态检查之后，还包括：

获取状态检查结果，并对所述状态检查结果进行判断；

判断所述原始数据状态和所述元数据状态均为异常状态和/或均为正常状态。

6.根据权利要求1所述的元数据异常状态恢复方法，其特征在于，所述触发对镜像元数据进行的数据同步操作，包括：

根据设置为正常状态的元数据中的目标数据对镜像元数据进行数据同步操作，并结束执行预设状态检查脚本。

7.根据权利要求1至6任一项所述的元数据异常状态恢复方法，其特征在于，所述触发对镜像元数据进行的数据同步操作之后，还包括：

将预设BeeGFS文件系统重新挂载至客户端服务。

8.一种元数据异常状态恢复装置，其特征在于，应用于预设BeeGFS文件系统，包括：

状态检查模块，用于通过客户端服务器运行预设状态检查脚本对所述预设BeeGFS文件系统中的元数据组中的元数据的原始数据状态以及对应的镜像元数据状态进行状态检查；

状态设置模块，用于若检查所述原始数据状态与所述镜像元数据状态均为异常状态，则将所述元数据的原始数据状态设置为正常状态；

数据同步模块，用于触发对镜像元数据进行的数据同步操作，完成元数据异常状态恢复。

9.一种电子设备，其特征在于，包括：

存储器，用于保存计算机程序；

处理器，用于执行所述计算机程序，以实现如权利要求1至7任一项所述的元数据异常状态恢复方法的步骤。

10.一种计算机可读存储介质，其特征在于，用于存储计算机程序；其中，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述的元数据异常状态恢复方法的步骤。

Images