A metadata abnormal state recovery method, device, equipment and storage medium

Abstract

The application discloses a metadata abnormal state recovery method and device, equipment and storage medium, and relates to the technical field of data storage. The method comprises the following steps: a preset state checking script is run through a client server to check the original data state of metadata in a metadata group in a preset BeeGFS file system and the corresponding mirror metadata state; if the original data state and the mirror metadata state are both abnormal states, the original data state of the metadata is set to a normal state; a data synchronization operation on the mirror metadata is triggered to complete metadata abnormal state recovery. By executing the preset state checking script on the client, it is detected that the original data state of the metadata can be forced to be changed to a Good state after the metadata Buddy Group appears an abnormal state, the mirror metadata is triggered to perform data synchronization, the client service is started, and the BeeGFS file system is mounted, so that the client cannot access the BeeGFS file system due to abnormal synchronization of the metadata.

Description

Technical Field

[0001] This invention relates to the field of data storage technology, and in particular to a method, apparatus, device, and storage medium for recovering metadata from abnormal states. Background Technology

[0002] In the era of big data and artificial intelligence, the storage needs of supercomputing centers or data centers have expanded from petabyte-level to exabyte-level. Many big data and intelligent applications need to run on HPC (High Performance Computing) systems. BeeGFS, as a leading parallel cluster file system in the HPC industry, can provide high-performance, highly scalable, and highly flexible file storage, while high availability of the cluster is also crucial. The BeeGFS file system achieves high availability of cluster data and metadata through Buddy Mirroring. Addressing the issue that abnormal power outages and restarts of metadata nodes may lead to abnormal states of two storage targets in a Buddy Group, preventing data synchronization, existing technologies require deploying the BeeGFS file system Meta service on two storage servers, configuring the Meta service BuddyGroup on the client, and enabling metadata mirroring to achieve high availability. When both metadata servers experience abnormal power outages and restarts simultaneously, the consistency state of both storage targets in the metadata Buddy Group will become Needs-resync, resulting in the inability to synchronize metadata. Furthermore, if the consistency state of both storage targets in the metadata Buddy Group is Needs-resync and data synchronization fails, the client service on the client will fail to mount the BeeGFS file system due to startup failure.

[0003] In summary, how to enable clients to successfully start and mount the BeeGFS file system and achieve data synchronization when the Buddy Group state is abnormal after a power outage and restart of the BeeGFS file system metadata node is a technical problem that needs to be solved in this field. Summary of the Invention

[0004] In view of this, the purpose of this invention is to provide a method, apparatus, device, and storage medium for recovering metadata from abnormal states. The specific solution is as follows:

[0005] In a first aspect, this application discloses a method for recovering metadata from abnormal states, applied to a pre-defined BeeGFS file system, comprising:

[0006] The client server runs a preset status check script to check the original data status of the metadata in the metadata group of the preset BeeGFS file system and the status of the corresponding image metadata.

[0007] If both the original data status and the image metadata status are found to be in an abnormal state, then the original data status of the metadata is set to a normal state.

[0008] Trigger a data synchronization operation on the image metadata to complete the recovery of the metadata from abnormal state.

[0009] Optionally, before running a preset status check script on the client server to check the original data status of the metadata in the metadata group of the preset BeeGFS file system and the corresponding mirror metadata status, the method further includes:

[0010] Start the client service and configure the metadata group for the metadata service in the client server;

[0011] Enable the metadata mirroring service so that the metadata can be mirrored to obtain mirrored metadata.

[0012] Optionally, before starting the client service and configuring the metadata group of the metadata service in the client server, the method further includes:

[0013] Install the default BeeGFS file system auxiliary services and start the client service on the client server.

[0014] Optionally, the step of running a preset status check script on the client server to check the original data status of the metadata in the metadata group of the preset BeeGFS file system and the corresponding mirror metadata status includes:

[0015] The execution of the state detection instruction, which checks whether the original data state is equal to the image metadata state, performs a state check on the original data state and the corresponding image metadata state of the metadata group in the preset BeeGFS file system.

[0016] Optionally, after executing the state detection instruction that detects the original data state as equal to the image metadata state to perform a state check on the original data state and the corresponding image metadata state of the metadata group in the preset BeeGFS file system, the method further includes:

[0017] Obtain the status check results and make a judgment on the status check results;

[0018] It is determined that both the original data status and the metadata status are in an abnormal state and / or both are in a normal state.

[0019] Optionally, the triggering of the data synchronization operation on the mirror metadata includes:

[0020] Perform data synchronization operations on the mirror metadata based on the target data in the metadata set to normal status, and then terminate the execution of the preset status check script.

[0021] Optionally, after triggering the data synchronization operation on the mirror metadata, the method further includes:

[0022] Remount the default BeeGFS file system to the client service.

[0023] Secondly, this application discloses a metadata abnormal state recovery device, applied to a preset BeeGFS file system, comprising:

[0024] The status check module is used to run a preset status check script on the client server to check the original data status of the metadata in the metadata group of the preset BeeGFS file system and the corresponding image metadata status.

[0025] The status setting module is used to set the original data status of the metadata to a normal status if both the original data status and the image metadata status are found to be in an abnormal state.

[0026] The data synchronization module is used to trigger data synchronization operations on the image metadata and complete the recovery of abnormal metadata states.

[0027] Thirdly, this application discloses an electronic device, including:

[0028] Memory, used to store computer programs;

[0029] A processor is configured to execute the computer program to implement the steps of the aforementioned disclosed method for restoring abnormal metadata states.

[0030] Fourthly, this application discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the steps of the aforementioned disclosed method for restoring abnormal metadata states.

[0031] Therefore, this application discloses a method for recovering metadata from abnormal states, applied to a preset BeeGFS file system. The method includes: running a preset state check script on a client server to check the original data state of the metadata in the metadata group of the preset BeeGFS file system and the corresponding mirror metadata state; if both the original data state and the mirror metadata state are abnormal, setting the original data state of the metadata to a normal state; and triggering a data synchronization operation on the mirror metadata to complete the recovery from the abnormal metadata state. Thus, by executing the preset state check script on the client to check the metadata state and the mirror metadata state, if an abnormal state is detected in the metadata Buddy Group, the original data state of the metadata can be forcibly changed to a Good state to trigger data synchronization of the mirror metadata and start the client service, mounting the BeeGFS file system, thus preventing the client from being unable to access the BeeGFS file system due to the inability to synchronize metadata properly. Attached Figure Description

[0032] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0033] Figure 1 This is a flowchart of a metadata abnormality recovery method disclosed in this application;

[0034] Figure 2 This application discloses a flowchart for resolving the Buddy Group state exception in the BeeGFS file system metadata.

[0035] Figure 3 This application discloses a flowchart of a specific metadata anomaly recovery method.

[0036] Figure 4 This is a schematic diagram of the structure of a metadata abnormality recovery device disclosed in this application;

[0037] Figure 5 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0038] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0039] In the era of big data and artificial intelligence, the storage needs of supercomputing centers or data centers have expanded from petabyte-level to exabyte-level. Many big data and intelligent applications need to run on HPC (High Performance Computing) systems. BeeGFS, as a leading parallel cluster file system in the HPC industry, can provide high-performance, highly scalable, and highly flexible file storage, while high availability of the cluster is also crucial. The BeeGFS file system achieves high availability of cluster data and metadata through Buddy Mirroring. Addressing the issue that abnormal power outages and restarts of metadata nodes may lead to abnormal states of two storage targets in a Buddy Group, preventing data synchronization, existing technologies require deploying the BeeGFS file system Meta service on two storage servers, configuring the Meta service BuddyGroup on the client, and enabling metadata mirroring to achieve high availability. When both metadata servers experience abnormal power outages and restarts simultaneously, the consistency state of both storage targets in the metadata Buddy Group will become Needs-resync, resulting in the inability to synchronize metadata. Furthermore, if the consistency state of both storage targets in the metadata Buddy Group is Needs-resync and data synchronization fails, the client service on the client will fail to mount the BeeGFS file system due to startup failure.

[0040] To address this, this application discloses a metadata anomaly recovery scheme that enables clients to successfully boot and mount the BeeGFS file system and achieve data synchronization even when the Buddy Group state is abnormal after a power outage and restart of the BeeGFS file system metadata node.

[0041] Reference Figure 1 As shown, this embodiment of the invention discloses a method for recovering metadata from abnormal states, applied to a preset BeeGFS file system, including:

[0042] Step S11: Run a preset status check script on the client server to check the original data status of the metadata in the metadata group of the preset BeeGFS file system and the corresponding image metadata status.

[0043] In this embodiment, a preset status check script is run on the client server to check the original data status and corresponding mirror metadata status of the Buddy Groups within the preset BeeGFS file system. The check result may be that the original data status of the metadata in the group is normal, and the mirror metadata status of the mirror metadata is normal; or the original data status of the metadata in the group is normal, and the mirror metadata status of the mirror metadata is abnormal; the original data status of the metadata in the group is abnormal, and the mirror metadata status of the mirror metadata is normal; or the original data status of the metadata in the group is abnormal, and the mirror metadata status of the mirror metadata is abnormal. Subsequent processing is performed for the above possible status results. It is understood that if two storage servers simultaneously experience an abnormal power outage and restart, the consistency status of the two storage targets in the metadata Buddy Group will both become Needs-resync, meaning that the two target data are considered out of sync and are attempting to resynchronize. Since no storage target is in the Good state, the metadata cannot be synchronized normally. Therefore, it is necessary to check the status of the storage targets. Because BeeGFS combines multiple storage servers to provide a highly scalable shared network file system with striped file content. In this way, it allows users to overcome the strict performance limitations of a single server, a single network interconnect, and a limited number of hard drives. Such a system can easily meet the high throughput demands of a large number of clients, while even a single client can benefit from the aggregated performance of this storage system. This is achieved through the separation of metadata and file content. The storage server is responsible for storing stripes of the actual content of user files, while the metadata server is responsible for coordinating file placement and striping between storage servers and informing clients of detailed information about certain file contents when necessary. When accessing file content, BeeGFS clients directly contact the storage server to perform file I / O and communicate with multiple servers simultaneously, enabling applications to truly achieve parallel access to file data. To minimize metadata access latency, BeeGFS also allows you to distribute metadata across multiple servers so that each metadata server can store a portion of the entire file system's namespace; therefore, the normal data state within the metadata is crucial.

[0044] In this embodiment, before running a preset status check script on the client server to check the original data status and corresponding mirrored metadata status of the metadata in the preset BeeGFS file system's metadata group, the method further includes: starting the client service and configuring the metadata group of the metadata service on the client server; enabling the metadata mirroring service so as to use the metadata mirroring service to perform mirroring operations on the metadata to obtain mirrored metadata. It is understood that before performing the status check, it is necessary to configure the Buddy Group of the Meta service on the client server and enable the mirroring function. For example, the metadata service and mirroring service can be configured and enabled using the following service configuration commands.

[0045] beegfs-ctl--addmirrorgroup--nodetype=metadata--groupid=1--primary=1--secondary=2;

[0046] beegfs-ctl–mirrormd;

[0047] Here, primary represents the original target metadata, and secondary represents the mirror target metadata.

[0048] In this embodiment, before starting the client service and configuring the metadata group of the metadata service in the client server, the method further includes: installing the auxiliary services of the preset BeeGFS file system and starting the client service in the client server. It can be understood that the BeeGFS file system helperd and client services are installed on the client server using the yum command, wherein the preset system service and startup service code are as follows: yum install beegfs-client beegfs-helperd beegfs-utils;

[0049] It's important to note that before installing and starting the corresponding services on the client server, you need to use the `yum` command to install the BeeGFS file system mgmtd (management service), meta (metadata) service, and storage (storage) service on both server storage servers. The installation code is shown below: `yum -y install beegfs-mgmtd beegfs-meta beegfs-storage`. Configure the storage service. Like the metadata service process, the BeeGFS data storage service process needs to know not only the path where the data is stored, but also the running IP address of the management service process. Typically, multiple storage service processes can be distributed across different nodes and / or assigned to different device targets under a single storage service process, such as multiple logical volumes. Additionally, each storage service process can be assigned a unique identifier ID. If the process has multiple device targets, a unique identifier ID can be assigned to each device target. The principle is: process ID + device target ID. For example, if a Storage Service ID is 1, and it has two configured targets, the ID of the first target can be set to "101", and the ID of the second target can be set to "102".

[0050] Step S12: If both the original data status and the image metadata status are in an abnormal state, then set the original data status of the metadata to a normal state.

[0051] In this embodiment, when the preset status check script detects that both the original data status and the image metadata status are in an abnormal state, for example, the abnormal status of Buddy Group after a power outage and restart is as follows:

[0052]

[0053] Then, the original data state of the metadata, that is, the state of the primary target, is forcibly changed from Needs-resync to the normal state, that is, the Good state.

[0054] Step S13: Trigger the data synchronization operation on the image metadata to complete the recovery of the abnormal metadata state.

[0055] In this embodiment, when the metadata status is normal, a data synchronization operation is triggered on the mirror metadata, that is, the data in the metadata is synchronized to facilitate the mounting of the BeeGFS file system on the client server, thereby restarting the client and completing the recovery from the abnormal metadata status. (Refer to...) Figure 2 As shown, Figure 2This document describes a solution to an abnormal BeeGFS file system metadata Buddy Group state. The steps include: installing the BeeGFS file system mgmt, meta, and storage services on the server; installing the BeeGFS file system helperd and client services on the client; configuring Buddy Group and enabling mirror functionality on the client; executing a metadata state check script on the client; and finally, restarting the client service. This solution demonstrates how to synchronize data when the metadata is in an abnormal state and successfully mounts the BeeGFS file system to enable client restart. Specifically, by executing the metadata Buddy Group state check script on the client, when both metadata storage targets are found to be in Needs-resync consistency state, the beegfs-ctl --setstate command is executed to force the original primary target's state to be set to Good. This allows the secondary target to synchronize data normally, preventing the client from being unable to access the BeeGFS file system due to metadata synchronization failure.

[0056] Therefore, this application discloses a method for recovering metadata from abnormal states, applied to a preset BeeGFS file system. The method includes: running a preset state check script on a client server to check the original data state of the metadata in the metadata group of the preset BeeGFS file system and the corresponding mirror metadata state; if both the original data state and the mirror metadata state are abnormal, setting the original data state of the metadata to a normal state; and triggering a data synchronization operation on the mirror metadata to complete the recovery from the abnormal metadata state. Thus, by executing the preset state check script on the client to check the metadata state and the mirror metadata state, if an abnormal state is detected in the metadata Buddy Group, the original data state of the metadata can be forcibly changed to a Good state to trigger data synchronization of the mirror metadata and start the client service, mounting the BeeGFS file system, thus preventing the client from being unable to access the BeeGFS file system due to the inability to synchronize metadata properly.

[0057] Reference Figure 3 As shown, this embodiment of the invention discloses a specific method for recovering from abnormal metadata states. Compared to the previous embodiment, this embodiment further explains and optimizes the technical solution. Specifically:

[0058] Step S21: Execute the state detection instruction to check the original data state and the corresponding mirror metadata state of the metadata in the metadata group of the preset BeeGFS file system.

[0059] For a more detailed description of the processing steps in step S21, please refer to the aforementioned disclosed embodiments; they will not be repeated here.

[0060] Step S22: Obtain the status check result and judge the status check result; determine that the original data status and the metadata status are both abnormal and / or both normal.

[0061] In this embodiment, the status check results are judged accordingly. It can be understood that if the check results are consistent, the status of one of the targets with consistent check results is judged to determine whether it is a normal state or an abnormal state. It should be noted that if it is a normal state, the data synchronization operation can be performed directly by relying on the data information in the metadata of the normal state.

[0062] Step S23: If both the original data state and the mirror metadata state are in an abnormal state, then set the original data state of the metadata to a normal state.

[0063] In this embodiment, if both the original data state and the mirror metadata state are in an abnormal state, it means that neither of them is a target metadata that can be used normally for synchronization. Therefore, the original data state of the metadata is forcibly set to a normal state, i.e., a "Good" state. A metadata state check script is executed on the client server, for example: `sh meta_check.sh`. The check logic of the `sh` script is as follows: First, the command `beegfs-ctl --listtargets --nodetype=meta --state --mirrorgroups` is executed to check the metadata Buddy Group state. If the consistency state of both targets is found to be Needs-resync, then the command `beegfs-ctl --setstate --nodetype=meta --nodeid=1 --state=good --force` is executed to force the original primary target to change from the Needs-resync state to the "Good" state.

[0064] Step S24: Perform data synchronization operation on the image metadata according to the target data in the metadata set to normal state, and end the execution of the preset state check script to complete the recovery of the abnormal state of the metadata.

[0065] In this embodiment, after the secondary target completes data synchronization and becomes "Good," the BuddyGroup group status information is printed, and the script execution ends. Following the data synchronization operation on the image metadata, the process also includes remounting the preset BeeGFS file system to the client service. Restarting the client service on the client server will remount the BeeGFS file system, for example, using the following command: `systemctl restart beegfs-client`.

[0066] Therefore, this embodiment effectively solves the problem of data synchronization failure caused by abnormal Buddy Group status in the BeeGFS file system metadata due to abnormal power outage and restart by forcibly changing the status of the original metadata to a normal state.

[0067] Reference Figure 4 As shown, this embodiment of the invention discloses a metadata abnormal state recovery device, applied to a preset BeeGFS file system, comprising:

[0068] The status check module 11 is used to run a preset status check script through the client server to check the original data status of the metadata in the metadata group of the preset BeeGFS file system and the corresponding image metadata status.

[0069] The status setting module 12 is used to set the original data status of the metadata to a normal status if both the original data status and the image metadata status are found to be in an abnormal state.

[0070] The data synchronization module 13 is used to trigger the data synchronization operation on the image metadata and complete the recovery of the metadata abnormal state.

[0071] The status check module 11 is used to run a preset status check script on the client server to check the original data status and corresponding mirror metadata status of the Buddy Group in the preset BeeGFS file system. The check result may be that the original data status of the metadata in the group is normal and the mirror metadata status is normal; or the original data status of the metadata in the group is normal and the mirror metadata status is abnormal; or the original data status of the metadata in the group is abnormal and the mirror metadata status is normal; or the original data status of the metadata in the group is abnormal and the mirror metadata status is abnormal. Subsequent processing is performed for the above possible status results. It is understandable that if two storage servers simultaneously experience an abnormal power outage and restart, the consistency status of the two storage targets in the metadata Buddy Group will both become Needs-resync, meaning that the two target data are considered out of sync and are attempting to resynchronize. Since no storage target is in a Good state, the metadata cannot be synchronized normally. Therefore, a status check of the storage targets is necessary. Before the step of running a preset status check script on the client server to check the original data status and corresponding mirrored metadata status of the metadata in the preset BeeGFS file system's metadata group, the process further includes: starting the client service and configuring the metadata group of the metadata service on the client server; and enabling the metadata mirroring service to perform mirroring operations on the metadata to obtain mirrored metadata. It is understood that before performing the status check, the Buddy Group of the Meta service needs to be configured on the client server, and the mirroring function needs to be enabled. For example, the metadata service and mirroring service can be configured and enabled using the following service configuration commands.

[0072] beegfs-ctl--addmirrorgroup--nodetype=metadata--groupid=1--primary=1--secondary=2;

[0073] beegfs-ctl–mirrormd;

[0074] Here, "primary" represents the original target metadata, and "secondary" represents the mirror target metadata. Before starting the client service and configuring the metadata group for the metadata service on the client server, the process also includes: installing the default BeeGFS file system auxiliary services and starting the client service on the client server. This can be understood as using the `yum` command to install the BeeGFS file system helperd and client services on the client server. The default system service and startup service code is as follows: `yum install beegfs-client beegfs-helperd beegfs-utils`. It's important to note that before installing and starting the corresponding services on the client server, the BeeGFS file system mgmtd (management service), meta (metadata) service, and storage (storage) service need to be installed on both server-side storage servers using the `yum` command. The installation code is as follows: `yum -y install beegfs-mgmtd beegfs-meta beegfs-storage`. Configuring the storage service involves, like the metadata service process, the BeeGFS data storage service process, in addition to knowing the path where the data is stored, also needs to know the running IP address of the management service process. Typically, multiple storage service processes can be distributed across different nodes and / or assigned to different device targets under a single storage service process, such as multiple logical volumes. Additionally, each storage service process can be assigned a unique identifier ID. If a process has multiple device targets, a unique identifier ID can be assigned to each device target. The principle for setting this is: process ID + device target ID. For example, if a Storage Service has an ID of 1, and it is configured with two targets, then the ID of the first target can be set to "101", and the identifier ID of the second target can be set to "102".

[0075] The status setting module 12 is used to make corresponding judgments on the status check results. It can be understood that if the check results are consistent, the status of one of the targets with consistent check results is then judged to determine whether it is a normal state or an abnormal state. It should be noted that if it is a normal state, data synchronization can be performed directly based on the data information in the metadata of the normal state. If both the original data status and the mirror metadata status are abnormal, it means that neither of them is a target metadata that can be used normally for synchronization. In this case, the original data status of the metadata is forcibly set to a normal state, i.e., a "Good" state, and the metadata status check script is executed on the client server. For example, the check script is as follows: sh meta_check.sh. The sh script's checking logic is as follows: First, it executes the command `beegfs-ctl --listtargets --nodetype=meta --state --mirrorgroups` to check the Buddy Group metadata status. If it finds that both targets have a consistency status of Needs-resync, it executes the command `beegfs-ctl --setstate --nodetype=meta --nodeid=1 --state=good --force` to force the original primary target to change from Needs-resync to Good. When the preset status check script detects that both the original data status and the mirror metadata status are abnormal, for example, after a power outage and restart, the abnormal status of the Buddy Group is as follows:

[0076] Then, the original data state of the metadata, that is, the state of the primary target, is forcibly changed from Needs-resync to the normal state, that is, the Good state.

[0077] The data synchronization module 13 is used to trigger a data synchronization operation on the mirror metadata when the metadata status is normal. This involves synchronizing the data within the metadata to facilitate mounting the BeeGFS file system on the client server, thereby restarting the client and recovering from the abnormal metadata status. (Refer to...) Figure 2 As shown, Figure 2This document describes a solution to an abnormal BeeGFS file system metadata Buddy Group state. The steps include: installing the BeeGFS file system mgmt, meta, and storage services on the server; installing the BeeGFS file system helperd and client services on the client; configuring the Buddy Group and enabling mirror functionality on the client; executing a metadata state check script on the client; and finally, restarting the client service. This implements a method for data synchronization when metadata is in an abnormal state and successfully mounts the BeeGFS file system to enable client restart. Specifically, by executing the metadata Buddy Group state check script on the client, when both metadata storage targets are found to be in the Needs-resync consistency state, the `beegfs-ctl --setstate` command is executed to force the original primary target's state to be set to Good. This allows the secondary target to synchronize data normally, preventing the client from being unable to access the BeeGFS file system due to metadata synchronization failure. After the secondary target completes data synchronization and also becomes Good, the Buddy Group status information is printed, and the script execution ends. The process also includes remounting the default BeeGFS file system to the client service after triggering the data synchronization operation on the mirror metadata. Restarting the client service on the client server will remount the BeeGFS file system. For example, you can mount the system using the following command: `systemctl restart beegfs-client`.

[0078] Therefore, this application discloses a method for recovering metadata from abnormal states, applied to a preset BeeGFS file system. The method includes: running a preset state check script on a client server to check the original data state of the metadata in the metadata group of the preset BeeGFS file system and the corresponding mirror metadata state; if both the original data state and the mirror metadata state are abnormal, setting the original data state of the metadata to a normal state; and triggering a data synchronization operation on the mirror metadata to complete the recovery from the abnormal metadata state. Thus, by executing the preset state check script on the client to check the metadata state and the mirror metadata state, if an abnormal state is detected in the metadata Buddy Group, the original data state of the metadata can be forcibly changed to a Good state to trigger data synchronization of the mirror metadata and start the client service, mounting the BeeGFS file system, thus preventing the client from being unable to access the BeeGFS file system due to the inability to synchronize metadata properly.

[0079] In some specific embodiments, the metadata abnormal state recovery device may specifically include:

[0080] The mirror unit is used to start the client service and configure the metadata group of the metadata service in the client server; and to enable the metadata mirroring service so as to use the metadata mirroring service to perform mirroring operations on the metadata to obtain mirrored metadata.

[0081] In some specific embodiments, the metadata abnormal state recovery device may specifically include:

[0082] The service installation unit is used to install auxiliary services for the preset BeeGFS file system on the client server and to start the client service.

[0083] In some specific embodiments, the status checking module 11 may specifically include:

[0084] The status checking unit is used to execute a status checking instruction to check the original data status and the corresponding image metadata status of the metadata in the metadata group of the preset BeeGFS file system.

[0085] In some specific embodiments, the metadata abnormal state recovery device may specifically include:

[0086] The result judgment unit is used to obtain the status check result and judge the status check result; and to judge that the original data status and the metadata status are both abnormal status and / or both normal status.

[0087] In some specific embodiments, the data synchronization module may specifically include:

[0088] The data synchronization unit is used to perform data synchronization operations on the mirror metadata based on the target data in the metadata set to the normal state, and then terminate the execution of the preset state check script.

[0089] In some specific embodiments, the metadata abnormal state recovery device may specifically include:

[0090] The system mount unit is used to remount the default BeeGFS file system to the client service.

[0091] Furthermore, embodiments of this application also disclose an electronic device, Figure 5 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.

[0092] Figure 5This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the metadata abnormal state recovery method disclosed in any of the foregoing embodiments. Furthermore, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0093] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0094] The processor 21 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 21 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor 21 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 21 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 21 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0095] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 221, computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0096] The operating system 221 manages and controls the various hardware devices and computer programs 222 on the electronic device 20 to enable the processor 21 to perform calculations and processing on the massive amounts of data 223 in the memory 22. The operating system 221 can be Windows Server, Netware, Unix, Linux, etc. The computer program 222, in addition to including a computer program capable of performing the metadata abnormal state recovery method executed by the electronic device 20 as disclosed in any of the foregoing embodiments, may further include computer programs capable of performing other specific tasks. The data 223 may include data received by the electronic device from external devices, as well as data collected by its own input / output interface 25.

[0097] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned metadata abnormal state recovery method. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0098] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0099] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in connection with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can implement the described functions using different methods for each specific application, but such implementation should not be considered beyond the scope of this application. The steps of the methods or algorithms described in connection with the embodiments disclosed herein can be implemented directly in hardware, software modules executed by a processor, or a combination of both. Software modules can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs, or any other form of storage medium known in the art.

[0100] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0101] The above provides a detailed description of the metadata anomaly recovery method, apparatus, device, and storage medium provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method for recovering from abnormal metadata states, characterized in that, Applicable to the default BeeGFS file system, including: The client server runs a preset status check script to check the original data status of the metadata in the metadata group of the preset BeeGFS file system and the status of the corresponding image metadata. If both the original data state and the mirror metadata state are in the Needs-resync state, then the original data state of the metadata is set to the normal state. Trigger a data synchronization operation on the image metadata to complete the recovery of the metadata from an abnormal state; After triggering the data synchronization operation on the mirror metadata, the following is also included: The default BeeGFS file system is remounted to the client service via the client server; The step of running a preset status check script on the client server to check the original data status of the metadata in the metadata group of the preset BeeGFS file system and the corresponding image metadata status includes: A preset status check script is run on the client server, and a status detection instruction is executed through the preset status check script to obtain the status check results corresponding to the metadata group in the preset BeeGFS file system; wherein, the status check results include image group identifier, member type, target identifier, reachability status, consistency status and node identifier. If both the original data state and the mirrored metadata state are in the Needs-resync state, then the original data state of the metadata is set to the normal state, including: Based on the status check results, determine whether the consistency status of the original metadata of the member type as the primary target and the mirror metadata of the member type as the secondary target under the same mirror group identifier are both in the Needs-resync state. If the consistency status of both the original metadata and the mirror metadata is Needs-resync, then a status setting instruction is executed based on the node identifier corresponding to the primary target to change the consistency status of the original metadata from Needs-resync to Good.

2. The metadata anomaly recovery method according to claim 1, characterized in that, Before the step of running a preset status check script on the client server to check the original data status of the metadata in the metadata group of the preset BeeGFS file system and the corresponding image metadata status, the method further includes: Start the client service and configure the metadata group for the metadata service in the client server; Enable the metadata mirroring service so that the metadata can be mirrored to obtain mirrored metadata.

3. The metadata anomaly recovery method according to claim 2, characterized in that, Before starting the client service and configuring the metadata group of the metadata service in the client server, the process also includes: Install the default BeeGFS file system auxiliary services and start the client service on the client server.

4. The metadata anomaly recovery method according to claim 1, characterized in that, The step of running a preset status check script on the client server to check the original data status of the metadata in the metadata group of the preset BeeGFS file system and the corresponding image metadata status includes: The execution of the state detection instruction, which checks whether the original data state is equal to the image metadata state, performs a state check on the original data state and the corresponding image metadata state of the metadata group in the preset BeeGFS file system.

5. The metadata anomaly recovery method according to claim 4, characterized in that, After the execution of the state detection instruction that detects that the original data state is equal to the image metadata state performs a state check on the original data state of the metadata in the metadata group of the preset BeeGFS file system and the corresponding image metadata state, it also includes: Obtain the status check results and make a judgment on the status check results; It is determined that both the original data status and the metadata status are in an abnormal state and / or both are in a normal state.

6. The metadata anomaly recovery method according to claim 1, characterized in that, The data synchronization operation triggered on the image metadata includes: Perform data synchronization operations on the mirror metadata based on the target data in the metadata set to normal status, and then terminate the execution of the preset status check script.

7. A metadata anomaly recovery device, characterized in that, Applicable to the default BeeGFS file system, including: The status check module is used to run a preset status check script on the client server to check the original data status of the metadata in the metadata group of the preset BeeGFS file system and the corresponding image metadata status. The status setting module is used to set the original data status of the metadata to a normal status if both the original data status and the mirror metadata status are in the Needs-resync state. The data synchronization module is used to trigger data synchronization operations on the image metadata and complete the recovery of abnormal metadata states. The metadata abnormal state recovery device is also used to remount the preset BeeGFS file system to the client service through the client server; The status check module is specifically used to run a preset status check script through the client server and execute status detection instructions through the preset status check script to obtain the status check results corresponding to the metadata group in the preset BeeGFS file system; wherein, the status check results include image group identifier, member type, target identifier, reachability status, consistency status and node identifier. The status setting module is specifically used to determine, based on the status check result, whether the consistency status of the original metadata of the member type being the primary target and the mirror metadata of the member type being the secondary target under the same mirror group identifier are both in the Needs-resync state; if the consistency status of the original metadata and the mirror metadata are both in the Needs-resync state, then a status setting instruction is executed based on the node identifier corresponding to the primary target to set the consistency status of the original metadata from the Needs-resync state to the Good state.

8. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the metadata abnormal state recovery method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, Used to store computer programs; wherein, when the computer programs are executed by a processor, they implement the steps of the metadata abnormal state recovery method as described in any one of claims 1 to 6.

Images