Metadata corruption recovery method and computing device

Abstract

This application relates to the field of computer technology, providing a method and computing device for recovering corrupted metadata. The method includes: detecting the activity status of a container runtime; when the activity status is inactive, creating a temporary test file in the working directory of the container runtime; if the temporary test file is successfully created, reading the runtime log of the container runtime; if the runtime log contains any preset keyword, determining that the metadata of the container runtime is corrupted, and updating the corruption detection count of the container runtime; when the corruption detection count is greater than or equal to a detection threshold, restoring the metadata file of the container runtime. Based on this solution, a host device equipped with a container orchestration platform can periodically detect and identify whether a fault involves the metadata file of the container runtime, achieving accurate identification and controllable repair of corrupted metadata, and improving the response speed for handling corrupted metadata files.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method and computing device for recovering corrupted metadata. Background Technology

[0002] With the widespread application of containerized build technology, the container runtime, as a core component of the container orchestration platform, is responsible for key functions such as container lifecycle management, image pulling, container startup, and resource isolation. The container runtime persistently stores key state information such as the containers, images, and snapshots it manages in an embedded metadata database. When the container runtime starts, it loads and parses the information in this database to restore the running state of the container orchestration platform.

[0003] During the operation of a container orchestration platform, server nodes may experience abnormal power outages due to power failures, hardware malfunctions, or system crashes. In such abnormal shutdown scenarios, the metadata database undergoing write operations may become inconsistent or corrupted due to the unexpected interruption of operations. After the server node restarts, the container runtime will fail to start because it cannot correctly parse the database content, resulting in service interruption.

[0004] A typical method for recovering corrupted metadata from container runtimes involves manually scanning and attempting to repair the metadata database using scanning tools. However, manual detection of corrupted metadata suffers from drawbacks such as slow response times, high operational complexity, and susceptibility to human error. This makes it difficult to meet the stringent requirements of high availability and data consistency in container runtimes, and reduces the overall management and delivery efficiency and business continuity assurance capabilities of container orchestration platforms. Summary of the Invention

[0005] This application provides a method and computing device for recovering corrupted metadata, which can perform real-time detection of metadata files during container runtime, identify metadata corruption occurring during container runtime using the detection process, and trigger a recovery process, thereby improving the response speed for handling corrupted metadata files.

[0006] To achieve the above objectives, the embodiments of this application adopt the following technical solutions: In a first aspect, embodiments of this application provide a method for recovering corrupted metadata, comprising: detecting the activity status of a container runtime; when the activity status is inactive, creating a temporary test file in the working directory of the container runtime; if the temporary test file is successfully created, reading the runtime log of the container runtime; if the runtime log contains any preset keyword in the container runtime, determining that the metadata of the container runtime is corrupted, and updating the corruption detection count of the container runtime; and when the corruption detection count is greater than or equal to the detection threshold stored in the container runtime, recovering the metadata file of the container runtime.

[0007] Based on this solution, the host device equipped with the container orchestration platform can periodically detect and identify whether the fault involves the metadata files of the container runtime, thereby achieving accurate identification and controllable repair of metadata corruption in the container runtime and improving the response speed for handling metadata file corruption.

[0008] In one possible implementation, detecting the activity status of the container runtime corresponding to the container orchestration platform includes: obtaining the runtime status parameters of the container runtime; determining the activity status of the container runtime based on the runtime status parameters; when the activity status of the container runtime is active, updating the damage detection count of the container runtime to zero and generating a first alarm message; the first alarm message is used to indicate that the container runtime is in an active state.

[0009] Based on this solution, the host device can detect the running status of the container and reset the damage detection count to zero when the container is running and active, avoiding interference from historical anomalies with the current detection and judgment, and ensuring the timeliness and accuracy of fault identification.

[0010] In another possible implementation, the runtime status parameters include an active status identifier, runtime result, exit status code, and restart count. Detecting the runtime activity of the container also includes: determining the runtime activity of the container to be inactive when the active status identifier is inactive, the restart count is greater than zero, and the exit status code or runtime result is abnormal; and determining the runtime activity of the container to be active when the exit status code and runtime result are normal, or when the active status identifier is active or the restart count is zero.

[0011] Based on this solution, the host device can use multi-dimensional state parameters to confirm the activity status of the container during runtime, avoiding the risk of misjudgment caused by judging based on a single parameter, improving the accuracy of state identification, and thus providing a reliable basis for triggering metadata fault recovery.

[0012] In another possible implementation, reading the container runtime logs includes: obtaining a preset number of container runtime logs; retrieving each keyword in the preset number of runtime logs; and updating the container runtime corruption detection count when any keyword is matched in the runtime logs.

[0013] Based on this solution, the host device can quickly locate anomalies using a small number of log lines, reducing transmission and computing resource overhead, and improving the efficiency and real-time performance of detecting corrupted metadata files.

[0014] In another possible implementation, after reading the runtime log of the container runtime, the method further includes: if the runtime log does not contain any preset keywords in the container runtime, updating the number of corruption detections in the container runtime to zero; generating a second alarm message; the second alarm message is used to indicate that there is no critical error information in the runtime log.

[0015] Based on this solution, the host device can avoid the problem of accidental triggering of recovery operations due to misjudgment of faults, so that the metadata recovery process can only be started when the metadata file is corrupted.

[0016] In another possible implementation, restoring the container runtime's metadata files includes: creating a recovery state file in the storage area; shutting down the container runtime to release the container runtime's metadata files; cleaning up the container runtime's metadata files and container network interface files; starting the container runtime to create new metadata files; and deleting the recovery state file.

[0017] Based on this solution, the host device can recover from corrupted metadata by shutting down the container runtime to release the metadata files, ensuring that the metadata files are in an unlocked state, and then cleaning up the corrupted metadata files. This allows the metadata files to be rebuilt based on the startup of the container runtime, reducing manual intervention and improving the fault recovery capability of the container orchestration platform.

[0018] In another possible implementation, before detecting the active state of the container runtime, the method further includes: detecting whether a recovery state file exists; if the recovery state file does not exist, updating the corruption detection count of the container runtime to zero; if the recovery state file exists, restoring the metadata file of the container runtime based on the recovery state file.

[0019] Based on this solution, the host device can skip the fault detection phase and immediately start the metadata file recovery process when the recovery status file exists, thus avoiding the need to repeatedly start the detection process when a secondary fault occurs during the recovery process, and significantly shortening the fault response time.

[0020] In another possible implementation, before cleaning up the container runtime's metadata files and container network interface files, the method further includes: obtaining the backup path parameters stored in the container runtime's configuration file; creating a file directory corresponding to the backup path parameters; and backing up the container runtime's metadata files to the file directory.

[0021] Based on this solution, the host device can back up the damaged metadata files to a specified path for subsequent fault analysis and backtracking, ensuring that changes to the metadata files are traceable and reversible.

[0022] In another possible implementation, before creating the file directory corresponding to the backup path parameter, the method further includes: detecting the backup path parameter; stopping the container runtime recovery process when the backup path parameter is invalid; and generating a third alarm message to indicate that the metadata file backup of the container runtime is abnormal.

[0023] Based on this solution, the host device can promptly suspend the recovery operation and provide alarm information when the backup path configuration is abnormal, avoiding data loss due to metadata file backup failure caused by path failure, thereby ensuring the reliability and security of the recovery process.

[0024] In another possible implementation, the container runtime is started to create a new metadata file, including: starting the main process of the container runtime; creating the metadata file corresponding to the container runtime; detecting the activity status of the container runtime; if the activity status is active, restoring the business functions of the container runtime; if the activity status is inactive, generating a fourth alarm message, which is used to indicate that the container runtime restart failed.

[0025] Based on this solution, the host device creates new metadata files by starting the container runtime, and determines whether to trigger alarms by detecting the activity status during the recovery of container runtime functions, thereby optimizing the business recovery process.

[0026] In another possible implementation, restoring the business functions of the container runtime includes: obtaining the recovery image path parameters stored in the container runtime's configuration file; loading each image located in the storage path corresponding to the recovery image path parameters; starting the minimum deployment unit of the container orchestration platform; and determining the recovery status of the container runtime's business functions based on the status of the minimum deployment unit.

[0027] Based on this solution, the host device can load the image file into the newly created metadata file during the process of restoring the business functions of the container runtime. This enables the container runtime to start quickly when providing containers for the smallest deployment unit, reducing business interruption time and improving the stability of the container orchestration platform.

[0028] Secondly, embodiments of this application also provide a metadata corruption recovery system, comprising: an activity status detection unit configured to detect the activity status of a container runtime corresponding to a container orchestration platform; a write test unit configured to create a temporary test file in the working directory of the container runtime when the activity status is inactive; a log analysis unit configured to read the runtime log of the container runtime when the temporary test file is successfully created; and, if the runtime log contains any preset keyword in the container runtime, to determine that the metadata of the container runtime is corrupted and to update the corruption detection count of the container runtime; and a metadata reconstruction unit configured to restore the metadata file of the container runtime when the corruption detection count is greater than or equal to the detection threshold stored in the container runtime.

[0029] Thirdly, embodiments of this application also provide a computing device, including: a processor and a memory; the processor and the memory are coupled; the memory is used to store program instructions; the processor is used to execute the program instructions to perform the method as described in any of the first aspects above.

[0030] Fourthly, embodiments of this application provide a chip for performing the methods described in any of the first aspects above.

[0031] Fifthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a computer, implement the method as described in any of the first aspects.

[0032] In a sixth aspect, embodiments of this application provide a program product including a computer program that, when executed by a processor, implements the method as described in any of the first aspects. Attached Figure Description

[0033] Figure 1 This is a schematic diagram of the architecture of a container orchestration platform; Figure 2 A schematic diagram of a container runtime architecture provided for an embodiment of this application; Figure 3 A flowchart illustrating a method for recovering corrupted metadata provided in this application embodiment; Figure 4 A flowchart illustrating a method for detecting the activity state of a container during runtime, provided as an embodiment of this application; Figure 5 This application provides a schematic diagram of a process for reading runtime logs. Figure 6 This application provides a schematic diagram of a process for restoring metadata files during container runtime, as illustrated in an embodiment of the present application. Figure 7A flowchart illustrating another method for recovering corrupted metadata provided in this application embodiment; Figure 8 A flowchart illustrating a process for backing up corrupted metadata files is provided in this application embodiment; Figure 9 This application provides a schematic diagram of the startup process of a container runtime. Figure 10 This application provides a schematic diagram of a process for restoring runtime business functions of a container. Figure 11 This is a schematic diagram of a metadata corruption recovery system provided in an embodiment of this application; Figure 12 This is a schematic diagram of a computing device provided in an embodiment of this application. Detailed Implementation

[0034] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. To facilitate a clear description of the technical solutions of the embodiments of this application, the use of terms such as "first," "second," etc., in the embodiments of this application is for illustrative purposes and to distinguish the objects being described. There is no particular order between them, nor does it indicate a specific limitation on the number of devices in the embodiments of this application, and they do not constitute any limitation on the embodiments of this application.

[0035] The following explanations of the technical terms mentioned in the embodiments of this application are provided to facilitate understanding by those skilled in the art.

[0036] A container orchestration platform is a large-scale distributed system that enables automated management, scheduling, and operation of containerized applications. Using a container orchestration platform, servers can complete tasks such as container deployment, scaling, network configuration, storage mounting, and fault recovery across multiple nodes and environments.

[0037] The container runtime is the core component in a container orchestration platform responsible for managing the container lifecycle. It performs operations such as creating, starting, pausing, resuming, stopping, and destroying containers. After being loaded into the container orchestration platform, the container runtime stores information such as container configurations and image configurations used during the creation and operation of containers built by the platform in the corresponding storage space by creating metadata files, providing metadata support for container operation.

[0038] The application scenarios of this application are described below.

[0039] Figure 1 This is a schematic diagram of the architecture of a container orchestration platform. The following is based on... Figure 1 The content shown herein provides an illustrative description of the application scenarios of the methods provided in the embodiments of this application.

[0040] Taking the container orchestration platform 100 as an example of a Kubernetes cluster, it includes a control plane node 110 and multiple worker nodes 120. The control plane node 110 is responsible for cluster state management and scheduling decisions. Each worker node 120 has multiple minimum deployment units 121, container runtimes 122, node agents 123 and network agents 124 to realize the deployment and operation of containers.

[0041] In this embodiment, the minimum deployment unit 121 can be a container group (Pod), and the container runtime 122 can be containerd. It can provide lifecycle management for containers and images for each worker node 120 and its minimum deployment unit 121 within the container orchestration platform 100. The container runtime 122, as the execution entity for instruction interaction between the control plane node 110 and the worker nodes 120, can call the operating system kernel interface of the host device to perform creation, startup, shutdown, deletion, and corresponding image pulling and management operations on the minimum deployment unit 121, thereby enabling the smooth operation of the container orchestration platform 100.

[0042] Interface proxy 123 is responsible for forwarding the instructions issued by control plane node 110 to container runtime 122 and returning the execution results to ensure the consistency between scheduling policy and actual running status; network proxy 124 works with container runtime 122 to complete key tasks such as IP address allocation and service discovery to provide network communication for the smallest deployment unit 121.

[0043] The control plane node 110 may include an interface service 111, a cloud controller manager 112, a scheduler 113, and a state database 114. The interface service 111 is the access point for the container orchestration platform 100, responsible for receiving and verifying requests from internal components or external systems. The cloud controller manager 112 is responsible for interacting with the underlying cloud platform to achieve cloud resource coordination such as node registration and load balancing configuration. The scheduler 113 schedules the smallest deployment unit 121 to suitable worker nodes 120 based on resource availability and policy constraints. The state database 114 persistently stores the global state of the container orchestration platform 100.

[0044] The container orchestration platform 100 can be deployed on the device corresponding to the hardware abstraction layer 101. The hardware abstraction layer 101 provides physical resources for the container orchestration platform 100, such as computing resources and storage resources. The operating system 102 is a software platform installed on the device corresponding to the hardware abstraction layer 101. It is responsible for managing hardware resources and providing a runtime environment for the container orchestration platform 100. The operating system 102, in collaboration with the hardware abstraction layer 101, provides system call support for the scheduling and execution of underlying container operations by the container runtime 122.

[0045] Figure 2 This is a schematic diagram of a container runtime architecture provided in an embodiment of this application. The following is based on... Figure 2 The content shown here is an exemplary description of the architecture of the container runtime 122 involved in the embodiments of this application.

[0046] like Figure 2 As shown, taking containerd as an example for container runtime 122, its architecture may include interface unit 201, measurement unit 202, event unit 203, task unit 204, metadata unit 205, storage unit 206, and runtime unit 207. Among them, interface unit 201 is used to receive and parse call requests from container orchestration platform 100, and can receive instructions such as creating containers and pulling images, and return the results, providing container runtime 122 with cross-language remote procedure call capabilities.

[0047] The measurement unit 202 is used to collect and aggregate resource usage metrics and health status of the container runtime 122, such as memory usage and latency. The metric data collected by the measurement unit 202 can reflect the internal state changes of the container runtime 122 in real time, which facilitates the container orchestration platform 100 to dynamically evaluate the health status of the container runtime 122 and identify abnormal trends.

[0048] Event unit 203 can be used to generate corresponding events when the internal state of container runtime 122 changes, such as when the image is pulled, the container is created, the task is started, or the snapshot is cleaned. Container orchestration platform 100 can read each event through interface unit 201 to realize real-time perception and response to key nodes in the container lifecycle and realize state synchronization of the corresponding working nodes of container runtime 122.

[0049] Task unit 204 is responsible for scheduling and executing various operations during the container's lifecycle. Task unit 204 can associate metadata unit 205 and runtime unit 207 to manage the container's running status.

[0050] Metadata unit 205 is used to persistently store key metadata of container runtime 122, including container configuration information and image configuration information. Task unit 204 can create corresponding tasks based on the container configuration information in metadata unit 205 to run the container.

[0051] Storage unit 206 is used to store file data of container runtime 122, including image layer data, container snapshots, and difference data between different snapshots. Based on the content stored in storage unit 206, container runtime 122 can efficiently reuse image layers and snapshots, significantly reducing storage redundancy and image pull time.

[0052] Runtime unit 207 is used to interface with the operating system kernel of the host device, where it creates isolated container processes and manages their lifecycles so that the container processes can run without interfering with each other.

[0053] It should be understood that the information stored in the metadata unit 205 is the metadata file of the container runtime 122. Correspondingly, the damage to the metadata file is the damage to the information stored in the metadata unit 205. The container configuration, image configuration and other information in the metadata file can be used by the task unit 204 as the basis for creating, starting or destroying the container.

[0054] During the operation of container runtime 122, its built metadata files are continuously read and written to maintain container state consistency. When the host device experiences an abnormal shutdown event such as an abnormal power outage, kernel crash, or forced shutdown, resulting in an interruption of operation, the metadata files are prone to problems such as incomplete writing, verification failures, or structural errors, affecting the normal functional recovery and business continuity of the container runtime. Furthermore, the impact of metadata file corruption may not be directly reflected in the immediate behavior of container runtime 122, but it will gradually cause task unit 204 to be unable to accurately parse configurations, misjudge container states, or even refuse to execute critical operations. In this case, the metrics collected by metric unit 202 cannot reflect the corruption of metadata files, affecting the efficiency of container orchestration platform 100 in identifying metadata file corruption, and thus leading to recovery failure or container startup blockage.

[0055] To address the aforementioned issues, this application provides a method for recovering corrupted metadata. By continuously monitoring the activity status of containers during runtime within a container orchestration platform, the method obtains information about the metadata files of the containers during runtime. This enables real-time detection of metadata file corruption, improving the container orchestration platform's ability to detect metadata corruption and its response timeliness.

[0056] The metadata corruption recovery method provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0057] Figure 3 This is a flowchart illustrating a metadata corruption recovery method provided in an embodiment of this application. The following is based on... Figure 3 The content shown illustrates the implementation steps of the metadata corruption recovery method provided in this application embodiment.

[0058] like Figure 3 As shown, the metadata corruption recovery method provided in this application embodiment may include the following steps S100 to S500.

[0059] S100: Detects the running status of containers corresponding to the container orchestration platform.

[0060] The container runtime is a component in a container orchestration platform used to manage the lifecycle of containers. The host device of the container orchestration platform can utilize the container runtime to invoke the operating system to run container processes, thereby achieving container deployment, operation, and lifecycle management. The activity status of the container runtime refers to the status of the services provided by the container runtime. Based on this activity status, it is possible to determine whether the container runtime is experiencing any faults. The host device of the container orchestration platform can determine the activity status of the container runtime by reading its runtime status parameters and other information.

[0061] In one example, the activity state of the container runtime can include either active or inactive. When the activity state of the container runtime is detected as active, the host device can determine that the container runtime is in a normal operating state; when the activity state of the container runtime is detected as inactive, the host device can determine that the container runtime is in an abnormal state, and the host device can perform subsequent steps to handle the abnormal state of the container runtime.

[0062] In this embodiment of the application, the storage area of ​​the container runtime may store configuration files. The host device can periodically initiate state detection logic based on the configuration files stored in the container runtime, or the container runtime can autonomously trigger state detection logic based on the configuration files stored in it to detect the read / write consistency and integrity of the metadata files.

[0063] For example, the configuration file may include a detection switch and a detection cycle. After the container starts or its configuration is updated, the host device can decide whether to enable the metadata corruption detection mechanism based on the state of the detection switch, and periodically check the activity status of the container during runtime according to the detection cycle. For example, the configuration file may have two fields: "containerd_check_enabled" and "containerd_check_cycle," which are used to control the start / stop and execution frequency of the detection function, respectively. The former takes a boolean value, i.e., true or false, and the latter is an integer time interval, which can be in seconds.

[0064] After reading the configuration file, the host device checks the "containerd_check_enabled" field to determine whether the metadata corruption detection mechanism is enabled. If the value of the "containerd_check_enabled" field is true, the host device can periodically send detection requests to the container runtime based on the time interval set by the "containerd_check_cycle" field to obtain the activity status information of the container runtime; if the value of the "containerd_check_enabled" field is false, the host device can skip the detection process.

[0065] In this embodiment, the values ​​of the "containerd_check_enabled" and "containerd_check_cycle" fields are information manually configured by the operation and maintenance personnel of the container orchestration platform through input commands or adding configuration files. The specific values ​​can be flexibly set by the operation and maintenance personnel according to actual business needs and system load. For example, in a high-load production environment, the operation and maintenance personnel can set "containerd_check_enabled" to true and "containerd_check_cycle" to 300 seconds (i.e., 5 minutes) to balance detection timeliness and resource consumption; while in low-frequency debugging scenarios, it can be set to false or extended to 3600 seconds to avoid redundant detection from interfering with system stability.

[0066] It should be understood that the host device of a container orchestration platform can be a server or a server cluster, which consists of one or more physical servers or virtualization instances. The host device has the operating system environment, storage resources and network connectivity required to run the container orchestration platform.

[0067] The detection period defined in the above embodiments is only an example. In actual applications, it can be dynamically adjusted according to hardware performance, container density and business criticality. For example, the detection period of some core systems can be compressed to 60 seconds to achieve fast response, while edge computing nodes can be relaxed to 7200 seconds to reduce bandwidth and computing power consumption. The specific value of the detection period is not mandatory in the embodiments of this application.

[0068] S200: When the activity status is inactive, create temporary test files in the working directory of the container runtime.

[0069] In step S200, after obtaining the active status of the container runtime, the host device can perform corresponding operations based on that status. When the active status of the container runtime is inactive, the host device can create a temporary test file in the working directory of the container runtime to provide basic checks for subsequent processes, thereby verifying whether the storage area corresponding to the container runtime can be written to.

[0070] The working directory for container runtime can be: Figure 2 The path corresponding to storage unit 206 described above is dynamically allocated by the host device and written into the container runtime's configuration information during container runtime initialization. For example, the working directory of the container runtime can be " / var / lib / containerd".

[0071] In one example, the host device can create a temporary test file named "test_write" by sending the command "touch / var / lib / containerd / test_write" to the container runtime to verify whether the storage area corresponding to the container runtime is writable.

[0072] The "touch" command is a commonly used tool in the operating system of the host device. In this embodiment, the command can first check whether a file named "test_write" exists in the storage area corresponding to " / var / lib / containerd". If it does not exist, the file is created based on the command and the execution status is returned. If it already exists, the access timestamp of the file can be updated based on the command and the execution status is returned. Then, based on the execution status returned by the command, the writability of the storage area can be determined.

[0073] If the instruction executes successfully and returns a status code of 0, the storage area is determined to be writable; if a non-zero status code is returned (such as insufficient permissions, disk full, or path unreachable), an error log is recorded and an alarm is triggered, indicating that the working directory of the current container runtime cannot be written.

[0074] Based on step S200, the host device can perform a preliminary investigation into the cause of the container runtime failure, avoiding the misjudgment of failures caused by other issues as corrupted metadata files during container runtime, and avoiding the misjudgment of problems such as insufficient storage space as metadata anomalies during the processing, thus triggering unnecessary repair processes.

[0075] S300: If the temporary test file is successfully created, read the runtime logs of the container.

[0076] In step S300, after the temporary test file is successfully created, the host device can determine that the storage area of ​​the container runtime is in a writable state. At this time, the host device further reads the runtime log of the container runtime to analyze the internal state of the container runtime through the log content and determine whether there is any corruption of the container runtime's metadata file.

[0077] In this embodiment, the host device can compare the contents of the operation log with preset keywords to determine whether there are error patterns related to metadata corruption in the log. For example, the host device can set corresponding keywords in the configuration file, such as defining a "log_error_keywords" field in the configuration file to store keywords associated with metadata file corruption.

[0078] In one example, the field value corresponding to the "log_error_keywords" field in the configuration file may include "invalid page type", "database corruption", "unexpected EOF", "bad magic number", etc. Among them, "invalid page type" is used to indicate an invalid page type, "database corruption" is used to indicate database corruption, "unexpected EOF" indicates that the log or metadata file was unexpectedly truncated, and "bad magic number" indicates that the file header verification failed.

[0079] The host device can use the "log_error_keywords" field in the configuration file to scan the runtime logs line by line to determine whether the logs contain any specific keywords. It should be noted that the "log_error_keywords" field in the configuration file can be modified to add or remove keywords, adapting to different log analysis scenarios and container runtime version iterations.

[0080] S400: If the runtime log contains any of the preset keywords in the container runtime, then the metadata of the container runtime is determined to be corrupted, and the corruption detection count of the container runtime is updated.

[0081] In step S400, the host device can match the above keywords line by line based on the read operation log to determine whether any keyword is contained therein; if any keyword is contained in the operation log, it can be determined that the metadata file is corrupted.

[0082] In this embodiment of the application, due to network fluctuations and other factors that may cause occasional keyword mismatches, the host device may update the number of corruption detections during container runtime and restart the detection process when it is determined that there is metadata corruption during container runtime, and execute steps S100 to S300 to verify whether the metadata corruption is a persistent anomaly.

[0083] The "damage detection count" refers to the number of times the host device detects metadata file corruption within the current detection cycle, while the detection cycle refers to the time period defined in the configuration file. This allows the host device to avoid occasional false alarms interfering with the container's metadata file repair decisions and prevents repair processes from being triggered by momentary anomalies such as network fluctuations.

[0084] S500: When the number of damage detections is greater than or equal to the detection threshold stored at runtime, restore the metadata file at runtime.

[0085] In step S500, the host device may trigger a metadata file recovery process to recover the metadata file of the container runtime when the number of damage detections is greater than or equal to the detection threshold stored during container runtime.

[0086] In this embodiment, the detection threshold can also be stored in a configuration file and can be dynamically updated via a container orchestration platform. For example, the configuration file can have a "containerd_check_times" field, whose corresponding numeric value is the detection threshold for the container runtime. The default value of this field can be 5, indicating that the process of restoring the container runtime's metadata file will only be triggered if the host device detects that the metadata file is corrupted five times consecutively.

[0087] If the host device receives a configuration file change instruction that includes an update to the "containerd_check_times" field, the corresponding value in the configuration file can be adjusted, and the criteria for determining the number of corruption detections can be dynamically adjusted accordingly. In this way, the host device can confirm whether metadata truly suffers from persistent corruption through multiple checks, thereby improving the accuracy of repair decisions, avoiding false repairs caused by occasional anomalies, and enhancing the stability and continuity of the container orchestration platform.

[0088] Through the above steps S100 to S500, the embodiments of this application enable the host device to periodically detect the metadata files of the container during runtime, realize accurate identification and controllable repair of metadata corruption, and reduce the risk of misjudgment while ensuring business continuity.

[0089] The steps in the above embodiments will be further described below with reference to the accompanying drawings.

[0090] Figure 4 This is a schematic flowchart illustrating a process for detecting the activity state of a container during runtime, as provided in an embodiment of this application. The following is based on... Figure 4 The content shown herein serves as an example to illustrate how the host device detects the activity status of a container during runtime in the embodiments of this application.

[0091] like Figure 4 As shown, in this embodiment of the application, the process by which the host device detects the activity status of the container during runtime may include the following steps S110 to S150.

[0092] S110: Obtain runtime status parameters of the container.

[0093] In step S110, the host device can determine the activity status of the container runtime by reading its runtime status parameters. In one example, taking containerd as the container runtime, the host device can obtain detailed status information of the containerd service by executing the command "systemctl show containerd".

[0094] In this embodiment of the application, the instructions executed by the host device can be used to accurately extract key status fields, such as "ActiveState", "Result", "ExecMainStatus", "NRestarts", etc., by adding the parameter "-p" to the "systemctl showcontainerd" command, so as to quickly determine whether containerd is currently in an active running state.

[0095] The “ActiveState” field indicates the active state. A value of “active” indicates that the containerd service is active, while a value of “inactive” or other values ​​indicates that the containerd service is inactive. The “Result” field indicates the result. A value of “success” indicates that the containerd service operation was successfully executed, while a value of “failed” indicates that the containerd service has a record of operation failure.

[0096] The “ExecMainStatus” field is the exit status code. A value of 0 indicates that the process corresponding to the containerd service exited normally, while a non-zero value indicates that the process terminated abnormally. The “NRestarts” field is the number of restarts, which is used to record the number of times containerd has been restarted. If this value is greater than zero, it indicates that the containerd service has encountered an abnormality and restarted automatically, indicating that there was an unexpected failure during container runtime.

[0097] S120: Determine the active state of the container during runtime based on runtime status parameters.

[0098] In step S120, after the host device collects the running status parameters, it can analyze each field in the running status parameters through preset rules, so as to use the combined logic of multiple fields to determine the actual activity status of the container during operation, and avoid misjudgment caused by normal shutdown or maintenance restart of the host device.

[0099] When the runtime status parameters include active status identifier, runtime result, exit status code, and restart count, the host device can determine the active status of the container runtime by checking whether the runtime status parameters meet preset conditions.

[0100] For example, the preset conditions can be set as follows: the active state is marked as inactive, the number of restarts is greater than zero, and the exit status code or running result is abnormal. When the running state parameters meet these preset conditions, the host device determines that the container's running activity state is inactive. Conversely, if the running state parameters do not meet any of the preset conditions, the host device can determine that the container's running activity state is active.

[0101] S130: When the active state is identified as inactive, the number of restarts is greater than zero, and the exit status code or the running result is abnormal, the active state of the container runtime is determined to be inactive.

[0102] In step S130, the host device can determine the active state of the container runtime after comparing the running status parameters with preset conditions. In this embodiment, since the active state of the container runtime is the key basis for determining the state of the metadata file, the host device can use preset conditions to identify scenarios where the container runtime is inactive when determining the active state of the container runtime, and then accurately determine the state of the metadata file based on other parameters, such as writability and keyword matching.

[0103] In one example, the preset condition that can be stored in the host device could be "ActiveState != active && NRestarts>0 && (ExecMainStatus != "0" || Result != "success")", which means that when the active state is marked as inactive, the number of restarts is greater than zero, the exit status code is not 0, or the running result is abnormal, the container runtime is determined to be in an inactive state. If the runtime status parameters detected by the host device meet this preset condition, it will be determined that the container runtime is in an inactive state.

[0104] Once the host device determines that the container's running state is inactive, it can trigger step S200 in the above embodiment to further determine whether the reason for the container's running state being inactive is due to corrupted metadata files, thus avoiding misjudgments caused by other factors such as configuration errors or insufficient resources.

[0105] S140: If the exit status code and the running result are normal, or the active status identifier is active or the number of restarts is zero, determine that the active status of the container is active during runtime.

[0106] In step S140, the host device can determine that the container runtime is in an active state when the running status parameters do not meet the preset conditions. At this time, the container runtime continues to provide services, and the host device does not need to perform subsequent detection processes. It can maintain the existing service state and perform routine monitoring and resource scheduling on the container runtime according to the parameters in the configuration file to ensure service stability and response efficiency.

[0107] In one example, because the preset conditions stipulate that the container's running activity is determined to be inactive only when all three conditions are met simultaneously: the active status is marked as inactive, the number of restarts is greater than zero, and the exit status code is not zero or the running result is abnormal, the host device can determine that the container's running activity is active as long as any one of the conditions is not met, such as the exit status code being 0 and the running result being normal, or the active status being marked as active, or the number of restarts being 0.

[0108] Once the host device determines that the container is active during runtime, it can execute the following step S150 to end the detection process and generate the corresponding prompt information.

[0109] S150: When the container is in an active state, update the number of damage detections during container runtime to zero and generate the first alarm message.

[0110] In step S150, the host device can determine whether to terminate the subsequent detection process by judging whether the container's runtime activity state is active. If the container's runtime activity state is active, the damage detection count is updated to zero to avoid the accumulation of sporadic anomalies that could lead to false triggering of the recovery process. Before ending the detection process, the host device can generate a first alarm message to indicate that the container is in an active state, and then terminate the current detection process.

[0111] In this embodiment, the first alarm information may store a detection timestamp and a current container runtime status identifier to identify the detection result, facilitating maintenance personnel to trace and analyze the container's runtime health status. The host device may store the generated first alarm information in the host device's local log to ensure the integrity and traceability of the alarm information.

[0112] Through the above steps S110 to S150, the host device can identify the running state of the container, and determine the necessity of detecting metadata files by judging its activity state, thereby reducing the system overhead caused by detection and improving resource utilization efficiency.

[0113] Figure 5 This is a schematic diagram illustrating a process for reading runtime logs, provided as an embodiment of this application. The following is based on... Figure 5The content shown herein serves as an illustrative example of the process by which the host device reads the runtime logs of a container in an embodiment of this application.

[0114] like Figure 5 As shown, in this embodiment of the application, the process of the host device reading the operation log may include the following steps S310 to S350.

[0115] S310: Get the runtime log of the container at a preset number of rows.

[0116] In step S310, the host device can obtain the runtime logs of the container through preset instructions to determine whether there is a problem with corrupted metadata files during container runtime. Because the runtime logs contain log information during container runtime and the number of logs is large, the host device can set a preset number of lines, such as obtaining the most recent N lines of log content, to focus on newly generated logs and improve detection efficiency and accuracy.

[0117] Taking containerd as an example of a container runtime, the host device can use the command "journalctl -ucontainerd -n 50 --no-pager" to obtain the most recent 50 lines of containerd service logs, enabling the host device to obtain the most recent log content and provide a data foundation for subsequent keyword matching.

[0118] In the command "journalctl -u containerd -n 50 --no-pager", "journalctl" indicates the command type, namely querying and managing system logs; "-u containerd" specifies that the log query operation is directed to the containerd service unit; "-n 50" limits the query to only the most recent 50 lines of logs; and "--no-pager" disables pagination to ensure that the output is a continuous text stream, which facilitates the use of keyword matching tools in subsequent steps to efficiently locate abnormal areas in the continuous text stream.

[0119] In another embodiment of this application, the host device can also combine log timestamps and detection timestamps for time window filtering, analyzing only the log increment between two detection time nodes, further narrowing the analysis scope. The detection time node refers to the time node at which the host device triggers the detection container's runtime based on the detection period specified in the configuration file. For example, if the configuration file sets the detection period to 10 minutes, the host device can use the log increment between the current detection timestamp and the previous detection timestamp as the analysis object during the detection process, thereby accurately capturing key clues during the period when metadata anomalies occur and avoiding redundant logs interfering with the judgment.

[0120] It should be noted that the instruction forms and parameter values ​​shown in the embodiments of this application are only examples. The instructions actually executed by the host device can be dynamically adapted according to the operating system type, log storage configuration and container runtime version of the host device. The preset number of lines N can also be dynamically adjusted according to the fault detection sensitivity requirements. For example, it can be adjusted to 30 lines in high-load scenarios to speed up the response, and expanded to 100 lines in production environments with strict stability requirements to enhance the anomaly capture coverage.

[0121] S320: Retrieve each keyword from the preset number of lines in the runtime log.

[0122] In step S320, after obtaining a preset number of operation logs, the host device can search for preset keywords in the operation logs to identify whether there are metadata file corruption anomalies during container runtime. In this embodiment, the preset keywords can be the field value corresponding to the "log_error_keywords" field defined in the container runtime configuration file. When the host device searches for keywords in the operation logs, it can generate corresponding search instructions using the keywords in the configuration file.

[0123] For example, the host device can generate the command "grep -i -E "invalid|corrupt|magic|eof|page type"" based on keywords in the configuration file. Here, "-i" is used to enable case-insensitive matching to avoid missing key error signals due to differences in capitalization; "-E" is used to enable the host device's extended regular expression engine, which enables the use of "|" (or operation) to achieve "or" matching of multiple keywords during the search process, ensuring that any keyword match is considered an anomaly.

[0124] The "|" symbol between the keywords represents a logical "OR", which means that when the host device searches for keywords in the operation log, it will trigger an anomaly detection if any keyword is matched, thereby improving the fault identification coverage and response speed.

[0125] In this embodiment, the number of keywords in the search instructions generated by the host device is consistent with the number of keywords defined in the "log_error_keywords" field in the configuration file, so that the search logic and configuration are kept synchronized, which facilitates unified maintenance and dynamic adjustment by operation and maintenance personnel. When a new exception type is added, it only needs to be updated in the configuration file to take effect in real time without restarting the service or modifying the code.

[0126] S330: When any keyword is matched in the runtime log, update the number of corruption detections during container runtime.

[0127] In step S330, if the host device finds any keyword in the runtime log during the keyword retrieval process, it determines that there is a metadata corruption anomaly during container runtime. The host device can then execute the aforementioned step S400 to update the corruption detection count during container runtime.

[0128] S340: If the runtime log does not contain any keywords preset during container runtime, update the container runtime corruption detection count to zero.

[0129] In step S340, if no keyword is matched during the process of the host device searching for keywords in the running log, it can be determined that the inactive state of the container during runtime is not caused by metadata corruption. At this time, the host device can reset the number of corruption detections during container runtime to 0 to avoid misjudgment caused by the continuous accumulation of occasional anomalies and improve the accuracy of fault statistics.

[0130] After the host device resets the number of damage detections to 0, it can execute step S350 to generate corresponding prompt information, which can help to prompt the operation and maintenance personnel that the container is inactive and that the abnormality is not metadata corruption.

[0131] S350: Generate a second alarm message.

[0132] In step S350, the host device can generate a second alarm message. This second alarm message indicates that there are no critical error messages in the runtime log, suggesting that the container is in an inactive state, but the cause of the anomaly is unrelated to metadata corruption. Similar to generating the first alarm message, after generating the second alarm message, the host device can generate an identifier based on the detection timestamp, making it easier for operations and maintenance personnel to trace the specific timing of the anomaly.

[0133] Unlike the process of generating the first alarm message, the second alarm message is used to characterize non-metadata corruption anomalies. Its alarm content indicates that the container's inactivity was caused by other reasons and needs to be pushed to other operation and maintenance subsystems for collaborative investigation. In this embodiment, after generating the second alarm message, the host device needs to promptly push it to the operation and maintenance personnel's corresponding operation and maintenance terminal or centralized alarm platform to prompt them to conduct further investigation into non-metadata corruption anomalies during container operation.

[0134] Through the above steps S310 to S350, the embodiment of this application enables the host device to use keywords in the configuration file to filter log content, accurately identify metadata corruption characteristics, avoid recovery misjudgments caused by other anomalies, realize intelligent identification and classification response to faults that occur during container runtime, and improve the automation level of container runtime stability management.

[0135] Figure 6This is a schematic diagram illustrating a process for restoring metadata files during container runtime, provided in an embodiment of this application. The following is based on... Figure 6 The content shown herein serves as an illustrative example of the process by which the host device restores the metadata files of the container during runtime in the embodiments of this application.

[0136] like Figure 6 As shown, in this embodiment of the application, the process of the host device restoring the metadata file of the container runtime may include the following steps S510 to S550.

[0137] S510: Create a recovery state file in the storage area.

[0138] In step S510, after the host device detects that the number of damage detections is greater than or equal to the detection threshold stored during container runtime, it triggers the metadata recovery process to restore the metadata files of the container runtime. First, the host device can create a recovery status file, such as the containerdRecover.state file, in the storage area corresponding to the container orchestration platform, indicating that the recovery process has been started.

[0139] In this embodiment, the recovery state file can be created in any storage path corresponding to the container orchestration platform. For example, the storage path of the recovery state file can be " / var / local / test / containerdRecover.state". Similar to step S200 in the previous embodiment, the host device can use the "touch" command to create the file to confirm that the recovery process has started.

[0140] If creation fails, the host device can determine that there is an abnormal write permission or insufficient disk space in the current container orchestration platform. The host device can generate a corresponding error alarm and terminate the recovery process. The error alarm is used to prompt the operation and maintenance personnel that the write to the recovery status file failed, so that the operation and maintenance personnel can intervene in time to check the disk or permission problems. If creation is successful, the host device can execute the following step S520 to perform the subsequent metadata file recovery process.

[0141] S520: Shut down the container runtime to release the container runtime's metadata files.

[0142] In step S520, because the container runtime locks the metadata file meta.db during operation to prevent concurrent modification, the host device can execute the stop command related to the container runtime after creating the recovery state file, shut down the container runtime process, and release the meta.db file to facilitate subsequent operations on the meta.db file.

[0143] For example, the host device can execute the "systemctl stop containerd" command to shut down the containerd process, thus making the meta.db file unused. The host device can then determine whether the containerd process has successfully terminated based on the result of the stop command. If it terminates successfully, it will execute step S530 below. If termination fails, the host device will generate an alarm message corresponding to the containerd process termination failure to notify maintenance personnel to check the containerd service status and system resource usage.

[0144] In the command "systemctl stop containerd", "systemctl" is a command-line tool used to manage system services on the host device, the "stop" parameter is used to stop the specified service, and "containerd" is the name of the service corresponding to the command. By executing this command, the host device controls the containerd service to shut down, preventing the enabled containerd service from occupying the meta.db file and causing subsequent recovery operations to fail.

[0145] S530: Clean up the container runtime metadata files and container network interface files.

[0146] In step S530, the host device can clean up the metadata file mate.db and the container network interface file, completely removing any corrupted mate.db files and simultaneously clearing all residual data in the container network interface file. The container network interface (CNI) is a network implementation interface of a container orchestration platform, and the container network interface file is a configuration file used to configure the container network. It can be located at the storage address " / var / lib / cni" and contains key information such as network plugin configurations and IP address allocation records.

[0147] In this embodiment, since the container network interface file stores network status information and this information is coupled with the data stored in the corrupted meta.db, cleaning up the container network interface file at the same time as cleaning up the meta.db file can avoid derivative failures such as IP conflicts and routing anomalies caused by residual network status after the container restarts, and provide a consistent operating environment foundation for the subsequent recovery process.

[0148] For example, the host device can execute the command "rm -rf / var / lib / containerd / io.containerd.metadata.v1.bolt / meta.db" to delete the meta.db file. Here, the "rm" command is used to delete files at the specified path; the "-rf" parameter specifies that the deletion command is executed recursively; and " / var / lib / containerd / io.containerd.metadata.v1.bolt / meta.db" specifies the path to the meta.db file to be deleted. In this embodiment, recursive execution ensures that the deletion command not only deletes the file itself at the specified path but also recursively enters that storage path, deleting all subdirectories and files within it, ensuring that the storage directory corresponding to the metadata file is completely emptied.

[0149] Correspondingly, the process of cleaning up container network interface files on the host device can be achieved using "rm -rf / var / lib / cni / ". The command will execute " / var / lib / cni / "All configuration files and status records under the path are cleared together, thereby synchronously cleaning up the network status information related to the metadata file, ensuring that the container network configuration is completely synchronized with the newly generated metadata file in subsequent steps."

[0150] S540: Starts the container runtime to create new metadata files.

[0151] In step S540, after the host device has cleaned up the metadata files and container network interface files, it can execute corresponding instructions to start the container runtime, thereby creating new metadata files and restoring the container runtime's operating environment. For example, the host device can execute the "systemctl start containerd" instruction to start the containerd process and trigger its initialization process to create new metadata files.

[0152] Similar to the process of shutting down a container on the host device, the "systemctl start containerd" command is used to control the startup of the containerd service. During the execution of the "systemctl start containerd" command on the host device, because the meta.db file has been cleared, the startup command triggers containerd to automatically initialize and create a new meta.db file, enabling the container to start normally.

[0153] In this embodiment of the application, the host device can respond to the execution result of the "systemctl start containerd" command and execute the corresponding process. If the execution is successful, it will proceed to step S550; otherwise, if the execution fails, it will exit the recovery process and generate alarm information corresponding to the failure of container runtime startup, so that operation and maintenance personnel can promptly investigate abnormal reasons such as underlying dependencies, permissions, or disk space.

[0154] S550: Delete the recovery status file.

[0155] In step S550, after receiving feedback that the container runtime has started successfully, the host device can delete the recovery status file from its storage path to mark that the self-recovery process has been fully executed. For example, the instruction to delete the recovery status file can be similar to the instruction to delete the metadata file and container network interface file in step S530 above; that is, the host device can execute "rm -f / var / local / test / containerdRecover.state" to ensure that the recovery status mark of the container runtime's metadata file is cleared, preventing it from being mistakenly judged as incomplete recovery and triggering repeatedly.

[0156] The "-f" parameter in the instruction executed by the host device indicates forced deletion without prompting for confirmation, which enables the operation to completely remove the recovery state file, avoiding file residue and affecting the normal operation of the container after recovery.

[0157] Through the above steps S510 to S550, the host device can achieve automated recovery of the container runtime after the metadata file is damaged through coordinated processes such as status marking and metadata deletion, avoiding manual intervention in the recovery process and improving the stability and operation and maintenance efficiency of the container runtime.

[0158] Figure 7 This is a flowchart illustrating another metadata corruption recovery method provided in an embodiment of this application. The following is based on... Figure 7 The content shown illustrates, by way of example, the process by which the host device handles corrupted metadata files during container runtime in an embodiment of this application.

[0159] like Figure 7 As shown, the process for a host device to restore a damaged metadata file during container runtime, as provided in this embodiment of the application, may further include the following steps S101 to S103.

[0160] S101: Check if the recovery status file exists.

[0161] In step S101, when the host device initiates the detection process for container runtime, it can first check whether a recovery status file exists in the corresponding storage path. If the host device detects a recovery status file in any storage path, it is determined that the historical recovery process was interrupted, and the host device can execute step S103 to skip the fault detection step and enter the recovery process; if no recovery status file is detected, step S102 is executed to start the regular fault detection process.

[0162] In the embodiments of this application, such as Figure 7 As shown, step S101 is executed only when the host device triggers the detection process based on the detection cycle in the configuration file, so as to ensure that the recovery status check does not interfere with the detection rhythm, thereby maintaining the timing stability and policy consistency of the detection mechanism.

[0163] S102: If the recovery state file does not exist, update the number of corruption detections during container runtime to zero.

[0164] In step S102, if the host device does not detect the recovery status file, the number of damage detections during container runtime can be initialized to 0 as the starting point of the detection process. This avoids misjudgment caused by contamination of the initial value of the counter corresponding to the number of damage detections, ensuring that the number of damage detections accumulates effectively only within one detection cycle, thereby improving the accuracy of fault determination.

[0165] After the host device initializes the number of damage detections to 0, it can sequentially execute steps S100 to S500 and the sub-steps corresponding to steps S100 to S500 in the aforementioned embodiment based on the execution conditions of each step, thereby realizing the detection and recovery of metadata file corruption during container runtime.

[0166] S103: If the recovery state file exists, restore the container runtime metadata file based on the recovery state file.

[0167] In step S103, if the host device detects the existence of the recovery status file, it can skip the fault detection step and directly enter the recovery process. Using the recovery status file, it performs the operation of restoring the metadata files of the container runtime. For example, after determining that the recovery status file exists, the host device can execute step S500 and its corresponding sub-steps S510 to S550 in the aforementioned embodiment to complete the recovery process of the container runtime's metadata files.

[0168] It should be noted that since the recovery status file already exists at this time, when the host device performs recovery based on the recovery status file, step S510 will write the timestamp that triggered the recovery process into the recovery status file to ensure that the recovery action is traceable; subsequent steps S520 to S550 will be executed sequentially according to the logical order in the aforementioned embodiment to achieve accurate repair of metadata corruption.

[0169] In this embodiment of the application, through the above steps S101 to S103, the host device can use the recovery status file to determine whether the container is in a historical recovery interruption state during runtime, and dynamically select the detection or recovery process accordingly, thereby ensuring system availability while avoiding repeated detection and redundant recovery operations.

[0170] Figure 8 This is a schematic diagram illustrating a process for backing up corrupted metadata files, provided in an embodiment of this application. The following is in conjunction with... Figure 6 and Figure 8 The content shown illustrates, through example, the process of backing up metadata files when the host device restores the metadata files of a container during runtime in this embodiment of the application.

[0171] like Figure 8 As shown, the process of backing up metadata files on the host device in this embodiment may include the following steps S561 to S566.

[0172] S561: Retrieves the backup path parameter stored in the container runtime configuration file.

[0173] In step S561, after shutting down the container runtime to release its metadata files, the host device can obtain the backup path parameters stored in the container runtime's configuration file. In this embodiment, the container runtime's configuration file may define a "backup_paths" field to store backup path parameters, and the corresponding field value is a subdirectory path of the container orchestration platform, such as " / var / local / backup".

[0174] The value of the "backup_paths" field in the configuration file can be the same as other fields in the configuration file, and can be changed in response to configuration instructions to flexibly adapt to the backup strategy requirements of different deployment environments.

[0175] In some embodiments, because different deployment environments have different requirements for metadata file backup, in low-resource or test environments, the host device supports configuring the "backup_paths" field in the configuration file to an empty value or commenting it out. In this case, after reading the backup path parameter, the host device can trigger a skip backup process operation, so that the host device can execute step S530 to delete the metadata file and container network interface file. However, in high reliability scenarios, the "backup_paths" field in the configuration file must be a valid path to facilitate the host device to perform backup operations to preserve damaged metadata files.

[0176] For example, the host device can determine whether the metadata file needs to be backed up by reading the "backup_paths" field in the configuration file. If the field value is empty or commented out, the backup step is skipped and S530 is executed directly; otherwise, the host device can execute step S562 and subsequent steps to back up the corrupted metadata file.

[0177] S562: Create a file directory corresponding to the backup path parameters.

[0178] In step S562, the host device can execute a directory creation command to create a file directory corresponding to the backup path parameter. For example, the directory creation command can be "mkdir {backup_paths}", where {backup_paths} is the backup path parameter in the configuration file, and the "mkdir" command is used to create a file directory at the specified path so that the corrupted metadata file can be safely migrated to that directory later.

[0179] Taking the value of the "backup_paths" field as " / var / local / backup" as an example, when the host device executes the directory creation command, it will create a subdirectory named "backup" under the storage path " / var / local" so that this directory can be used to store data migrated from the metadata file later.

[0180] S563: Detect backup path parameters.

[0181] In step S563, after executing step S562, the host device can determine the validity of the backup parameters based on the execution result. If the backup path has been successfully created, the parameters are deemed valid, and the host device can execute step S566 to back up the corrupted metadata file; if the backup path creation fails or permissions are insufficient, the parameters are deemed invalid, and the host device can execute steps S564 and S565.

[0182] S564: Stop the recovery process when the backup path parameter is invalid.

[0183] In step S564, after determining that the backup path parameters are invalid, the host device can stop the recovery process for the container runtime, thereby avoiding the risk of data loss caused by directly deleting the damaged metadata file and improving system stability and fault traceability.

[0184] S565: Generate the third alarm message.

[0185] In step S565, after stopping the recovery process during container runtime, the host device can generate a third alarm message containing a fault timestamp. This third alarm message is used to indicate an anomaly in the backup of the container's metadata files. The host device can store the third alarm message in the local log system and push it synchronously to the operations and maintenance personnel's terminals, facilitating their timely intervention to investigate issues such as incorrect backup path configuration, insufficient disk space, or abnormal permissions. This allows operations and maintenance personnel to combine alarm information with the maintenance of the container orchestration platform's stability.

[0186] S566: When the backup path parameter is valid, back up the container runtime metadata files to the file directory.

[0187] In step S566, after the host device detects that the file directory has been successfully created based on the backup path parameters, it can back up the corrupted metadata file to that file directory to achieve secure isolation and traceability of the metadata. For example, the backup operation can completely copy all files in the path " / var / lib / containerd / io.containerd.metadata.v1.bolt / meta.db" to the " / var / local / backup / " directory to achieve a complete snapshot retention of the corrupted metadata state.

[0188] After the backup is complete, the host device can verify the backup integrity to ensure that the file hash value is consistent with the source file, thereby avoiding data corruption of metadata files due to input / output errors during the backup process and improving backup reliability.

[0189] Through the above steps S561 to S566, the embodiment of this application enables the host device to isolate and back up the damaged metadata file in the process of restoring the metadata file, ensuring that the fault scene is traceable and the recovery process is rollbackable, thereby optimizing the robustness of fault handling.

[0190] Figure 9 This is a schematic diagram of a container runtime startup process provided in an embodiment of this application. The following is based on... Figure 9 The disclosed content provides an exemplary description of the process by which the host device starts the container runtime in the embodiments of this application.

[0191] like Figure 9As shown in the embodiments of this application, the process of the host device starting the container runtime to create a new metadata file may include the following steps S541 to S545.

[0192] S541: Starts the main process of the container runtime.

[0193] In step S541, the host device can start the main process of the containerd service by executing the "systemctl start containerd" command, thereby switching the container runtime from a shut-down state to a running state. The host device can determine the startup success by receiving status feedback during the containerd service startup process.

[0194] In this embodiment of the application, if the host device detects that the execution return code of the "systemctl start containerd" instruction is 0, it determines that the main process of the container runtime has entered the startup process. Subsequently, the host device can determine the startup effect of the container runtime by detecting the activity status of the container runtime.

[0195] S542: Create the metadata file corresponding to the container runtime.

[0196] In step S542, the host device can trigger an initialization process after the container runtime starts to create a new metadata file meta.db. This file can be located in the path / var / lib / containerd / io.containerd.metadata.v1.bolt / and serve as the metadata file for the container runtime after restart. This file will carry core metadata information such as container image, container instance and namespace to provide persistent storage support for the container runtime.

[0197] It should be noted that the meta.db file created by the host device at this time is an initial empty database, containing only the basic structure and no metadata records of any business containers or images. It needs to be rebuilt and populated with the original data stored in the storage unit of the container runtime so that it has complete business carrying capacity.

[0198] S543: Detect the active status of the container during runtime.

[0199] In step S543, after the host device starts the container runtime and creates the corresponding metadata file, it can detect the activity status of the container runtime and verify whether the container runtime has entered a normal service state. In this embodiment of the application, the host device can detect the activity status of the container runtime in the manner shown in step S100, so as to determine whether the metadata file recovery process is successful based on its running status after the container runtime is restarted.

[0200] It should be noted that restarting the container runtime is a time-consuming process. Therefore, the host device can perform the activity status check multiple times after a delay following the completion of steps S541 and S542, for example, by performing the activity status check every 5 seconds, and using the last query result within a preset time as the determination criterion. For example, the preset time can be 30 seconds. During the 30-second period after the host device performs the first activity status check on the restarted container runtime, the host device can periodically perform the activity status check and determine whether the container runtime is active based on the last query result within the preset time.

[0201] S544: If the activity status is active, then restore the business functions of the container runtime.

[0202] In step S544, when the host device detects that the container runtime is active, it can determine that the container runtime has been successfully started and has basic service capabilities. At this time, the host device can restore its business functions based on the restarted container runtime and manage tasks such as container instances, image pulling and scheduling in the container orchestration platform.

[0203] S545: If the activity status is inactive, then generate a fourth alarm message.

[0204] In step S545, when the host device detects that the container runtime activity state is inactive, it can determine that the host device failed to restart the container runtime. At this time, the host device can generate a fourth alarm message to indicate that the container runtime restart failed. Similar to the alarm messages generated in the previous embodiments, the fourth alarm message can also be stored in a local log file and pushed to the operator's terminal to indicate that the container runtime has metadata file corruption and recovery failed, requiring manual intervention to check for underlying storage anomalies or to perform a forced reconstruction process.

[0205] Through the above steps S541 to S545, the embodiment of this application enables the host device to rebuild the metadata file and complete the verification process of the container runtime status when restarting the container runtime, thereby reducing the service interruption time caused by metadata corruption and improving the overall stability and self-healing capability of the system.

[0206] Figure 10 This is a schematic diagram illustrating a process for restoring runtime business functions of a container, provided as an embodiment of this application. The following is based on... Figure 10 The content shown here is an exemplary illustration of the process by which the host device restores the runtime business functions of the container using the newly created metadata file after creating a new metadata file in the embodiments of this application.

[0207] like Figure 10As shown in the embodiments of this application, the process of the host device restoring the business functions of the container during runtime may include the following steps S571 to S574.

[0208] S571: Retrieves the restore image path parameter stored in the container runtime configuration file.

[0209] In step S571, the host device can read the storage path parameter of the recovery image in the configuration file at runtime of the container, so that the host device can locate the storage path of the image file that can be pulled to the metadata file based on the parameter, thereby providing data basis for subsequent image loading and metadata file writing.

[0210] In this embodiment of the application, the configuration file of the container runtime can define a "recovery_image_paths" field, the value of which is the storage path of the directory where the image source file is located, such as " / var / local / deploy / images / ". Multiple container image data packages required by the business can be stored under this path, so that after the container runtime restarts and a new metadata file is created, it can be loaded into the working directory where the new metadata file is located, so that the reconstructed metadata file can be quickly restored to a state where the business can be executed.

[0211] S572: Based on the recovery image path parameters, load each image located in the storage path corresponding to the recovery image path parameters.

[0212] In step S572, the host device can execute an image loading instruction based on the recovery image path parameters stored in the configuration file to load the image file under the specified path into the directory where the newly created metadata file is located, so as to accelerate the business function recovery process during container runtime.

[0213] For example, the image loading command can take the form of "ctr -n k8s.io images import / var / local / deploy / images / xx.gz", where "ctr" is the containerd command-line tool used to perform tasks such as managing images and containers; "-n k8s.io" is used to specify the namespace so that the metadata files created at runtime can be correctly recognized by container orchestration platforms of type Kubernetes; "images import" indicates the image import operation, the path parameter points to the container image package to be loaded, and "xx.gz" is the specific image file name.

[0214] Based on image loading instructions, the host device can load images from a specified path into a newly created metadata file, thereby completing the base image layer that the container runtime depends on. This process supports concurrent loading of multiple images, significantly reducing recovery time. Furthermore, the host device can also collect loading results during the loading process and write them to logs in real time, making the container runtime recovery process traceable.

[0215] In some implementations of this application, the host device can also restore the newly created metadata file by calling the metadata snapshot stored in the storage unit and combining it with the image data loaded in the newly created metadata file. This enables the newly created metadata file to quickly achieve the same integrity and consistency as before the failure, thereby optimizing the accuracy of metadata reconstruction and the ability to ensure business continuity.

[0216] S573: The smallest deployment unit to start a container orchestration platform.

[0217] In step S573, after the host device loads the image, it can control the container orchestration platform to call the minimum deployment unit to restart the service functions of the minimum deployment unit. For example... Figure 1 and Figure 2 As shown, the container runtime can manage the lifecycle of containers and images of each minimum deployment unit. Therefore, during the restart process of the container runtime, each minimum deployment unit is also in a standby state. After the metadata reconstruction and image loading are completed, the host device can send a restart command to the container orchestration platform to trigger each minimum deployment unit to start the business functions of the container orchestration platform.

[0218] After the host device executes the image loading process, when starting the minimum deployment unit, the container runtime only needs to call the already loaded image to create the container, which reduces the time spent pulling and loading images, shortens the business interruption time caused by metadata corruption, and improves the system's self-healing capability.

[0219] S574: Determine the recovery status of business functions during container runtime based on the status of the smallest deployment unit.

[0220] In step S574, the host device can determine the recovery status of the service functions during container runtime based on the status of each minimum deployment unit after restarting. If all minimum deployment units corresponding to the container runtime become running, it is determined that the service functions have been fully restored; if any minimum deployment unit is not ready, its status is continuously polled and timeout exceptions are recorded until a preset retry threshold is reached, triggering an alarm to prompt the operations and maintenance personnel that there are still minimum deployment units that are not ready after the container runtime restarts.

[0221] Through the above steps S571 to S574, the embodiment of this application enables the host device to accelerate the business recovery speed of the container runtime by loading the image file after restarting the container runtime, which facilitates the host device to start each minimum deployment unit and maintain its stable business operation in the subsequent process.

[0222] Figure 11 This is a schematic diagram of a metadata corruption recovery system provided in an embodiment of this application.

[0223] Corresponding to the embodiments of the aforementioned metadata corruption recovery method, this application also provides an embodiment of a metadata corruption recovery system. For example... Figure 11 As shown, the recovery system 1100 may include an activity status detection unit 1110, a write test unit 1120, a log analysis unit 1130, and a metadata reconstruction unit 1140.

[0224] The activity status detection unit 1110 is configured to detect the activity status of the container running corresponding to the container orchestration platform.

[0225] Write test unit 1120 is configured to create temporary test files in the working directory of the container runtime when the activity state is inactive.

[0226] The log analysis unit 1130 is configured to read the runtime log of the container runtime when the temporary test file is successfully created; and if the runtime log contains any of the preset keywords of the container runtime, determine that the metadata of the container runtime is corrupted and update the corruption detection count of the container runtime.

[0227] Metadata reconstruction unit 1140 is configured to restore the container runtime metadata file when the number of corruption detections is greater than or equal to the detection threshold stored at the container runtime.

[0228] Figure 12 This is a schematic diagram of a computing device provided in an embodiment of this application.

[0229] like Figure 12 As shown, the computing device 1200 includes a processor 1201 and a memory 1202. Exemplarily, the computing device 1200 may also include a communications interface 1203 and a communications bus 1204.

[0230] The processor 1201, memory 1202, and communication interface 1203 communicate with each other via communication bus 1204. The communication interface 1203 may include a transmitter and receiver for communicating with other devices or communication networks. It can be a wired interface (port), such as a fiber distributed data interface (FDDI) or a gigabit Ethernet interface (GE).

[0231] In some embodiments, the processor 1201 is used to execute program 1205, specifically performing the relevant steps in the above-described inference task execution method embodiments. Specifically, program 1205 may include program code, which includes computer-executable instructions.

[0232] For example, processor 1201 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement some embodiments of this application. Computing device 1200 may include one or more processors, which may be processors of the same type, such as one or more CPUs; or processors of different types, such as one or more CPUs and one or more ASICs. The CPU may be a single-core CPU or a multi-core CPU.

[0233] In some embodiments, memory 1202 is used to store program 1205. Memory 1202 may include high-speed random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device.

[0234] Specifically, program 1205 can be called by processor 1201 to cause computing device 1200 to perform the method operations described in the above embodiments.

[0235] Some embodiments of this application provide a computer-readable storage medium storing at least one executable instruction that, when executed on a computing device 1200, causes the computing device 1200 to perform the metadata corruption recovery method described in the above embodiments.

[0236] The executable instructions can be used to cause the computing device 1200 to perform metadata corruption recovery operations.

[0237] For example, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, a floppy disk, and an optical data storage device, etc.

[0238] This application provides a chip device in some embodiments, which is applied to a server. The chip device includes one or more interface circuits and one or more processors. The interface circuits and processors are interconnected via lines. The interface circuits are used to receive signals from the server's memory and send signals to the processors, the signals including computer instructions stored in the memory. When the server processor executes the computer instructions, the server performs various steps in the metadata corruption recovery method shown in the above-described method embodiments.

[0239] The beneficial effects that the readable storage medium provided in some embodiments of this application can achieve can be referred to the beneficial effects in the corresponding metadata corruption recovery method provided above, and will not be repeated here.

[0240] The embodiments described above are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made based on the technical solution of this application should be included within the scope of protection of this application.

Claims

1. A method for recovering corrupted metadata, characterized in that, The method includes: Detect the active status of the container during runtime; When the activity status is inactive, a temporary test file is created in the working directory of the container runtime. If the temporary test file is created successfully, read the runtime log of the container. If the runtime log contains any of the preset keywords in the container runtime, then the metadata of the container runtime is determined to be corrupted, and the corruption detection count of the container runtime is updated. When the number of damage detections is greater than or equal to the detection threshold stored during container runtime, the metadata file of the container runtime is restored.

2. The method according to claim 1, characterized in that, The detection of the container's running activity status includes: Obtain the runtime status parameters of the container; The operational status of the container during runtime is determined based on the aforementioned operational status parameters; When the container is in an active state, the number of damage detections during container operation is updated to zero and a first alarm message is generated; the first alarm message is used to indicate that the container is in an active state.

3. The method according to claim 2, characterized in that, The running status parameters include an active status identifier, running result, exit status code, and restart count. The detection of the container's running activity status also includes: When the active state identifier is inactive, the number of restarts is greater than zero, and the exit status code or the running result is abnormal, the active state of the container runtime is determined to be inactive. The container's runtime activity status is determined to be active when the exit status code and the running result are normal, or when the activity status identifier is active or the number of restarts is zero.

4. The method according to any one of claims 1 to 3, characterized in that, The step of reading the runtime logs of the container includes: Obtain the runtime log of the container at a preset number of rows; In the preset number of rows of the operation log, retrieve each keyword; When any of the keywords is matched in the runtime log, the number of corruption detections during container runtime is updated.

5. The method according to any one of claims 1 to 4, characterized in that, After reading the runtime logs of the container, the method further includes: If the runtime log does not contain any preset keywords for the container runtime, the number of damage detections for the container runtime will be updated to zero. A second alarm message is generated; the second alarm message is used to indicate that there are no critical error messages in the operation log.

6. The method according to claim 1, characterized in that, The method of restoring the metadata file of the container runtime includes: Create a recovery status file in the storage area; Shut down the container runtime to release the container runtime's metadata files; Clean up the container runtime metadata files and container network interface files; The container is started to run in order to create new metadata files; Delete the recovery status file.

7. The method according to claim 6, characterized in that, Before detecting the activity state of the container during runtime, the method further includes: Check if the recovery status file exists; If the recovery status file does not exist, the number of corruption detections during container runtime is updated to zero; If the recovery state file exists, the metadata file of the container runtime is restored based on the recovery state file.

8. The method according to claim 6 or 7, characterized in that, Before cleaning up the container runtime metadata files and container network interface files, the method further includes: Obtain the backup path parameter stored in the configuration file of the container runtime; Create a file directory corresponding to the backup path parameters; Back up the metadata files of the container runtime to the file directory.

9. The method according to claim 8, characterized in that, Before establishing the file directory corresponding to the backup path parameter, the method further includes: Detect the backup path parameters; If the backup path parameter is invalid, the recovery process of the container runtime is stopped; A third alarm message is generated, which is used to indicate that the metadata file backup of the container is abnormal during runtime.

10. The method according to any one of claims 6 to 9, characterized in that, The process of starting the container runtime to create a new metadata file includes: Start the main process of the container runtime; Create the metadata file corresponding to the container runtime; Detect the activity status of the container during runtime; If the activity status is active, then the business functions of the container runtime are restored; If the activity status is inactive, a fourth alarm message is generated, which is used to indicate that the container failed to restart during runtime.

11. The method according to claim 10, characterized in that, The restoration of the business functions of the container runtime includes: Obtain the recovery image path parameter stored in the configuration file of the container runtime; Based on the recovery image path parameters, load each image located in the storage path corresponding to the recovery image path parameters; Start the smallest deployment unit of the container orchestration platform; Based on the status of the minimum deployment unit, determine the recovery status of the business functions during container runtime.

12. A computing device, characterized in that, include: Processor and memory; The processor and the memory are coupled together; The memory is used to store program instructions; The processor is used to execute the program instructions to perform the metadata corruption recovery method as described in any one of claims 1 to 11.

Images