Database remote disaster recovery method and device, electronic equipment and medium

Abstract

The invention relates to a database remote disaster recovery method and device, electronic equipment and a medium, and belongs to the technical field of databases. The method comprises the steps that in response to a main and standby database installation request of a target database, installation dependency resources are pulled from a preset resource pool, the preset resource pool comprises a container mirror image template, an optimization parameter script and a hardware information resource; based on the installation dependency resources, creating a main and standby database container service through an Operator controller, and converting creation information of the target database into K8S resource configuration information; and when determining that the main and standby database container services are ready, sending a preset script to a standby database cluster and a remote database cluster. According to the invention, data remote disaster recovery is realized based on a container technology and K8S, so that the efficiency of data remote disaster recovery is improved.

Description

Technical Field

[0001] The present invention relates to the field of database technology, and in particular to a method, device, electronic equipment and medium for off-site disaster recovery of a database. Background Art

[0002] Database systems play a vital role in the modern information society. To ensure the high availability of database systems, disaster recovery solutions are usually required so that database services can be quickly restored in the event of a catastrophic event.

[0003] Traditional database disaster recovery solutions usually rely on hardware redundancy and data mirroring technology. Hardware redundancy involves using backup hardware to replace the main hardware to ensure fast switching in the event of hardware failure. Data mirroring is the real-time replication of data between two locations to ensure data security and availability in the event of a disaster.

[0004] Traditional database disaster recovery solutions have some significant problems: 1) High network requirements: Traditional database disaster recovery usually requires high-speed, low-latency network connections between data centers; 2) Heavy burden on server resources: In traditional database disaster recovery solutions, multiple backup servers are usually required to quickly switch to the backup database in the event of a disaster. 3) Heavy deployment and operation and maintenance load: The setup of backup servers, configuration and monitoring of data synchronization, etc. all require professionals to complete, and as the size of the database increases, the workload will increase exponentially. 4) Difficult to switch quickly: In traditional database disaster recovery, failover usually requires manual intervention or time-consuming automation processes.

[0005] In summary, the prior art lacks a method for implementing off-site disaster recovery of databases based on containers and K8S, thereby improving the efficiency of off-site disaster recovery of databases. Summary of the invention

[0006] In view of this, it is necessary to provide a method, device, electronic device and medium for off-site disaster recovery of databases, so as to achieve the purpose of improving the efficiency of off-site disaster recovery of databases.

[0007] In order to achieve the above object, the present invention provides a method for off-site disaster recovery of a database, comprising: In response to the target database master and standby database installation request, pull the installation dependent resources from the preset resource pool, the preset resource pool includes: container image template, optimization parameter script and hardware information resources; Based on the installation dependent resources, a primary and secondary database container service is created through the Operator controller, and the creation information of the target database is converted into K8S resource configuration information; When it is determined that the primary and standby database container services are ready, a preset script is sent to the standby database cluster and the remote database cluster.

[0008] In a possible implementation, the preset script includes: The mal file of the target database, the arch archive configuration of the target database, and the backup file of the target database. In a possible implementation, the Operator controller sets a guide component in the container of the target database, and the guide component is used to determine the primary and standby database containers in sequence.

[0009] In a possible implementation, the boot component boots the cluster according to a configuration file specified by the Operator controller; When the database container corresponding to the configuration file is the main database, the Operator controller creates a backup file and publishes a backup download service based on the backup file; When the database container corresponding to the configuration file is a standby database, wait for the Operator controller to send backup download service status ready information and download the backup file.

[0010] In a possible implementation, the remote database cluster creates a kubevirt interface based on kubevirt virtualization technology, obtains the preset script through the kubevirt interface, and synchronizes the preset script to the remote database cluster.

[0011] In a possible implementation, the method further includes: A scheduled task is set for the target database on the cluster corresponding to the primary database container service to achieve scheduled transmission of data packets to the standby database cluster and the remote database cluster.

[0012] In a possible implementation, the method further includes: Load balancing is achieved in the primary and standby database cluster based on the Metallb load balancer.

[0013] On the other hand, the present invention also provides a device for off-site disaster recovery of a database, comprising: A data acquisition module is used to respond to the target database master and standby database installation request and pull installation dependent resources from a preset resource pool, wherein the preset resource pool includes: container image templates, optimization parameter scripts, and hardware information resources; A container creation module is used to create a primary and standby database container service through an Operator controller based on the installation dependency resources, and convert the creation information of the target database into K8S resource configuration information; The script sending module is used to send the preset script to the standby database cluster and the remote database cluster when it is determined that the primary and standby database container services are ready. On the other hand, the present invention also provides an electronic device, including a memory and a processor, wherein: The memory is used to store programs; The processor is coupled to the memory and is used to execute the program stored in the memory to implement the steps in the method for off-site disaster recovery of a database described in any one of the above implementations.

[0014] On the other hand, the present invention also provides a computer-readable storage medium for storing computer-readable programs or instructions, which, when executed by a processor, can implement the steps in a method for off-site disaster recovery of a database described in any of the above-mentioned implementations.

[0015] The beneficial effects of the present invention are as follows: a method for off-site disaster recovery of a database provided by the present invention first responds to the installation request of the target database master and standby databases, pulls installation dependent resources from a preset resource pool, and then creates a master and standby database container service through an Operator controller based on the installation dependent resources, and converts the creation information of the target database into K8S resource configuration information, and finally, when it is determined that the master and standby database container service is ready, sends the preset script to the standby database cluster and the off-site database cluster. Based on the Operator controller, the present invention realizes the full life cycle automated management of database instances, sends the preset script to the standby database cluster and the off-site database cluster at the same time, realizes off-site disaster recovery of the database, and thus improves the efficiency of off-site disaster recovery of the database as a whole. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 A structural method flow chart of an embodiment of a method for off-site disaster recovery of a database provided by the present invention; Figure 2 A schematic diagram of data interaction between center A and center B in an embodiment of a method for off-site disaster recovery of a database provided by the present invention; Figure 3 A schematic diagram of the structure of an embodiment of a database off-site disaster recovery device provided by the present invention; Figure 4 A schematic structural diagram of an embodiment of an electronic device provided by the present invention. DETAILED DESCRIPTION

[0017] The preferred embodiments of the present invention are described in detail below in conjunction with the accompanying drawings, wherein the accompanying drawings constitute a part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not used to limit the scope of the present invention.

[0018] Before presenting the embodiments, the following terms are explained.

[0019] Kubernetes is an open source container-based cluster management platform. The goal of Kubernetes is to make the deployment of containerized applications simple and efficient, and to provide a mechanism for application deployment, planning, updating, and maintenance, referred to as K8S.

[0020] The present invention provides a method, device, electronic equipment and medium for off-site disaster recovery of a database, which are described below respectively.

[0021] Figure 1 A schematic diagram of an embodiment of a method for off-site disaster recovery of a database provided by the present invention is shown in FIG. Figure 1 As shown, the method for off-site disaster recovery of a database includes: S101, responding to the target database master and standby database installation request, pulling installation dependent resources from a preset resource pool, the preset resource pool including: container image templates, optimization parameter scripts, and hardware information resources; S102: Create a primary and standby database container service through the Operator controller based on the installation dependent resources, and convert the creation information of the target database into K8S resource configuration information; S103: When it is determined that the primary and standby database container services are ready, a preset script is sent to the standby database cluster and the remote database cluster.

[0022] Compared with the prior art, the present embodiment provides a method for off-site disaster recovery of a database. First, it responds to the installation request of the target database master and standby database, pulls the installation dependent resources from the preset resource pool, and then creates the master and standby database container service through the Operator controller based on the installation dependent resources, and converts the creation information of the target database into K8S resource configuration information. Finally, when it is determined that the master and standby database container service is ready, the preset script is sent to the standby database cluster and the off-site database cluster. Based on the Operator controller, the present invention realizes the full life cycle automated management of the database instance, sends the preset script to the standby database cluster and the off-site database cluster at the same time, realizes off-site disaster recovery of the database, and thus improves the efficiency of off-site disaster recovery of the database as a whole.

[0023] In some embodiments of the present invention, the preset script includes: The mal file of the target database, the arch archive configuration of the target database, and the backup file of the target database.

[0024] In some embodiments of the present invention, the Operator controller sets a guide component in the container of the target database, and the guide component is used to determine the primary and standby database containers in sequence.

[0025] In some embodiments of the present invention, the boot component performs cluster booting according to a configuration file specified by the Operator controller; When the database container corresponding to the configuration file is the main database, the Operator controller creates a backup file and publishes a backup download service based on the backup file; When the database container corresponding to the configuration file is a standby database, wait for the Operator controller to send backup download service status ready information and download the backup file.

[0026] In a specific embodiment of the present invention, Figure 2 The figure shows the data interaction diagram between Center A and Center B, involving two data centers, namely the local Center A and the remote Center B (referred to as Center A and Center B), which contain three database instances. The main service DAMO database and the backup service DAMO database (referred to as the main database and backup database) are deployed in Center A, and the asynchronous backup service database (referred to as the asynchronous backup database) is deployed in Center B. The use of containerization technology and virtualization can reduce the occupation of physical resources. Centers A and B can deploy multiple sets of remote disaster recovery database clusters. The asynchronous backup database under virtualization is more convenient for operation and maintenance personnel to recover after a disaster. The specific implementation steps are as follows: In Center A, kubernetes operator controller technology is introduced to implement DAMO R&D DAMO resource controller to precisely manage DAMO database custom resources; A database cluster boot component is implanted in the DAMO database image. This component mainly implements the automatic role allocation of DAMO database nodes in the master-slave cluster mode. The database container sorting is determined according to the number of replicas described in the yaml file. The first ranked data is the primary database, and the other one is the backup database. According to the configuration file specified by the core controller, the cluster is booted and precise idempotent configuration is implemented for the database sub-node members. When it is the main database, it creates its own backup file and publishes the backup download service to the outside world. After the backup database is started, it learns through the boot file that it is not the main database, and waits for the backup download service in the cluster to be ready. After checking that the backup download service is ready, it actively downloads the backup file and restores its own database. After restoration, it guides the component to execute SQL statements, marks its own database role, and waits until the cluster data is synchronized. The DM resource controller receives the configuration file in yaml format, which describes the image version, cpu, memory, storage size, cluster type, number of replicas and other information used by the DM database. The DM resource controller converts this information into resource configurations such as statefulset, configmap, secret, service, PersistentVolumeClaim that can be recognized by the kubernetes cluster, realizes the scheduling and deployment of the DM database based on the kubernetes cluster, and completes the deployment of the master-slave database cluster in Center A.

[0027] In some embodiments of the present invention, the remote database cluster creates a kubevirt interface based on kubevirt virtualization technology, obtains the preset script through the kubevirt interface, and synchronizes the preset script to the remote database cluster.

[0028] In a specific embodiment of the present invention, kubevirt virtualization technology is introduced in center B, and a virtual machine environment required for an asynchronous standby machine is created through the kubevirt interface call method. The deployment script written in ansible is used to remotely and automatically deploy the virtual machine on center B, realize automatic mounting of ISO, automatic configuration of database, and automatic management of database services. The database configuration is automatically obtained through the boot component interface configured on center A, and the binary configuration files such as mal configuration and arch archive configuration necessary for database synchronization are encrypted and converted into strings using Base64, and converted into files in the virtual machine after transmission, so as to ensure that the configuration files of the two remote centers are consistent. Metallb load balancing technology is introduced, and L2 mode is used to fix the IP addresses of the primary and standby databases, and the database service is converted into a two-layer network mode to realize communication of the configuration of center B, and the timer timing task of the DAMO database is automatically configured to realize timed data packet compression transmission, realize asynchronous directional database synchronization, and reduce the network pressure caused by real-time transmission.

[0029] In some embodiments of the present invention, it further includes: A scheduled task is set for the target database on the cluster corresponding to the primary database container service to achieve scheduled transmission of data packets to the standby database cluster and the remote database cluster.

[0030] In some embodiments of the present invention, it further includes: Load balancing is achieved in the primary and standby database cluster based on the Metallb load balancer.

[0031] Data centers A and B both use the kubernetes cluster as the underlying scheduling platform. Both centers can use the high availability features of the kubernetes platform. When a node in the data center is abnormally disconnected, with the support of container technology and virtualization technology, the database instance can be automatically drifted and switched in clusters A and B respectively. At the same time, since cluster A is the primary and standby cluster database, when the primary database goes down, the standby database can automatically take over. When the entire center of data center A is catastrophically damaged or there is a power outage, the asynchronous standby database of center B can automatically take over the service.

[0032] In order to better implement a database off-site disaster recovery method in an embodiment of the present invention, based on a database off-site disaster recovery method, correspondingly, Figure 3 As shown, an embodiment of the present invention further provides a device for off-site disaster recovery of a database. The device 300 for off-site disaster recovery of a database includes: The data acquisition module 301 is used to respond to the target database master and standby database installation request and pull installation dependent resources from a preset resource pool, wherein the preset resource pool includes: container image templates, optimization parameter scripts, and hardware information resources; The container creation module 302 is used to create a primary and standby database container service through the Operator controller based on the installation dependency resources, and convert the creation information of the target database into K8S resource configuration information; The script sending module 303 is used to send the preset script to the standby database cluster and the remote database cluster when it is determined that the primary and standby database container services are ready.

[0033] The device 300 for off-site disaster recovery of a database provided in the above embodiment can implement the technical solution described in the above embodiment of a method for off-site disaster recovery of a database. The specific implementation principles of the above modules or units can refer to the corresponding contents in the above embodiment of a method for off-site disaster recovery of a database, which will not be repeated here.

[0034] like Figure 4 As shown, the present invention also provides an electronic device 400. The electronic device 400 includes a processor 401, a memory 402 and a display 403. Figure 4Only some components of the electronic device 400 are shown, but it should be understood that it is not required to implement all of the components shown, and more or fewer components may be implemented instead.

[0035] In some embodiments, the processor 401 may be a central processing unit (CPU), a microprocessor or other data processing chip, used to run program codes or process data stored in the memory 302, such as a database off-site disaster recovery method in the present invention.

[0036] In some embodiments, processor 401 may be a single server or a server group. The server group may be centralized or distributed. In some embodiments, processor 401 may be local or remote. In some embodiments, processor 401 may be implemented in a cloud platform. In some embodiments, the cloud platform may include a private cloud, a public cloud, a hybrid cloud, a community cloud, a distributed cloud, an internal cloud, a multi-cloud, etc., or any combination thereof.

[0037] In some embodiments, the memory 402 may be an internal storage unit of the electronic device 400, such as a hard disk or memory of the electronic device 400. In other embodiments, the memory 402 may also be an external storage device of the electronic device 400, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc., equipped on the electronic device 400.

[0038] Furthermore, the memory 402 may include both an internal storage unit of the electronic device 400 and an external storage device. The memory 402 is used to store application software installed in the electronic device 400 and various data.

[0039] In some embodiments, the display 403 may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, an OLED (Organic Light-Emitting Diode) touch device, etc. The display 403 is used to display information on the electronic device 400 and to display a visual user interface. The components 401-403 of the electronic device 400 communicate with each other via a system bus.

[0040] In one embodiment, when the processor 401 executes a database off-site disaster recovery program in the memory 402, the following steps may be implemented: In response to the target database master and standby database installation request, the installation dependent resources are pulled from the preset resource pool, where the preset resource pool includes: container image templates, optimization parameter scripts, and hardware information resources; Based on the installation dependent resources, a primary and secondary database container service is created through the Operator controller, and the creation information of the target database is converted into K8S resource configuration information; When it is determined that the primary and standby database container services are ready, a preset script is sent to the standby database cluster and the remote database cluster.

[0041] It should be understood that: when the processor 401 executes a database off-site disaster recovery program in the memory 402, in addition to the above functions, other functions can also be implemented. For details, please refer to the description of the corresponding method embodiment above.

[0042] Furthermore, the embodiment of the present invention does not specifically limit the type of the electronic device 400 mentioned, and the electronic device 400 may be a portable electronic device such as a mobile phone, a tablet computer, a personal digital assistant (PDA), a wearable device, a laptop computer, etc. Exemplary embodiments of portable electronic devices include but are not limited to portable electronic devices equipped with IOS, Android, Microsoft or other operating systems. The above-mentioned portable electronic devices may also be other portable electronic devices, such as a laptop computer with a touch-sensitive surface (e.g., a touch panel). It should also be understood that in some other embodiments of the present invention, the electronic device 400 may not be a portable electronic device, but a desktop computer with a touch-sensitive surface (e.g., a touch panel).

[0043] Those skilled in the art will appreciate that all or part of the processes of the above-mentioned embodiments can be implemented by instructing related hardware through a computer program, and the program can be stored in a computer-readable storage medium, wherein the computer-readable storage medium is a disk, an optical disk, a read-only storage memory, or a random access memory, etc.

[0044] The above description is only a preferred specific implementation manner of the present invention, but the protection scope of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by any technician familiar with the technical field within the technical scope disclosed by the present invention should be covered within the protection scope of the present invention.

Claims

1. A method for off-site disaster recovery of a database, characterized in that: include: In response to the target database master and standby database installation request, the installation dependent resources are pulled from the preset resource pool, where the preset resource pool includes: container image templates, optimization parameter scripts, and hardware information resources; Based on the installation dependent resources, a primary and secondary database container service is created through the Operator controller, and the creation information of the target database is converted into K8S resource configuration information; When it is determined that the primary and standby database container services are ready, a preset script is sent to the standby database cluster and the remote database cluster.

2. The method for off-site disaster recovery of a database according to claim 1, characterized in that: The preset script includes: The mal file of the target database, the arch archive configuration of the target database, and the backup file of the target database.

3. The method for off-site disaster recovery of a database according to claim 1, characterized in that: The Operator controller sets a guide component in the container of the target database, and the guide component is used to determine the primary and standby database containers in sequence.

4. The method for off-site disaster recovery of a database according to claim 1, characterized in that: The boot component boots the cluster according to the configuration file specified by the Operator controller; When the database container corresponding to the configuration file is the main database, the Operator controller creates a backup file and publishes a backup download service based on the backup file; When the database container corresponding to the configuration file is a standby database, wait for the Operator controller to send backup download service status ready information and download the backup file.

5. The method for off-site disaster recovery of a database according to claim 1, characterized in that: The remote database cluster creates a kubevirt interface based on the kubevirt virtualization technology, obtains the preset script through the kubevirt interface, and synchronizes the preset script to the remote database cluster.

6. The method for off-site disaster recovery of a database according to claim 1, characterized in that: Also includes: A scheduled task is set for the target database on the cluster corresponding to the primary database container service to achieve scheduled transmission of data packets to the standby database cluster and the remote database cluster.

7. The method for off-site disaster recovery of a database according to claim 1, characterized in that: Also includes: Load balancing is achieved in the primary and standby database cluster based on the Metallb load balancer.

8. A device for off-site disaster recovery of a database, characterized in that: include: A data acquisition module is used to respond to the target database master and standby database installation request and pull installation dependent resources from a preset resource pool, wherein the preset resource pool includes: container image templates, optimization parameter scripts, and hardware information resources; A container creation module is used to create a primary and standby database container service through an Operator controller based on the installation dependency resources, and convert the creation information of the target database into K8S resource configuration information; The script sending module is used to send the preset script to the standby database cluster and the remote database cluster when it is determined that the primary and standby database container services are ready.

9. An electronic device, characterized in that: comprising a memory and a processor, wherein: The memory is used to store programs; The processor is coupled to the memory and is used to execute the program stored in the memory to implement the steps in the method for off-site disaster recovery of a database as described in any one of claims 1 to 7 above.

10. A computer-readable storage medium, characterized in that: Used to store computer-readable programs or instructions, which, when executed by a processor, can implement the steps in the method for off-site disaster recovery of a database as described in any one of claims 1 to 7 above.

Images