Hybrid cloud-based cloud-native database recovery method, device and storage medium

Abstract

The application discloses a cloud-native database recovery method and device based on a hybrid cloud and a storage medium, and belongs to the technical field of data processing. The technical problem to be solved by the application is how to realize database recovery compatible with Kubernetes technology, complete data migration, and then meet the needs of customers for rapid cloud migration in the cloud era. The technical scheme adopted is as follows: the method specifically comprises the following steps: a recovery medium deployed in a Kubernetes cluster in an application mode is used to listen to a Kubernetes custom resource event in real time; the recovery medium is used to listen to a creation of a Kubernetes custom resource event, create a Kubernetes Job resource required for recovery, and realize recovery of data; wherein, the creation of the Kubernetes Job resource required for recovery comprises a recovery task Job and a master-slave task Job; the recovery medium is used to listen to a backup Kubernetes Job resource event, judge whether the recovery task Job and the master-slave task Job are successful, and according to a task state execution result, update information to the Kubernetes custom resource.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, in particular to a cloud-native database recovery method and device based on a hybrid cloud and a storage medium. BACKGROUND

[0002] In relation to database recovery, first of all, two mainstream backup tool softwares need to be explained: open source xtrabackup software realizes physical backup, and mysqldump software realizes logical backup. Database recovery is to realize the recovery function based on the existing physical backup or logical backup as source data.

[0003] Kubernetes in the cloud era is an open source that is used to manage containerized applications on multiple hosts in the cloud platform, and the goal of Kubernetes is to make the deployment of containerized applications simple and efficient. Kubernetes provides a mechanism for application deployment, planning, updating and maintenance. Operator is developed by CoreOS to extend the Kubernetes API, and is a specific application controller that is used to create, configure and manage complex stateful applications such as databases, caches and monitoring systems. Operator is built based on the resource and controller concepts of Kubernetes, but also contains application-specific domain knowledge.

[0004] Kubernetes is a container orchestration engine open sourced by Google, which supports automatic deployment, large-scale scalability and application container management. When deploying an application in a production environment, multiple instances of the application are usually deployed to balance the application requests.

[0005] In Kubernetes, multiple containers can be created, each of which runs an application instance, and then through the built-in load balancing strategy, the management, discovery and access of the group of application instances are realized, and these details do not need to be configured and processed by the operation and maintenance personnel.

[0006] With the gradual rise of cloud computing, higher requirements are put forward for databases, so how to realize the database recovery compatible with Kubernetes technology, complete data migration, and then meet the needs of customers to quickly go to the cloud in the cloud era is a technical problem to be solved at present. SUMMARY

[0007] The technical task of the present application is to provide a cloud-native database recovery method and device based on a hybrid cloud and a storage medium to solve the problem of how to realize the database recovery compatible with Kubernetes technology, complete data migration, and then meet the needs of customers to quickly go to the cloud in the cloud era.

[0008] The technical task of the present application is achieved in the following way, a hybrid cloud-based cloud-native database recovery method, which is as follows:

[0009] The recovery medium deployed in the Kubernetes cluster in the form of an application listens to the Kubernetes custom resource event in real time;

[0010] The recovery medium listens to the creation of a Kubernetes custom resource event, creates a Kubernetes Job resource required for recovery, and realizes data recovery; wherein creating a Kubernetes Job resource required for recovery includes a recovery task Job and a master-slave task Job;

[0011] The recovery medium listens to the backup Kubernetes Job resource event, judges whether the recovery task Job and the master-slave task Job are successful, and updates the information to the Kubernetes custom resource according to the task state execution result.

[0012] As a preferred, the recovery medium supports the recovery of two types of data files, database logical backup and full physical backup, the recovery medium and Kubernetes rely on custom resources (CR) to pass user request information, the definition of the recovery custom resource is completed when the recovery medium is initialized, and the user does not need to care about the creation of the resource, and understands the attribute configuration.

[0013] More preferably, the recovery medium provides a Restful style API interface for users to use, the API interface includes a recovery request interface, a recovery task history interface, a current recovery task interface, and an abort and delete recovery task interface; the API interface provided by the recovery medium is a viewing interface for the state information of the recovery CR, which is realized by calling the kubernetes command, avoiding direct contact of the user with kubernetes, and reducing the user's use threshold.

[0014] More preferably, the database recovery file in the database logical backup is imported from an external object storage, and the recovery medium supports swift protocol and S3 protocol for user selection; in the data recovery CR, the location of the backup in the object storage (OSS) is defined, and the location in the object storage (OSS) includes the domain name, the storage bucket, the file name, and the database node (one or more, multiple database nodes are the database cluster to be recovered) to be recovered.

[0015] More preferably, the recovery of the full physical backup is as follows:

[0016] The user calls the recovery request interface provided by the recovery medium;

[0017] The recovery medium generates a recovery request custom resource according to the user transmission parameter, and calls Kubernetes to create the custom resource;

[0018] After receiving the request, the Kubernetes creates the recovery request custom resource and generates a recovery custom resource creation event;

[0019] After the recovery medium listens to the recovery request custom resource creation event, the recovery medium calls Kubernetes to update the custom resource state to "recovery task starting";

[0020] After the recovery medium listens to the recovery task Job successful creation event, the recovery medium updates the custom resource state to "recovery task execution", and waits for the recovery task Job execution result;

[0021] After the Kubernetes recovery task Job is created, the resources are allocated according to the Job configuration, and the Job load resource Pod is created successfully, and the database recovery operation is executed; wherein, if the backup is restored to a database cluster, the recovery task Job covers the recovery of all database nodes;

[0022] When the recovery task execution is successful, the Kubernetes generates a recovery task Job successful execution event, which is listened to by the recovery medium, and the recovery custom resource state is adjusted to "recovery task execution success"; on the contrary, if the recovery task Job load (Pod resource) is not successfully created, or the recovery process execution is abnormal, it will lead to the failure of the recovery task Job execution, and the recovery medium will update the specific failure reason to the recovery custom resource, and update the state to "recovery task execution failure".

[0023] For the recovery of database logical backup, the recovery process is basically the same as the above. The only difference is that the logical backup recovery is only performed on the master node.

[0024] More preferably, in the case of recovery task Job execution failure, the recovery medium tracks the failure reason in the following way:

[0025] ①Listen to the recovery task Job event;

[0026] ②Listen to the recovery task Job load (Pod resource) event and execution log;

[0027] The recovery medium guarantees the integrity of the recovery request custom resource information, and presents the information to the user in a complete manner; the recovery medium listens to the recovery task Job failure event message, and filters according to the information in the recovery task Job event:

[0028] If the failure reason is present in the Job event message of the recovery task, then update the failure reason in the recovery request CR resource.

[0029] If the failure reason is not clearly stated in the Job event message of the recovery task, the recovery medium will listen for Pod resource (recovery job load) events, obtain the event information generated by the Pod resources, make a reasonable judgment, and confirm the failure reason.

[0030] More preferably, the recovery media implements data recovery functions for single-node databases and cluster databases based on full physical backups; when multiple database nodes need to be recovered in a user request, the recovery media assumes that the database nodes provided by the user are in a cluster, performs backup and recovery, and sets up master-slave replication. The master node in the cluster is selected by default from the first database node provided by the user; otherwise, the specified master-slave replication is used.

[0031] The database recovery process for a clustered database is the same as that for a single database.

[0032] Ideally, cluster recovery and setup should be performed as follows:

[0033] The cluster is built after each database node has been restored. When the recovery media hears a message that the recovery task has been successfully executed, the recovery media changes the custom resource status to "cluster building in progress" and calls Kubernetes to create and build the cluster job.

[0034] The cluster setup job metadata information is generated based on user request data. When setting up a cluster, the recovery media automatically parses the node backup files to obtain the necessary data information for setting up the cluster (the user only needs to provide the database account for setting up master and slave).

[0035] When the recovery media listener receives a completion message for the cluster setup job, it calls Kubernetes to update the status of the custom resource to "recovery successful", thus completing the recovery and cluster setup.

[0036] An electronic device includes: a memory and at least one processor;

[0037] The memory stores computer-executed instructions;

[0038] The at least one processor executes the computer execution instructions stored in the memory, causing the at least one processor to perform the cloud-native database recovery method based on hybrid cloud as described above.

[0039] A computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the cloud-native database recovery method based on hybrid cloud as described above.

[0040] Operators, developed by CoreOS, extend the Kubernetes API. They are application-specific controllers used to create, configure, and manage complex stateful applications such as databases, caching, and monitoring systems. Operators are built upon Kubernetes resource and controller concepts but also incorporate application-specific domain knowledge. A key aspect of creating an Operator is the design of its Custom Resource Request (CRD). Essentially, an Operator follows the same pattern as a Controller in Kubernetes, managing its resources by monitoring or checking their expected state, comparing it to the current state, and updating accordingly if discrepancies are found.

[0041] The cloud-native database recovery method, device, and storage medium based on hybrid cloud of the present invention have the following advantages:

[0042] (i) This invention provides a database recovery method with low R&D cost, high R&D efficiency, and high scalability, and it has strong adaptability and can be widely used in various database recovery systems.

[0043] (ii) This invention is based on cloud-native technology and can achieve cross-cloud recovery, solving problems such as difficulties for users to migrate to the cloud and difficulties for data migration;

[0044] (III) This invention leverages the cloud-native features of Kubernetes to extend the functionality of Kubernetes and utilizes custom resource objects to implement database recovery tasks, thereby meeting the needs of customers in the cloud era to quickly migrate to the cloud. Attached Figure Description

[0045] The invention will be further described below with reference to the accompanying drawings.

[0046] Appendix Figure 1 A diagram illustrating the CR status transition for backup and recovery;

[0047] Appendix Figure 2 This is a flowchart for restoring backup files. Detailed Implementation

[0048] The cloud-native database recovery method, device, and storage medium based on hybrid cloud of the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0049] Example 1:

[0050] This embodiment provides a cloud-native database recovery method based on hybrid cloud, as detailed below:

[0051] S1. Monitor Kubernetes custom resource events in real time using recovery media deployed in the Kubernetes cluster as an application;

[0052] S2. Create custom Kubernetes resource events by listening to the recovery media, create the Kubernetes Job resources required for recovery, and realize data recovery; among them, creating the Kubernetes Job resources required for recovery includes the recovery task Job and the master-slave setup task Job;

[0053] S3. By monitoring backup Kubernetes Job resource events through the recovery media, determine whether the Job recovery task and the master-slave job setup task were successful, and update the information to the Kubernetes custom resources according to the task status and execution results.

[0054] In this embodiment, the recovery media supports the recovery of two types of data files: logical database backups and full physical backups. The recovery media and Kubernetes rely on custom resources (CR) to transmit user request information. The definition of the custom resource is completed during the initialization of the recovery media. Users do not need to care about the creation of the resource, but only need to understand its attribute configuration.

[0055] In this embodiment, the recovery medium provides RESTful API interfaces for users. These API interfaces include interfaces for initiating recovery requests, viewing recovery task history, viewing current recovery tasks, and terminating or deleting recovery tasks. The API interfaces provided by the recovery medium are for viewing recovery CR status information, which is achieved by calling Kubernetes commands, thus avoiding direct user interaction with Kubernetes and lowering the barrier to entry for users.

[0056] In this embodiment, the database recovery file in the logical backup of the database is imported from an external object storage. The recovery medium supports the Swift protocol and the S3 protocol for users to choose from. In the data recovery CR, the location of the backup in the object storage (OSS) is defined. The location in the object storage (OSS) includes the domain name, bucket, file name, and the database node to which the recovery needs to be performed (one or more, where multiple database nodes are the database cluster to which the recovery task is performed).

[0057] The full physical backup recovery in this embodiment is as follows:

[0058] (1) The user calls the recovery request interface provided by the recovery medium;

[0059] (2) The recovery medium generates a recovery request for custom resources based on the parameters passed by the user, and calls Kubernetes to create the custom resources;

[0060] (3) After receiving the request, Kubernetes creates the custom resource to be restored and generates a custom resource creation event.

[0061] (4) After the recovery media detects the custom resource creation event of the recovery request, the recovery media calls Kubernetes to update the status of the custom resource to "Recovery task starting"; at the same time, the recovery media calls Kubernetes to create a recovery task Job;

[0062] (5) When the recovery media detects the successful creation of the recovery task Job, the recovery media updates the status of the custom resource to "Recovery task in progress" and waits for the execution result of the recovery task Job;

[0063] (6) After the Kubernetes recovery job is created, resources are allocated according to the job configuration. After the job load resource Pod is successfully created, the database recovery operation is performed. If the backup is restored to a database cluster, the recovery job covers the recovery of all database nodes.

[0064] (7) When the recovery task is executed successfully, Kubernetes generates a recovery task Job successful execution event. This event is listened to by the recovery media, and the recovery media adjusts the status of the recovery custom resource to "Recovery task executed successfully". Conversely, when the recovery task Job load (Pod resource) is not successfully created, or the recovery process is abnormal, the recovery task Job will fail to execute. The recovery media will update the specific failure reason to the recovery custom resource and update the status to "Recovery task executed failed".

[0065] The recovery process for database logical backups is largely the same as described above. The only difference is that logical backup recovery is performed only on the master node.

[0066] In this embodiment, when the recovery task (Job) fails to execute, the method for tracing the failure reason through the recovery media is as follows:

[0067] ① Listen for the Job event in the recovery task;

[0068] ② Monitor the job load (Pod resource) events and execution logs for the recovery task;

[0069] The recovery media ensures the integrity of custom resource information in the recovery request and presents the information completely to the user; the recovery media listens for event messages when a recovery task fails and filters the information based on the information in the recovery task event.

[0070] If the failure reason is present in the Job event message of the recovery task, then update the failure reason in the recovery request CR resource.

[0071] If the failure reason is not clearly stated in the Job event message of the recovery task, the recovery medium will listen for Pod resource (recovery job load) events, obtain the event information generated by the Pod resources, make a reasonable judgment, and confirm the failure reason.

[0072] In this embodiment, the recovery medium implements data recovery functions for single-node databases and cluster databases based on full physical backups. When multiple database nodes need to be recovered in a user request, the recovery medium assumes that the database nodes provided by the user are in a cluster. The recovery medium performs backup and recovery and sets up master-slave replication. The master node in the cluster is selected by default as the first database node provided by the user; otherwise, the specified master-slave replication is used.

[0073] The database recovery process for a cluster database is the same as that for a single database.

[0074] As attached Figure 1 As shown, the cluster recovery and setup in this embodiment are as follows:

[0075] (1) The cluster is built after each database node has been restored; when the recovery medium hears the message that the recovery task Job has been successfully executed, the recovery medium changes the custom resource status to "cluster building in progress" and calls Kubernetes to create and build the cluster Job.

[0076] (2) The metadata information of the cluster job is generated based on the user's request data. When building a cluster, the recovery media automatically parses the node backup files to obtain the necessary data information for building the cluster (the user only needs to provide the database account for building the master and slave).

[0077] (3) When the recovery media listens for the completion message of the cluster build job, it calls Kubernetes to update the status of the custom resource to "recovery successful", and the recovery and cluster build are completed.

[0078] As attached Figure 1 As shown, the backup and recovery process using CR status is as follows:

[0079] a) After the recovery data request CR resource is successfully created, its status is "Starting";

[0080] b) After generating the recovery Job based on the CR resource information, the status changes to "Executing";

[0081] c) If the data recovery job fails to execute, the status will change to "failed";

[0082] d) After the data recovery job is successfully executed, the status will change to "success";

[0083] e) If it is a single node, there is no "cluster building in progress" status; only cluster instances (when restored to multiple nodes) have this status.

[0084] As attached Figure 2 As shown, the logical backup and recovery process for single-node and cluster databases, as well as the physical backup and recovery process for single-node databases, are detailed below:

[0085] (1) Restore media reception recovery request;

[0086] (2) Restore media calls Kubernetes to create recovery data CR;

[0087] (3) Create recovery data (CR) in Kubernetes;

[0088] (4) Recover media listen for recovery data CR creation event;

[0089] (5) The recovery media creates a recovery data task job and updates the recovery data CR status to "Recovering";

[0090] (6) Kubernetes executes the data recovery job;

[0091] (7) The recovery media determines whether the recovery task is successful by monitoring the Kubernetes recovery task Job;

[0092] (8) The recovery media updates the recovery data CR status to "Recovery Successful" or "Recovery Failed" based on the recovery task Job results;

[0093] The specific process for physical backup and recovery of the cluster database is as follows:

[0094] (1) Restore media reception recovery request;

[0095] (2) Restore media calls Kubernetes to create recovery data CR;

[0096] (3) Create recovery data (CR) in Kubernetes;

[0097] (4) Recover media listen for recovery data CR creation event;

[0098] (5) The recovery media creates a recovery data task job and updates the recovery data CR status to "Recovering";

[0099] (6) Kubernetes executes the data recovery job;

[0100] (7) The recovery media determines whether the recovery task is successful by monitoring the Kubernetes recovery task Job;

[0101] (8) The recovery media updates the recovery data CR status to "Cluster building in progress" or "Recovery failed" based on the recovery task Job result. If the recovery task Job is successfully executed, proceed to step (9).

[0102] (9) The recovery media uses the database node information defined in the recovery data CR to call Kubernetes to create and build a database cluster Job;

[0103] (10) Kubernetes executes the job to build a database cluster;

[0104] (11) The recovery media uses the Kubernetes database cluster job to monitor whether the task is successful;

[0105] (12) The recovery media updates the recovery data CR status to "Recovery Successful" or "Recovery Failed" based on the results of the database cluster Job.

[0106] Example 3:

[0107] This embodiment also provides an electronic device, including: a memory and at least one processor;

[0108] The memory stores computer-executed instructions;

[0109] The at least one processor executes the computer execution instructions stored in the memory, causing the at least one processor to execute the cloud-native database recovery method based on hybrid cloud according to any one of the present invention.

[0110] The processor can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), off-the-shelf programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The processor can be a microprocessor or any conventional processor.

[0111] Memory is used to store computer programs and / or modules. The processor implements various functions of the electronic device by running or executing the computer programs and / or modules stored in the memory, and by accessing data stored in the memory. Memory can mainly include a program storage area and a data storage area. The program storage area can store the operating system, at least one application program required for a function, etc.; the data storage area can store data created based on the use of the terminal, etc. In addition, memory can also include high-speed random access memory, and can also include non-volatile memory, such as hard disks, RAM, plug-in hard disks, smart memory cards (SMC), secure digital cards (SD cards), flash memory cards, at least one disk storage device, flash memory devices, or other volatile solid-state storage devices.

[0112] Example 4:

[0113] This embodiment also provides a computer-readable storage medium storing multiple instructions, which are loaded by a processor to cause the processor to execute the cloud-native database recovery method based on hybrid cloud in any embodiment of the present invention. Specifically, a system or apparatus equipped with a storage medium may be provided, on which software program code implementing the functions of any of the above embodiments is stored, and the computer (or CPU or MPU) of the system or apparatus can read and execute the program code stored in the storage medium.

[0114] In this case, the program code read from the storage medium can itself implement the function of any of the above embodiments, and therefore the program code and the storage medium storing the program code constitute part of the present invention.

[0115] Examples of storage media used to provide program code include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD+RW), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, program code can be downloaded from a server computer via a communication network.

[0116] Furthermore, it should be clear that not only can the program code read by the computer be executed, but also the operating system or other components operating on the computer can be instructed based on the program code to perform some or all of the actual operations, thereby realizing the function of any of the embodiments described above.

[0117] Furthermore, it is understood that the program code read from the storage medium is written to the memory set in the expansion board inserted into the computer or to the memory set in the expansion unit connected to the computer. Then, based on the instructions of the program code, the CPU or other components installed on the expansion board or expansion unit execute some and all of the actual operations, thereby realizing the function of any of the embodiments described above.

[0118] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A cloud-native database recovery method based on hybrid cloud, characterized in that, The method is as follows: Monitor Kubernetes custom resource events in real time using recovery media deployed as an application in a Kubernetes cluster; By restoring media listeners, custom Kubernetes resource events are created, and the necessary Kubernetes Job resources for recovery are created to achieve data recovery. The Kubernetes Job resources for recovery include recovery tasks and master-slave setup tasks. By monitoring backup Kubernetes Job resource events through the recovery media, it can determine whether the recovery job and the master-slave job setup were successful, and update the information to the Kubernetes custom resource based on the task status and execution results. The recovery media supports the recovery of two types of data files: logical database backups and full physical backups. The recovery media and Kubernetes rely on custom resources to pass user request information. The definition of the custom recovery resource is completed during the initialization of the recovery media. The recovery media provides RESTful API interfaces for users, including interfaces for initiating recovery requests, viewing recovery task history, viewing current recovery tasks, and suspending or deleting recovery tasks. The API interfaces provided by the recovery media are for viewing recovery CR status information, which is achieved by calling Kubernetes commands. In logical database backup, the database recovery file is imported from an external object storage. The recovery media supports both Swift and S3 protocols for users to choose from. In data recovery CR, the location of the backup in object storage is defined, including the domain name, bucket, file name, and the database node to be restored. The specific steps for restoring a full physical backup are as follows: The user calls the interface provided by the recovery medium to initiate a recovery request; The recovery medium generates a recovery request for custom resources based on the parameters passed by the user, and calls Kubernetes to create the custom resources; Upon receiving the request, Kubernetes creates the custom resource to be restored and generates a restore custom resource creation event. After the recovery media detects a custom resource creation event for a recovery request, it calls Kubernetes to update the custom resource status to "Recovery task starting"; at the same time, the recovery media calls Kubernetes to create a recovery task (Job). When the recovery media detects that the recovery task Job has been successfully created, it updates the custom resource status to "Recovery task in progress" and waits for the result of the recovery task Job execution. After a Kubernetes recovery job is created, resources are allocated according to the job configuration. Once the job's workload Pods are successfully created, database recovery operations are performed. If the backup is restored to a database cluster, the recovery job covers the recovery of all database nodes. When a recovery task is executed successfully, Kubernetes generates a "Job Successful Execution" event, which is detected by the recovery media. The recovery media then adjusts the status of the recovery custom resource to "Recovery Task Successful Execution". Conversely, if the recovery task job is not successfully created or if the recovery process encounters an error, the recovery task job will fail. The recovery media will update the recovery custom resource with the specific reason for the failure and update the status to "Recovery Task Failed Execution". In the event that a recovery task (Job) fails to execute, the specific method for tracing the failure reason using recovery media is as follows: ① Listen for the Job event in the recovery task; ② Monitor the job load events and execution logs for recovery tasks; The recovery media ensures the integrity of custom resource information in the recovery request and presents the information completely to the user; the recovery media listens for event messages when a recovery task fails and filters the information based on the information in the recovery task event. If the failure reason is present in the Job event message of the recovery task, then update the failure reason in the recovery request CR resource. If the failure reason is not clearly stated in the Job event message of the recovery task, the recovery medium will listen to the Pod resource event to obtain the event information generated by the Pod resource and make a reasonable judgment to confirm the failure reason. The recovery media enables data recovery for single-node and cluster databases based on full physical backups. When a user requests the recovery of multiple database nodes, the recovery media assumes that the database nodes provided by the user are in a cluster. The recovery media performs backup and recovery and sets up master-slave replication. The master node in the cluster is selected by default from the first database node provided by the user; otherwise, the specified master-slave replication is used. The cluster recovery and setup procedures are as follows: The cluster is built after each database node has been restored. When the recovery media hears a message that the recovery task has been successfully executed, the recovery media changes the custom resource status to "cluster building in progress" and calls Kubernetes to create and build the cluster job. The metadata information for cluster setup jobs is generated based on user request data. When setting up a cluster, the recovery media automatically parses the node backup files to obtain the necessary data information for cluster setup. When the recovery media listener receives a completion message for the cluster setup job, it calls Kubernetes to update the status of the custom resource to "Recovery successful", thus completing the recovery and cluster setup.

2. An electronic device, characterized in that, include: Memory and at least one processor; The memory stores computer-executed instructions; The at least one processor executes the computer execution instructions stored in the memory, causing the at least one processor to perform the cloud-native database recovery method based on hybrid cloud as described in claim 1.

3. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by the processor, implement the cloud-native database recovery method based on hybrid cloud as described in claim 1.

Images