Disaster recovery system deployment method of offsite dual-active cluster and disaster recovery system of offsite dual-active cluster

Abstract

The application discloses a method for deploying a cross-site dual-active cluster disaster recovery system and the cross-site dual-active cluster disaster recovery system, and comprises the following steps: building a master database cluster and a backup database cluster in different geographical positions, wherein the master database cluster and the backup database cluster are both based on a multi-master architecture; configuring an external port for a first database instance, wherein the first database instance is a database instance in the master database cluster; selecting the first database instance corresponding to each second database instance as a synchronous data source, and configuring the external port of the first database instance corresponding to the second database instance to the second database instance, so as to synchronize data from the first database instance to the second database instance based on the external port, wherein the second database instance is a database instance in the backup database cluster. In this way, the write performance can be expanded while avoiding the problem of high network delay.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data disaster recovery, in particular to a method for deploying a disaster recovery system of a remote active-active cluster and the disaster recovery system of the remote active-active cluster. BACKGROUND

[0002] In order to safely store massive data and ensure stable operation of a system, an active-active disaster recovery cluster needs to be deployed to ensure that a database provides read and write services in multiple data centers at different geographical locations at the same time, and when a failure occurs in any data center, other data centers can seamlessly take over the services.

[0003] However, the traditional database cluster deployment scheme uses a master-slave architecture. Since the master-slave architecture can only have one master node to handle write operations, the write data performance of the cluster cannot be improved by increasing the number of cluster nodes but only by improving the hardware configuration, and the write performance expansion has bottlenecks. The database cluster deployed using a multi-master architecture allows multiple master nodes to handle read and write operations, which can solve the write performance expansion problem involved in the traditional master-slave database cluster scheme. However, for data synchronization between active-active disaster recovery clusters, since the multi-master architecture uses real-time synchronization replication technology, it is difficult to ensure that the network delay across geographical locations meets the requirements of the disaster recovery scenario.

[0004] In summary, how to deploy an active-active disaster recovery cluster system while ensuring write performance expansion and avoiding high network delay is a problem to be solved. SUMMARY

[0005] Therefore, the purpose of the present application is to provide a method for deploying an active-active disaster recovery cluster system and the active-active disaster recovery cluster system, which can ensure write performance expansion while avoiding high network delay. The specific scheme is as follows:

[0006] In a first aspect, the present application discloses a method for deploying an active-active disaster recovery cluster system, comprising:

[0007] Building a master database cluster and a standby database cluster at different geographical locations, wherein the master database cluster and the standby database cluster are both based on a multi-master architecture;

[0008] Configuring an external port for a first database instance, wherein the first database instance is a database instance in the master database cluster;

[0009] The first database instance uniquely corresponding to each second database instance is selected as a synchronization data source, and the external port of the uniquely corresponding first database instance is configured for the second database instance, so as to synchronize data from the first database instance to the second database instance based on the external port, wherein the second database instance is a database instance in the standby database cluster.

[0010] Optionally, configuring an external port for the first database instance includes:

[0011] Obtaining the instance name of the first database instance;

[0012] Allocate a unique external port to the first database instance based on the instance name from a reserved port library;

[0013] The external port is configured for the first database instance to allow external traffic to access the first database instance through the external port.

[0014] Optionally, configuring the external port for the first database instance includes:

[0015] Modify the instance name and external port in a preset template file, wherein the preset template file is a template file for deploying a service that allows external traffic to access;

[0016] Execute the execution command corresponding to the preset template file to complete the deployment of the service allowing external traffic to access.

[0017] Optionally, the selecting the first database instance uniquely corresponding to each second database instance as the synchronization data source includes:

[0018] Obtain the instance name of the second database instance;

[0019] Based on the instance name of the second database instance and the instance name of the first database instance, a unique corresponding first database instance is matched for the second database instance as a synchronization data source.

[0020] Optionally, after selecting the first database instance uniquely corresponding to each second database instance as the synchronization data source, the method further includes:

[0021] Obtaining a file name and synchronization location information of a log corresponding to the first database instance, wherein the log is used to record data change operations of the first database instance;

[0022] The file name of the log and the synchronization location information are configured for the second database instance.

[0023] Optionally, establishing a primary database cluster and a standby database cluster in different geographical locations includes:

[0024] Based on the Kubernetes platform, master database clusters and standby database clusters in different geographical locations are built, wherein the master database clusters and standby database clusters adopt the Galera Cluser multi-master architecture.

[0025] In a second aspect, the present application discloses a remote active-active cluster disaster recovery system, comprising: a primary database cluster and a standby database cluster at different geographical locations, wherein both the primary database cluster and the standby database cluster are based on a multi-master architecture;

[0026] In addition, each second database instance has a unique corresponding first database instance as a synchronization data source, and data synchronization from the first database instance to the second database instance is performed based on the unique external port of the first database instance, wherein the first database instance is a database instance in the primary database cluster, and the second database instance is a database instance in the standby database cluster.

[0027] In a third aspect, the present application discloses a computer program product, which, when executed, implements the aforementioned remote active-active cluster disaster recovery system deployment method.

[0028] In a fourth aspect, the present application discloses an electronic device, including a memory and a processor, wherein:

[0029] The memory is used to store computer programs;

[0030] The processor is used to execute the computer program to implement the aforementioned remote active-active cluster disaster recovery system deployment method.

[0031] In a fifth aspect, the present application discloses a computer-readable storage medium for storing a computer program, wherein the computer program, when executed by a processor, implements the aforementioned remote active-active cluster disaster recovery system deployment method.

[0032] It can be known from the above scheme that the application provides a method for deploying a disaster recovery system of a geographically-distributed dual-active cluster, comprising: building a master database cluster and a backup database cluster in different geographical locations, wherein the master database cluster and the backup database cluster are both based on a multi-master architecture; configuring an external port for a first database instance, wherein the first database instance is a database instance in the master database cluster; selecting the first database instance corresponding to each second database instance as a synchronous data source, and configuring the external port of the first database instance corresponding to the second database instance, so as to synchronize data from the first database instance to the second database instance based on the external port, wherein the second database instance is a database instance in the backup database cluster.

[0033] It can be seen that the application has the following beneficial effects: in the geographically-distributed dual-active cluster based on the multi-master architecture, an external port is configured for each database instance in the master database cluster, and each database instance in the backup database cluster matches a database instance in the master database cluster corresponding thereto as a synchronous data source, so as to realize one-to-one correspondence between the database instances in the backup database cluster and the database instances in the master database cluster, and then realize data synchronization from each database instance in the master database cluster to the corresponding database instance in the backup database cluster through the external port of the database instance, thereby avoiding network delay caused by the use of real-time synchronization replication technology in the multi-master architecture, and being capable of guaranteeing write performance expansion while avoiding high network delay.

[0034] Correspondingly, the application also provides a geographically-distributed dual-active cluster disaster recovery system, an electronic device and a readable storage medium, which also have the above technical effects. BRIEF DESCRIPTION OF DRAWINGS

[0035] In order to more clearly illustrate the technical solutions in the embodiments of the application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or the prior art description. Obviously, the drawings in the following description only constitute the embodiments of the application, and for those skilled in the art, other drawings can also be obtained without creative labor on the basis of the provided drawings.

[0036] Figure 1 A flow chart of a method for deploying a geographically-distributed dual-active cluster disaster recovery system is provided for the embodiments of the application;

[0037] Figure 2 A schematic diagram of a geographically-distributed dual-active cluster disaster recovery system is provided for the embodiments of the application;

[0038] Figure 3 A flow chart of a method for deploying a geographically-distributed dual-active cluster disaster recovery system is provided for the embodiments of the application;

[0039] Figure 4 A flowchart of automatically creating a binlog synchronization port for a master cluster database instance provided in an embodiment of the present application;

[0040] Figure 5 A flow chart of an automatic configuration of a binlog slave replication mechanism for a standby cluster database instance provided in an embodiment of the present application;

[0041] Figure 6 A structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0042] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0043] First, the terms involved in the embodiments of this application are explained:

[0044] MySQL is an open-source relational database that uses a structured data storage format, with tables linked by foreign keys. It uses Structured Query Language (SQL) for database management and operations. Traditional MySQL clusters use a master-slave replication scheme to achieve data consistency across database nodes within the cluster. This scheme is a one-master, multiple-slave cluster architecture, where only one database node in the cluster serves as the master, while all other nodes act as slaves. The master node is responsible for database write operations, while slave nodes asynchronously replicate data to the master and provide read capabilities.

[0045] Galera Cluster is a synchronous multi-master replication solution for MySQL clusters. It ensures data consistency and high system availability across all nodes through data synchronization and distributed transaction processing between cluster nodes. Key features of the Galera Cluster solution include: synchronous replication, where data on all nodes is synchronized in real time to ensure consistency; a multi-master architecture, where each node acts as a master node, capable of handling read and write requests, providing high availability and concurrent processing capabilities; automatic horizontal node scaling, which supports the dynamic addition and removal of nodes, with new nodes automatically synchronizing data upon joining; data consistency, which uses the strong consistency model WSREP (Write Set Replication, a database replication technology) API (Application Programming Interface) to ensure transaction atomicity and consistency; and automatic fault recovery, where failed nodes are automatically removed from the cluster and automatically rejoin the cluster and synchronize data upon recovery.

[0046] Kubernetes is an open-source container orchestration engine platform that supports automated deployment, massive scalability, and containerized application management. It also features built-in load balancing policies and the ability to balance access to cluster nodes. The Kubernetes platform also integrates with persistent volume technologies like Longhorn, enabling database cluster instances deployed in a microservices-based environment to achieve persistent data storage by mounting persistent volumes.

[0047] NodePort is a concept related to Service in Kubernetes, which allows access to the Service through the IP address and specified port number of each node in the cluster.

[0048] Binlog (i.e. Binary Log, binary log file of MySQL database) records all operations that modify the database.

[0049] See also Figure 1 As shown, the embodiment of the present application discloses a remote active-active cluster disaster recovery system deployment method, including:

[0050] Step S11: Building a master database cluster and a standby database cluster in different geographical locations, wherein both the master database cluster and the standby database cluster are based on a multi-master architecture.

[0051] Both the primary and standby database clusters include multiple database instances. Pre-defined cluster deployment scripts can be used to establish primary and standby database clusters in different locations. Furthermore, the cluster names and the names of the included database instances of the primary and standby database clusters can be consistent, ensuring that database instances in the standby database cluster correspond one-to-one with database instances in the primary database cluster. To maximize cluster server performance, the number of cluster instances can be set to the same number of servers, so that database cluster instances are evenly distributed across all servers.

[0052] In an optional implementation, a master database cluster and a standby database cluster in different geographical locations may be built based on the Kubernetes platform, wherein the master database cluster and the standby database cluster adopt the Galera Cluser multi-master architecture.

[0053] Furthermore, the load balancing strategy in the Kubernetes platform may be selected as the load balancing strategy for the primary database cluster and the standby database cluster.

[0054] Step S12: configuring an external port for a first database instance, wherein the first database instance is a database instance in the primary database cluster.

[0055] In an optional implementation, the instance name of the first database instance can be obtained; a unique external port can be allocated to the first database instance from a reserved port library based on the instance name; and the external port can be configured for the first database instance to allow external traffic to access the first database instance through the external port. In this embodiment, when creating a database instance, the instance name can include sequence information, and the ports in the reserved port library can be arranged in sequence. When allocating external ports, the corresponding sequence of external ports can be obtained from the reserved port library based on the sequence information in the instance name.

[0056] Moreover, in an optional implementation, the instance name and external port in the preset template file can be modified, wherein the preset template file is a template file for deploying a service that allows external traffic to access the service; and the execution command corresponding to the preset template file is executed to complete the deployment of the service that allows external traffic to access the service.

[0057] Among them, the service allowing external traffic access can be understood as a software service with the function of allowing external traffic access. This embodiment can pre-create a deployment template file corresponding to the service allowing external traffic access, that is, a preset template file. By modifying the instance name and external port in the preset template file, and then executing the execution command corresponding to the preset template file, the deployment of the service allowing external traffic access can be completed. It can be understood that the instance name and external port are the instance name and external port of the first database instance of the service allowing external traffic access to be deployed.

[0058] Step S13: Select the first database instance uniquely corresponding to each second database instance as the synchronization data source, and configure the external port of the uniquely corresponding first database instance to the second database instance, so as to synchronize data from the first database instance to the second database instance based on the external port, wherein the second database instance is a database instance in the standby database cluster.

[0059] In an optional implementation, the instance name of the second database instance can be obtained; based on the instance name of the second database instance and the instance name of the first database instance, a uniquely corresponding first database instance can be matched for the second database instance as the synchronization data source. Specifically, the first database instance with the same instance name can be matched as the synchronization data source for the second database instance.

[0060] Furthermore, in this embodiment, the file name and synchronization location information of the log corresponding to the first database instance are obtained, wherein the log is used to record data change operations of the first database instance; the file name and the synchronization location information of the log are configured to the second database instance.

[0061] That is, in this embodiment, the log of the first database instance is synchronized to the second database instance, wherein the synchronization position information can be understood as the starting position to be synchronized in the log. The log can be a binlog log.

[0062] After configuring the log file name and synchronization location information for the second database instance, the second database instance can transmit the log file name and synchronization location information to the first database instance. When synchronization conditions are met, the first database instance synchronizes the log data to the second database instance based on the log file name and synchronization location information. The synchronization condition can be the completion of a transaction commit in the primary database cluster. For synchronizations after the first synchronization, the synchronization location information is the end location of the previous synchronization.

[0063] It can be seen that in the embodiment of the present application, in a remote active-active cluster based on a multi-master architecture, an external port is configured for each database instance in the primary database cluster, and each database instance in the standby database cluster matches a uniquely corresponding database instance in the primary database cluster as a synchronization data source, thereby achieving a one-to-one correspondence between the database instances in the standby database cluster and the database instances in the primary database cluster, and then realizing data synchronization from the database instance to the corresponding database instance in the standby database cluster through the external port of each database instance in the primary database cluster, thereby avoiding the network delay introduced by the real-time synchronous replication technology used in the multi-master architecture, and being able to avoid the problem of high network delay while ensuring write performance expansion.

[0064] With the rapid development of information technology, databases are playing an increasingly important role in various industries. Database systems have become core systems for storing and managing large amounts of business data. MySQL, with its high performance, open source nature, and low cost, has been widely used in the internet, finance, telecommunications, and other fields. However, with the increase in data volumes and the growing importance of business systems, database read and write performance, data consistency, high availability, and data security are becoming increasingly prominent. MySQL geo-active disaster recovery clusters are designed to ensure that database read and write services are provided simultaneously across multiple data centers in different locations, and if any data center fails, the remaining data centers can seamlessly take over. Traditional MySQL cluster deployments use native master-slave synchronization technology, a single-master, multiple-slave architecture, to synchronize data within the cluster. However, because this master-slave architecture can only handle write operations with a single master node, improving cluster write performance cannot be achieved by adding cluster nodes, but only by upgrading hardware configurations, resulting in write performance scalability bottlenecks. MySQL cluster deployments based on Galera Cluster utilize a multi-master architecture, allowing multiple master nodes to handle read and write operations, addressing the write performance scalability issues of traditional MySQL database clusters. However, the Galera Cluster solution does not provide load balancing technology and requires the use of third-party components to achieve load-balanced access to multiple master nodes, such as HAProxy (High Availability Proxy) and ProxySQL, which will increase the complexity of the system. In addition, existing cluster deployment solutions have relatively weak support for automated management of the entire database lifecycle, such as the automation of horizontal expansion, fault recovery, and monitoring capabilities of cluster nodes. On the other hand, current solutions for deploying MySQL clusters similar to the Galera Cluster approach do not have a mature and suitable solution for data synchronization between remote disaster recovery clusters. Solutions such as Galera Cluster basically use real-time synchronous replication technology, and data will be written to all nodes in the cluster at the same time when it is submitted. In disaster recovery scenarios, too many database nodes will greatly affect the database's write performance, and network latency across geographical locations will also greatly affect the success rate of data writing. Below, taking the MySQL remote active-active disaster recovery cluster in a cloud-native scenario as an example, the solution provided by this application is further explained:

[0065] Deploy two Galera Cluster multi-master MySQL database instance clusters based on the Kubernetes platform, one as the Master Cluster (i.e., the primary database cluster) and the other as the backup database cluster. Figure 2 As shown, Figure 2A schematic diagram of a remote active-active cluster disaster recovery system provided for an embodiment of the present application. The cluster can be managed through the API management service. NodePortService (i.e., node port service) is a service type in Kubernetes, which allows external clients to access services within the cluster through the IP address and static port of any node in the cluster. Load balancing can use the policies in the Kubernetes platform. The main database cluster and the backup database cluster are both instantiated with three database instances. In actual scenarios, the number of database instances can be increased or decreased, and the instance names are MySQL-0, MySQL-1, and MySQL-2 respectively. The cluster uses the synchronous replication mechanism of the Galera architecture to ensure the consistency of data of each data node. Each instance node of the backup cluster matches the instance node of the same name in the main cluster according to the instance name. Through the master-slave synchronization mechanism of the binlog log, one-to-one binding master-slave data synchronization of cluster nodes is realized to avoid the problem of binlog synchronization position confusion caused by random binding. It mainly includes the following steps:

[0066] Step 1: Prepare the environment for deployment. A Kubernetes cluster consists of two environments: a primary cluster and a backup cluster. Install the necessary tools and services, such as the Longhorn persistent volume storage service.

[0067] Step 2: Functional script development. Based on the Kubernetes platform, develop a functional script for deploying the MySQL cluster, creating a binlog synchronization port, and configuring binlog synchronization.

[0068] Step 3: Master / Slave Cluster Deployment. Execute the deployment script to deploy two identical MySQL database instance clusters based on the Galera Cluster multi-master architecture in the master and slave Kubernetes clusters, one for the master database cluster and the other for the slave database cluster.

[0069] Step 4: Enable the external access ports for the database instances in the primary database cluster. Execute the Create Service script to create an external access NodePort for each database instance in the primary database cluster.

[0070] Step 5: Configure binlog synchronization for the database instances in the standby database cluster. Execute the binlog configuration script to deliver the binlog file synchronization configuration for each database instance in the standby database cluster.

[0071] See also Figure 3 As shown, Figure 3This is a flow chart for deploying a remote active-active cluster disaster recovery system disclosed in an embodiment of this application. Prepare Kubernetes cluster environments in different geographical locations and install necessary tool services, such as Longhorn; develop scripts based on the Kubernetes platform, including MySQL cluster deployment scripts, binlog synchronization port creation scripts, and binlog configuration scripts; deploy a MySQL cluster in a remote Kubernetes cluster, where the cluster is based on the Galera Cluster multi-master architecture; select the NodePort port based on the MySQL cluster instance name to create a port for binlog master-slave synchronization for the primary cluster; configure the binlog slave node synchronization mechanism for each instance in the standby cluster based on the MySQL cluster instance name. The specific process is as follows:

[0072] Step 1: Build a Kubernetes platform cluster. To maximize business continuity, this example builds two identical Kubernetes clusters in two different geographic locations. Furthermore, database microservice deployments must consider persistent disk storage for data. Install the Longhorn service, and database microservice instances can achieve persistent data storage by mounting persistent volumes.

[0073] Step 2: Implement the deployment orchestration script for the MySQL geo-active cluster disaster recovery system on the Kubernetes platform. Based on object-oriented and scalable concepts, the orchestration deployment process can be split into three independent and decoupled functional scripts: the cluster deployment script, the binlog synchronization port configuration script, and the binlog synchronization configuration script.

[0074] Step 2.1: Cluster deployment script. First, based on the cluster's given name and auto-numbering rules, a unique instance name is generated for the cluster's database instance, and the Galera Cloud multi-master MySQL cluster is deployed on the Kubernetes platform. Second, the platform's built-in load balancing algorithm is selected to create a network service that allows external traffic to access the MySQL cluster.

[0075] Step 2.2: Binlog synchronization port setting script. Based on the cluster instance name, the algorithm automatically selects a unique matching reserved port and enables external traffic to directly access the network service of the named instance.

[0076] Step 2.3: Binlog synchronization configuration script. First, enable binlog synchronization for each instance in the active MySQL cluster and obtain the current log file and synchronization location for each instance. Second, configure a binlog synchronization data source for each instance in the standby cluster. The data source matching rule is for instances with the same name in the active cluster.

[0077] Step 3: Active / standby cluster deployment. For Kubernetes platform clusters in different locations, use the cluster deployment script implemented in Step 2 to specify the cluster name and number of instance replicas to build a geographically distributed MySQL geo-active cluster system.

[0078] In a MySQL geo-active cluster system, the cluster name and number of MySQL cluster instance replicas in the active and standby clusters must be consistent. This ensures that the standby cluster instance's binlog synchronization data source is mapped one-to-one to the active cluster instance. This prevents synchronization errors and halts caused by inconsistent synchronization log files and locations when multiple database instances share the same binlog synchronization data source. The number of cluster instance replicas can be the same as the number of Kubernetes cluster servers, ensuring that database cluster instances are evenly distributed across each server and fully utilizing the platform's cluster server performance.

[0079] Step 4: Create a service that allows external traffic to access the master cluster instance. Using the binlog synchronization port setting script implemented in Step 2, create a service that allows external traffic to access each MySQL instance in the master cluster. The service's exposed port is selected by an algorithm that matches a unique port in the reserved port library based on the instance name.

[0080] Step 4.1: Obtain the names of all instances in the active MySQL cluster. Use the command: kubectl get pods --no-headers -o custom-columns=NAME:.metadata.name -nmysql. kubectl is the command-line tool for the Kubernetes platform, and -nmysql is the name of the deployment space for the MySQL cluster.

[0081] Step 4.2: Obtain the service port that the MySQL cluster instance allows external traffic to access. The algorithm matches a unique port in the reserved port library based on the instance name as the exposed port for the instance that allows external traffic to access the service.

[0082] Step 4.3: Allow external traffic to access the service deployment for the MySQL cluster instance. Based on the MySQL cluster instance name and assigned port number, use the shell's sed command to modify the template file, binlog-nodeport-service.yaml, that allows external traffic to access the service deployment. Modify the exposed port number and the instance name bound to the service in the file. Execute the command: kubectl apply -f binlog-nodeport-service.yaml to complete the deployment of the MySQL instance on the Kubernetes platform, allowing external traffic to access the service.

[0083] See also Figure 4 As shown, Figure 4 This embodiment of the present application provides a flowchart for automatically creating a binlog synchronization port for a master cluster database instance. The command queries the MySQL cluster instance list, processes a database instance, matches the reserved NodePort port from the reserved port list based on the instance name, modifies the binlog-nodeport-service.yaml template file based on the reserved NodePort port matched by the instance name, creates the binlog synchronization port with the kubectl command, determines whether there are any unprocessed database instances, and loops through each database instance until all are processed.

[0084] Step 5: Configure the binlog slave replication mechanism for the standby cluster instance. Using the binlog synchronization configuration script implemented in Step 2, select the instance corresponding to the primary cluster as the data source based on the consistent instance name principle, and configure the binlog slave replication synchronization mechanism for the standby cluster instance.

[0085] Step 5.1: Obtain the names of all instances in the standby MySQL cluster. Use the command: kubectl get pods --no-headers -o custom-columns=NAME:.metadata.name -nmysql. kubectl is the command-line tool for the Kubernetes platform, and -nmysql is the name of the deployment space for the MySQL cluster.

[0086] Step 5.2: Obtain the binlog synchronization information of the MySQL standby cluster instance. Based on the standby cluster instance name, match the primary cluster instance as the binlog synchronization data source and execute the command: kubectl exec -it <pod-name>-nmysql --mysql -u <username> -p <password> -P <nodeport>-e "show master status;" obtains the current binlog file name and synchronization position information (binlog file name and synchronization position information of the master database instance).

[0087] in, <pod-name>The instance name of the database instance in the primary database cluster configured for binlog synchronization. <username>The database login user name for the database instance in the primary database cluster. <password>The database login password for the database instance in the primary database cluster. <nodeport>Allow external traffic to access the service port for the master node DB instance.

[0088] Step 5.3 Configure the MySQL standby cluster instance binlog slave replication synchronization mechanism. Execute the command: kubectl exec <pod-name>-nmysql -- change master to master_host='%s',master_port=%s,master_user='%s',master_password='%s',master_log_file='%s',master_log_pos=%s, to realize the backup cluster database instance binlog from the replication synchronization mechanism configuration.

[0089] wherein, <pod-name>is the MySQL database instance name, master_host is the access address of the master cluster database instance, master_port is the service port allowed by the master cluster database instance for external traffic access, master_user is the login user name of the master cluster database instance, master_log_file is the binlog log file name of the master cluster database instance, and master_log_pos is the starting position of the binlog slave replication, which must exist in the binlog log file of the master cluster database instance.

[0090] See also Figure 5 As shown, Figure 5 This is a flowchart for automatically configuring a binlog slave replication mechanism for a standby cluster database instance, as disclosed in an embodiment of the present application. The command queries the MySQL cluster instance list, processes a database instance, matches the master node information based on instance name consistency, obtains the binlog log file name, synchronization position offset (i.e., synchronization position information), and binlog synchronization port (i.e., external port), issues a binlog slave replication mechanism configuration command to the database instance, determines whether any database instances remain unprocessed, and loops through each database instance until all are processed.

[0091] This allows for the deployment of a cloud-native MySQL geo-active cluster disaster recovery system. Multiple nodes within the cluster are capable of handling data read and write operations. The architecture supports dynamic horizontal scaling of database nodes and automatic data synchronization for newly added nodes, resolving the write performance scaling bottleneck inherent in traditional MySQL cluster deployments, which typically require only a single master node. MySQL clusters are deployed on the Kubernetes platform, leveraging the Kubernetes platform to automate the lifecycle management of MySQL cluster microservice instances, including orchestration, load balancing access, and monitoring. First, the platform's inherent microservice orchestration and self-healing capabilities enable horizontal scaling and self-healing of the cluster. Second, the platform's native Istio service mesh technology, with its built-in multiple load balancing algorithms, enables load balancing access for cluster nodes. Finally, native monitoring tools, such as Prometheus, are integrated to seamlessly monitor the cluster across multiple dimensions. This addresses the lack of load balancing access capabilities and the low level of automation in full lifecycle management of MySQL clusters based on the Galera Cluster architecture. Furthermore, data synchronization is enabled between MySQL clusters deployed on the Kubernetes platform based on Galera Cluster technology in different locations. The deployment status of MySQL clusters in different locations is consistent, including the number of nodes and node names. Utilizing MySQL's binlog log file synchronization technology, instances in the standby cluster are bound to corresponding instances in the primary cluster by name, and their binlog synchronization data sources are configured. This solution addresses the issues of read and write performance impacted by joining the standby cluster to the primary cluster's Galera network, as well as synchronization speed impacted by the network. Furthermore, hot migration of application services is implemented to ensure business continuity.

[0092] Furthermore, an embodiment of the present application discloses a remote active-active cluster disaster recovery system, comprising: a primary database cluster and a standby database cluster at different geographical locations, wherein both the primary database cluster and the standby database cluster are based on a multi-master architecture;

[0093] In addition, each second database instance has a unique corresponding first database instance as a synchronization data source, and data synchronization from the first database instance to the second database instance is performed based on the unique external port of the first database instance, wherein the first database instance is a database instance in the primary database cluster, and the second database instance is a database instance in the standby database cluster.

[0094] Furthermore, an embodiment of the present application discloses a computer program product, which, when executed, implements the aforementioned remote active-active cluster disaster recovery system deployment method.

[0095] The specific process of the method for deploying the off-site dual-active cluster disaster recovery system can refer to the corresponding content disclosed in the foregoing embodiments, and details are not described herein.

[0096] Further, the embodiment discloses a device for deploying an off-site dual-active cluster disaster recovery system, comprising:

[0097] a cluster building module configured to build a master database cluster and a standby database cluster in different geographical locations, wherein the master database cluster and the standby database cluster are both based on a multi-master architecture;

[0098] a port configuration module configured to configure an external port for a first database instance, wherein the first database instance is a database instance in the master database cluster;

[0099] a data source matching module configured to select the first database instance uniquely corresponding to each second database instance as a synchronization data source, and configure the external port of the first database instance uniquely corresponding to the second database instance, so as to synchronize data from the first database instance to the second database instance based on the external port, wherein the second database instance is a database instance in the standby database cluster.

[0100] Referring to Figure 6 The embodiment of the present application discloses an electronic device 20 comprising a processor 21 and a memory 22; wherein the memory 22 is configured to save a computer program; the processor 21 is configured to execute the computer program, and the method for deploying an off-site dual-active cluster disaster recovery system disclosed in the foregoing embodiments.

[0101] The specific process of the method for deploying the off-site dual-active cluster disaster recovery system can refer to the corresponding content disclosed in the foregoing embodiments, and details are not described herein.

[0102] In addition, the memory 22 as a carrier for storing resources can be a read-only memory, a random access memory, a magnetic disk or an optical disk, and the storage mode can be temporary storage or permanent storage.

[0103] In addition, the electronic device 20 further comprises a power supply 23, a communication interface 24, an input / output interface 25 and a communication bus 26; wherein the power supply 23 is configured to provide working voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol followed by the communication interface 24 can be any communication protocol applicable to the technical solution of the present application, which is not limited herein; the input / output interface 25 is configured to obtain external input data or output data to the outside, and the specific interface type can be selected according to specific application needs, which is not limited herein.

[0104] Furthermore, an embodiment of the present application also discloses a computer-readable storage medium for storing a computer program, wherein when the computer program is executed by a processor, the method for deploying a remote active-active cluster disaster recovery system disclosed in the aforementioned embodiment is implemented.

[0105] For the specific process of the above-mentioned remote active-active cluster disaster recovery system deployment method, reference can be made to the corresponding content disclosed in the above-mentioned embodiments, and no further details will be given here.

[0106] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from the other embodiments. Reference can be made to the descriptions of the identical or similar parts between the various embodiments. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple, and the relevant parts can be referred to the descriptions of the methods.

[0107] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0108] The above is a detailed introduction to the remote active-active cluster disaster recovery system deployment method and the remote active-active cluster disaster recovery system provided by this application. This article uses specific examples to illustrate the principles and implementation methods of this application. The description of the above embodiments is only used to help understand the method of this application and its core ideas; at the same time, for general technical personnel in this field, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on this application. < / nodeport> < / password> < / username> < / nodeport> < / password> < / username>

Claims

1. A method for deploying a remote active-active cluster disaster recovery system, characterized in that: include: Building a master database cluster and a standby database cluster in different geographical locations, wherein both the master database cluster and the standby database cluster are based on a multi-master architecture; Configuring an external port for a first database instance, wherein the first database instance is a database instance in the primary database cluster; The first database instance uniquely corresponding to each second database instance is selected as a synchronization data source, and the external port of the uniquely corresponding first database instance is configured for the second database instance, so as to synchronize data from the first database instance to the second database instance based on the external port, wherein the second database instance is a database instance in the standby database cluster.

2. The remote active-active cluster disaster recovery system deployment method according to claim 1, characterized in that: Configuring an external port for the first database instance includes: Obtaining the instance name of the first database instance; Allocate a unique external port to the first database instance based on the instance name from a reserved port library; The external port is configured for the first database instance to allow external traffic to access the first database instance through the external port.

3. The remote active-active cluster disaster recovery system deployment method according to claim 2, characterized in that: Configuring the external port for the first database instance includes: Modify the instance name and external port in a preset template file, wherein the preset template file is a template file for deploying a service that allows external traffic to access; Execute the execution command corresponding to the preset template file to complete the deployment of the service allowing external traffic to access.

4. The remote active-active cluster disaster recovery system deployment method according to claim 1, characterized in that: The selecting the first database instance uniquely corresponding to each second database instance as the synchronization data source includes: Obtain the instance name of the second database instance; Based on the instance name of the second database instance and the instance name of the first database instance, a unique corresponding first database instance is matched for the second database instance as a synchronization data source.

5. The remote active-active cluster disaster recovery system deployment method according to claim 1, characterized in that: After selecting the first database instance uniquely corresponding to each second database instance as a synchronization data source, the method further includes: Obtaining a file name and synchronization location information of a log corresponding to the first database instance, wherein the log is used to record data change operations of the first database instance; The file name of the log and the synchronization location information are configured for the second database instance.

6. The remote active-active cluster disaster recovery system deployment method according to claim 1, characterized in that: The establishment of primary database clusters and standby database clusters in different geographical locations includes: Based on the Kubernetes platform, master database clusters and standby database clusters in different geographical locations are built, wherein the master database clusters and standby database clusters adopt the Galera Cluser multi-master architecture.

7. A remote active-active cluster disaster recovery system, characterized in that: include: A primary database cluster and a standby database cluster at different geographical locations, wherein both the primary database cluster and the standby database cluster are based on a multi-master architecture; Configuring an external port for a first database instance, wherein the first database instance is a database instance in the primary database cluster; The first database instance uniquely corresponding to each second database instance is selected as a synchronization data source, and the external port of the uniquely corresponding first database instance is configured for the second database instance, so as to synchronize data from the first database instance to the second database instance based on the external port, wherein the second database instance is a database instance in the standby database cluster.

8. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instruction is executed by a processor, the method for deploying a remote active-active cluster disaster recovery system according to any one of claims 1 to 6 is implemented.

9. An electronic device, characterized in that: comprising a memory and a processor, wherein: The memory is used to store computer programs; The processor is configured to execute the computer program to implement the remote active-active cluster disaster recovery system deployment method according to any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that Used to store a computer program, wherein when the computer program is executed by a processor, the remote active-active cluster disaster recovery system deployment method according to any one of claims 1 to 6 is implemented.

Images