Database redundancy method, apparatus and electronic device

Abstract

The application belongs to the technical field of database, and particularly relates to a database redundancy method, device and electronic equipment, which comprises the following steps: installing cluster components in four servers of a to-be-clustered database, wherein the cluster components comprise keepalived components and NDB Cluster; dividing the four servers into two groups; performing master-backup redundancy configuration on the servers in each group; and determining two servers completing the master-backup redundancy configuration as a database cluster, so as to realize high redundancy and high reliability of data synchronization in the cluster; performing ring-shaped master-backup redundancy configuration on the four servers of the cluster, so as to form redundancy between database clusters, realize high redundancy and high reliability of data synchronization between clusters, and solve the problem that the existing redundancy scheme using a MySQL database cannot realize the function of master-backup offsite disaster recovery between data centers.

Description

Technical Field

[0001] This invention belongs to the field of database technology, specifically relating to a database redundancy method, apparatus, and electronic device. Background Technology

[0002] With the development of mobile network technology, 5G network communication technology is increasingly being used in our lives due to its outstanding advantages such as high transmission speed and high stability. The 5GC core network element UDR (Unified Data Repository) supports UDM storage and retrieval of subscribed data, and is considered the operator's data center. Operators require data redundancy and high reliability within their data centers. As operator businesses expand and the number of core network devices increases, the need for off-site disaster recovery for data centers arises. For redundancy solutions in small and medium-sized core networks, MySQL databases can be used. Currently, the mainstream solutions for redundancy using MySQL databases include: 1. Two servers, with MySQL using master-master replication, acting as mutual backup; 2. Multiple servers, with MySQL using master-slave replication, where data written to the master is automatically synchronized to the slave (the slave follows the master); 3. A MySQL cluster using MySQL Group Replication (MGR) in a single-master mode, with at least three servers in the cluster environment allowing the MySQL Router and MySQL servers to coexist. The MySQL cluster selects the master node through a voting mechanism. However, none of the above-mentioned solutions using MySQL databases for redundancy can achieve the function of primary and backup disaster recovery between data centers. Summary of the Invention

[0003] In view of this, the purpose of the present invention is to provide a database redundancy method, apparatus and electronic device to solve the problem that the existing schemes using MySQL database for redundancy cannot achieve the function of primary and backup disaster recovery between data centers.

[0004] According to a first aspect of the present invention, a database redundancy method is provided, comprising:

[0005] Install cluster components on the four servers where the database is located, including keepalived and NDB Cluster.

[0006] The four servers with cluster components installed are divided into two groups. The servers in each group are configured with primary and backup redundancy. The two servers that have completed the primary and backup redundancy configuration are defined as a database cluster.

[0007] The four servers behind the cluster are configured with ring primary-backup redundancy to form redundancy between database clusters. This includes: if a server in any cluster is determined to be the primary server of a server in another cluster, the other server in that cluster is determined to be the backup server of the remaining server in the other cluster.

[0008] Preferably, the four servers include: a first server, a second server, a third server, and a fourth server. If the first server and the second server are configured as a first database cluster, and the third server and the fourth server are configured as a second database cluster, the step of configuring primary and backup redundancy for the servers in each group includes:

[0009] Configure primary and backup redundancy for the first and second servers according to the preset configuration steps.

[0010] Based on the configuration steps of the first and second servers, the third and fourth servers are configured with primary and backup redundancy.

[0011] Preferably, the step of configuring the first server and the second server with primary and backup redundancy according to the preset configuration steps includes: installing keepalived on the first server and the second server;

[0012] Modify the keepalived configuration file keepalived.conf on the first and second servers, configure the local address and floating address, and start keepalived; the server configured with the floating address is the primary server.

[0013] Deploy an NDB Cluster on the first and second servers;

[0014] Start the relevant NDB Cluster processes on the first server and the second server in sequence;

[0015] If the first server is the primary server and the second server is the backup server, after the keepalived monitoring of the first server detects an abnormal process of the NDB Cluster, the floating address will be switched to the second server.

[0016] Preferably, deploying the NDB Cluster on the first server and the second server includes:

[0017] Install MySQL Cluster on the first and second servers;

[0018] Modify the config.ini configuration file for MySQL Cluster on both the first and second servers;

[0019] Modify the configuration file my.cnf for the first and second MySQL servers.

[0020] Preferably, the step of sequentially starting the relevant NDB Cluster processes on the first server and the second server includes:

[0021] Start the NDB management process, NDB data node, and MySQL API node on the first and second servers in sequence.

[0022] Preferably, if the first server is the primary server and the second server is the backup server, after the keepalived monitoring of the NDB Cluster detects a process abnormality, the floating address is switched to the second server, including:

[0023] Establish a connection between the database client and the MySQL API node in the NDB Cluster on the first server to access and manipulate data.

[0024] After the keepalived monitoring of the first server detects an abnormal process in the MySQL API node of the first server, the floating address is switched to the second server.

[0025] Preferably, the step of configuring the four servers behind the cluster with ring primary-backup redundancy to form redundancy between the database clusters includes:

[0026] Modify the MySQL API node parameters in the MySQL server configuration file my.cnf of each server in the first and second database clusters;

[0027] Configure the ring redundancy relationship between data nodes in the first and second database clusters.

[0028] Preferably, configuring the ring redundancy relationship of data nodes in the first and second database clusters includes:

[0029] A circular data redundancy relationship is determined among databases on different servers; wherein, the data node of the first server serves as the primary data node of the third server, and the data node of the fourth server serves as the primary data node of the second server;

[0030] Connect the MySQL API nodes of the third and second servers to configure the master-slave relationship between the servers in the cluster;

[0031] Connect the MySQL API nodes of the third and second servers to initiate the master-slave configuration between the cluster servers;

[0032] Connect to the MySQL API nodes of the third and second servers to check if master-slave replication between the clusters is effective.

[0033] According to a second aspect of the present invention, a database redundancy apparatus is provided, comprising:

[0034] The cluster configuration module is used to divide the four servers with cluster components installed into two groups, configure primary and standby redundancy for the servers in each group, and determine the two servers that have completed the primary and standby redundancy configuration as a database cluster.

[0035] The inter-cluster configuration module is used to configure the four servers behind the cluster in a ring-shaped primary-backup redundancy configuration to form redundancy between the database clusters. This includes: if a server in any cluster is determined to be the primary server of a server in another cluster, then another server in that cluster is determined to be the backup server of the remaining server in the other cluster.

[0036] According to a third aspect of the present invention, an electronic device is provided, comprising: the database redundancy device described above.

[0037] The technical solutions provided by the embodiments of the present invention may include the following beneficial effects:

[0038] By installing cluster components, including keepalived and NDB Cluster, on the four servers hosting the database in the cluster, the four servers are divided into two groups. Each group's servers are configured with primary / standby redundancy. The two servers with completed primary / standby redundancy are then designated as a database cluster, achieving high redundancy and high reliability of data synchronization within the cluster. A ring-shaped primary / standby redundancy configuration is then applied to the four servers behind the cluster, creating redundancy between the database clusters. If a server in one cluster is designated as the primary server for a server in another cluster, the other server in that cluster is designated as the standby server for the remaining server in the other cluster. This achieves high redundancy and high reliability of data synchronization between clusters, solving the problem that existing redundancy schemes using MySQL databases cannot achieve cross-regional disaster recovery between data centers.

[0039] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0040] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0041] Figure 1 This is a flowchart illustrating a database redundancy method according to an exemplary embodiment;

[0042] Figure 2 This is a schematic diagram of a network topology within a single cluster, according to an exemplary embodiment.

[0043] Figure 3A and Figure 3B This is a schematic diagram of a dual-cluster network according to an exemplary embodiment;

[0044] Figure 4 This is a schematic block diagram illustrating a database redundancy device according to an exemplary embodiment. Detailed Implementation

[0045] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the invention as detailed in the appended claims.

[0046] Please see Figure 1 , Figure 1 This is a flowchart illustrating a database redundancy method according to an exemplary embodiment, such as... Figure 1 As shown, the database redundancy method includes:

[0047] Step S11: Install cluster components on the four servers where the database is located, including keepalived and NDB Cluster.

[0048] Step S12: Divide the four servers with cluster components installed into two groups, configure primary and backup redundancy for the servers in each group, and determine the two servers that have completed the primary and backup redundancy configuration as a database cluster.

[0049] Step S13: Configure a ring primary-backup redundancy configuration for the four servers behind the cluster to form redundancy between database clusters, including: if a server in any cluster is determined to be the primary server of a server in another cluster, then the other server in that cluster is determined to be the backup server of the remaining server in the other cluster.

[0050] It should be noted that, in practice, the database redundancy method provided in this embodiment needs to be loaded and run in the controller of the electronic device.

[0051] The electronic devices include, but are not limited to: mobile phones, tablets, desktop computers, etc.

[0052] It is understood that the technical solution provided in this embodiment, by installing cluster components on the four servers to be clustered where the database resides, including keepalived components and NDB Cluster, divides the four servers with the cluster components into two groups, performs primary and backup redundancy configuration on the servers in each group, and determines the two servers that have completed the primary and backup redundancy configuration as a database cluster, thus achieving high redundancy and high reliability of data synchronization within the cluster; and performs ring primary and backup redundancy configuration on the four servers after the cluster to form redundancy between database clusters. Wherein, if a server in any cluster is determined to be the primary server of a server in another cluster, the other server in that cluster is determined to be the backup server of the remaining server in the other cluster, thus achieving high redundancy and high reliability of data synchronization between clusters, solving the problem that existing schemes using MySQL databases for redundancy cannot achieve the function of primary and backup disaster recovery between data centers.

[0053] In practice, the "cluster component" mentioned in step S11 is a general term for the tools used to configure database redundancy relationships in the embodiments of this invention. In this embodiment, the cluster component specifically includes keepalived and NDBCluster.

[0054] Keepalived is a software implementation based on the VRRP protocol, similar to a layer 3, 4 & 5 switching mechanism. When the main router or other gateway devices fail, another device takes over its work. VRRP enables automatic switching during network failures without affecting communication between user hosts. It operates automatically without manual intervention. Keepalived detects server status; if a web server goes down or malfunctions, it removes the faulty server from the system and replaces it with another server. Once the server is functioning normally again, Keepalived automatically adds it back to the server group. All of this is done automatically without manual intervention.

[0055] NDB Cluster is a highly practical and redundant version of a cluster of computers suitable for distributed computing environments. It uses the NDB Cluster storage engine, allowing multiple MySQL servers to run within a single cluster. The system can use inexpensive hardware and has no special hardware or software requirements. Furthermore, because each component has its own memory and disk, there are no single points of failure. A MySQL Cluster consists of a group of computers, each running various processes, including the MySQL server, NDB Cluster data nodes, a management server, and (potentially) dedicated data access programs. Additionally, the NDB Cluster solution can use ring replication to achieve data redundancy and synchronization between clusters.

[0056] It is understandable that in this embodiment, after using keepalived, the data access program only needs to access the external floating address to perform read and write data operations, which is convenient and simple. Moreover, after detecting a server failure, it can automatically switch to a backup server, facilitating the use and maintenance of the database. Using NDB Cluster, data redundancy and high reliability can be achieved between data centers through simple configuration, greatly simplifying network configuration. Furthermore, using NDB Cluster can form a database cluster with a minimum number of servers, reducing operating costs.

[0057] In practice, the "four servers" mentioned in step S12 include: the first server, the second server, the third server, and the fourth server.

[0058] If the first and second servers are configured as the first database cluster, the third and fourth servers are configured as the second database cluster. In practice, step S12, "configuring primary and backup redundancy for each group of servers," includes:

[0059] 1. Configure primary / standby redundancy for the first and second servers according to the preset configuration steps, specifically as follows:

[0060] a. Install keepalived on the first and second servers.

[0061] b. Modify the keepalived configuration file keepalived.conf on the first and second servers, configure the local address and floating address, and start keepalived; the server configured with the floating address is the primary server.

[0062] In practice, the keepalived.conf configuration file is configured with mcast_src_ip (local address) and VIP (floating address). The server with the VIP (floating address) configured is the primary server, and the other server is the backup server.

[0063] c. Deploy NDB Cluster on the first and second servers.

[0064] In practice, the specific steps for deploying an NDB Cluster are as follows:

[0065] Install MySQL Cluster on the first and second servers;

[0066] Modify the config.ini configuration file for MySQL Cluster on both the first and second servers. It should be noted that the contents of the config.ini configuration file for MySQL Cluster on both servers are exactly the same. The specific configuration content is as follows:

[0067] Modify the [ndbd default] item and configure NoOfReplicas=2;

[0068] Modify the [ndb_mgmd] item:

[0069] [ndb_mgmd]

[0070] NodeId=1

[0071] hostname = server1 address

[0072] datadir = / usr / mysql-cluster /

[0073] [ndb_mgmd]

[0074] NodeId=2

[0075] hostname = server2 address

[0076] datadir = / usr / mysql-cluster /

[0077] Modify the [ndbd] item:

[0078] [ndbd]

[0079] NodeId=11

[0080] hostname = server1 address

[0081] datadir = / usr / mysql / data

[0082] [ndbd]

[0083] NodeId=12

[0084] hostname = server2 address

[0085] datadir = / usr / mysql / data

[0086] Modify the [mysqld] item:

[0087] [mysqld]

[0088] NodeId=21

[0089] hostname = server1 address

[0090] [mysqld]

[0091] NodeId=22

[0092] hostname = server2 address

[0093] Modify the configuration file my.cnf for the first and second MySQL servers.

[0094] It should be noted that the MySQL server's configuration file, my.cnf, is located at / etc / my.cnf, and its specific configuration content is as follows:

[0095] Modify the [mysqld] section and add the following configuration;

[0096] ndbcluster

[0097] default-storage-engine=ndbcluster

[0098] ndb-connectstring = server1 address, server2 address

[0099] Add [mysql_cluster] and add the following configuration:

[0100] ndb-connectstring = server1 address, server2 address

[0101] d. Start the relevant NDB Cluster processes on the first server and the second server in sequence.

[0102] In practice, the NDB Cluster processes include: the NDB management process, the NDB data nodes, and the MySQL API nodes. Understandably, after installing MySQL Cluster, the NDB management process, NDB data nodes, and MySQL API nodes on each server in the cluster need to be started sequentially.

[0103] The following commands can be used to start the relevant NDB Cluster processes:

[0104] ndb_mgmd-f / usr / config.ini--initial

[0105] . / ndbd--initial

[0106] . / mysqld&

[0107] e. If the first server is the primary server and the second server is the backup server, after the keepalived monitoring of the first server detects an abnormal process of the NDB Cluster, the floating address will be switched to the second server.

[0108] In practice, the first step is to establish a connection between the database client and the MySQL API node in the NDB Cluster on the first server for data access and manipulation. The NDB Cluster backend will automatically synchronize the data. In practice, the database client can log in to the MySQL API node in the NDB Cluster on the first server by entering its username and password, thus establishing the connection between the database client and the MySQL API node in the NDB Cluster on the first server.

[0109] After the keepalived monitoring of the first server detects an abnormal process in the MySQL API node of the first server, the floating address is switched to the second server.

[0110] In practice, the keepalived server on the first server monitors the MySQL API process on that server. When it detects that the process is unavailable, it transfers the VIP from the first server to the second server. Similarly, when the second server (where the VIP is the primary user) detects an anomaly in the MySQL API process, it can also switch the VIP back to the first server. This achieves primary / backup failover for API node access.

[0111] Understandably, with keepalived, data access programs only need to access the external floating address to perform read and write operations, which is convenient and simple. Moreover, it can automatically switch to a backup server after detecting a server failure, which facilitates the use and maintenance of the database.

[0112] Please see Figure 2 , Figure 2 This is a schematic diagram of a network topology within a single cluster, as shown in an exemplary embodiment. Figure 2 As shown, the networked database cluster (NDB CLUSTER) includes: a first server and a second server. Each server includes: an NDB management node (first server management node), an NDB data node (ndbd), and a MySQL API node (mysqld). The first server and the second server are configured with the same floating address (VIP). Access to the specific database data node (ndbd) is achieved by accessing the floating address through the database client (MySQLClient).

[0113] Understandably, the above configuration can achieve the simplest deployment of a dual-machine NDB Cluster, realizing high availability and redundancy of data within a single cluster.

[0114] 2. Based on the configuration steps of the first and second servers, configure the third and fourth servers with primary and backup redundancy.

[0115] Understandably, based on the preset configuration steps of the first and second servers, the third and fourth servers are configured with corresponding primary and backup redundancy so that the third and fourth servers form a second database cluster after configuration.

[0116] In practice, step S13, "configuring ring-shaped primary-backup redundancy for the four servers behind the cluster to form redundancy between the database clusters," includes:

[0117] 1. Modify the MySQL API node parameters in the MySQL server configuration file my.cnf of each server in the first and second database clusters;

[0118] It should be noted that the my.cnf file (the configuration file for the MySQL server) needs to be modified on all four machines. The configuration file path is / etc / my.cnf. The specific modifications are shown below, taking service 1 as an example:

[0119] Modify the [mysqld] section and add the following configuration;

[0120] server-id=1 -- Set different values ​​for each of the four machines.

[0121] log-bin= / usr / mysql / data / log / ndb1.bin -- Path to generate log file log-bin-index= / usr / mysql / data / log / ndb1.index -- Path to generate index file

[0122] 2. Configure the ring redundancy relationship of data nodes in the first and second database clusters.

[0123] In practice, the ring redundancy relationship of data nodes in the first and second database clusters is configured as follows:

[0124] a. Determine the circular data redundancy relationship between databases on different servers.

[0125] In practice, the data node of the first server can be set as the primary data node of the third server, and the data node of the fourth server can be set as the primary data node of the second server; the circular data redundancy relationship between the databases can also be adjusted according to the actual situation.

[0126] b. Connect the MySQL API nodes of the third and second servers to configure the master-slave relationship between the servers in the cluster.

[0127] In practice, logging into the MySQL API node of the third and second servers allows you to execute commands to establish master-slave relationships between servers in the cluster. The specific commands are as follows:

[0128] Log in to MySQL API node 3:

[0129] CHANGE MASTER TO MASTER_HOST = 'Server 1 address', MASTER_PORT = 3306, MASTER_USER = 'Username', MASTER_PASSWORD = 'Password', master_log_file = 'ndb1.000001', master_log_pos = 154;

[0130] Log in to MySQL API node 2:

[0131] MASTER_PORT = 3306, MASTER_USER = 'username', MASTER_PASSWORD = 'password', master_log_file = 'ndb1.000001', master_log_pos = 154;

[0132] c. Connect the MySQL API nodes of the third and second servers and start the master-slave configuration between the cluster servers.

[0133] In practice, logging into the MySQL API node of the third and second servers allows you to execute commands to start the master-slave configuration between servers in the cluster. The specific commands are as follows:

[0134] Log in to MySQL API node 3:

[0135] Start slave;

[0136] Log in to MySQL API node 2:

[0137] Start slave;

[0138] d. Connect to the MySQL API nodes of the third and second servers to check if master-slave replication between the clusters is effective.

[0139] In practice, logging into the MySQL API node of the third and second servers allows you to execute commands to check whether master-slave replication between the clusters is effective. The specific commands are as follows:

[0140] Log in to MySQL API node 3 to check the master-slave status:

[0141] Show slave status\G

[0142] Log in to MySQL API node 2 to check the master-slave status:

[0143] Show slave status\G

[0144] Please see Figure 3A and Figure 3B , Figure 3A and Figure 3B This is a schematic diagram of a dual-cluster network according to an exemplary embodiment. Due to space limitations, Figure 3A The attached figure's label "a" and Figure 3B The attached diagram is connected to the symbol "a". Figure 3A The attached figure's reference numeral "b" and Figure 3B The attached diagram is connected by the identifier "b", such as... Figure 3A and Figure 3BAs shown, after networking between the two clusters, the two database clusters (NDBCLUSTER 1 and NDB CLUSTER 2) consist of four servers: server1-server4. Server1 and server2 form NDB CLUSTER 1, and server3 and server4 form NDB CLUSTER 2. Server1 and server4 are the primary servers, and server2 and server3 are the backup servers.

[0145] It is understandable that using NDB Cluster, through simple configuration, can achieve data redundancy and high reliability between two clusters, greatly simplifying network configuration. Furthermore, using NDB Cluster allows for the formation of a database cluster with a minimal number of servers, reducing operating costs. It is also understandable that this application provides a database redundancy method to achieve database cluster redundancy. By installing cluster components, including keepalived and NDB Cluster, on the four servers in the cluster, the four servers are divided into two groups. Primary and backup redundancy configurations are performed on the servers in each group, and the two servers with completed primary and backup redundancy configurations are defined as a database cluster, achieving high redundancy and high reliability of data synchronization within the cluster. A ring primary and backup redundancy configuration is then performed on the four servers behind the cluster, forming redundancy between database clusters. If a server in one cluster is designated as the primary server for a server in another cluster, the other server in that cluster is designated as the backup server for the remaining server in the other cluster. This achieves high redundancy and high reliability of data synchronization between clusters, solving the problem that existing redundancy schemes using MySQL databases cannot achieve cross-regional disaster recovery between data centers.

[0146] Please see Figure 4 , Figure 4 This is a schematic block diagram illustrating a database redundancy device according to an exemplary embodiment, such as... Figure 4 As shown, the database redundancy device 100 includes:

[0147] The cluster configuration module 101 is used to divide the four servers with cluster components installed into two groups, configure primary and backup redundancy for the servers in each group, and determine the two servers that have completed the primary and backup redundancy configuration as a database cluster.

[0148] The inter-cluster configuration module 102 is used to configure the four servers behind the cluster in a ring-shaped primary-backup redundancy configuration to form redundancy between the database clusters. This includes: if a server in any cluster is determined to be the primary server of a server in another cluster, then another server in that cluster is determined to be the backup server of the remaining server in the other cluster.

[0149] Regarding the database redundancy device 100 in this embodiment, the specific manner in which its intra-cluster configuration module 101 and inter-cluster configuration module 102 execute the above method has been described in detail in the embodiments related to the method, and will not be elaborated here.

[0150] It is understood that the technical solution provided in this embodiment, the database redundancy device, achieves high redundancy and high data synchronization reliability within the cluster by installing cluster components on the four servers of the database cluster. The four servers with the cluster components installed are divided into two groups, and primary and backup redundancy configurations are performed on the servers in each group. The two servers that have completed the primary and backup redundancy configurations are determined as a database cluster. The four servers behind the cluster are configured with ring primary and backup redundancy to form redundancy between database clusters. If a server in any cluster is determined to be the primary server of a server in another cluster, the other server in that cluster is determined to be the backup server of the remaining server in the other cluster. This achieves high redundancy and high data synchronization reliability between clusters, solving the problem that existing redundancy schemes using MySQL databases cannot achieve the function of primary and backup disaster recovery between data centers.

[0151] An electronic device according to an exemplary embodiment includes the database redundancy device 100 described above.

[0152] Regarding the electronic device including the database redundancy device in the above embodiments, the specific manner in which the database redundancy device performs the above method has been described in detail in the embodiments related to the method, and will not be elaborated here.

[0153] In practice, the electronic device can be a mobile phone, tablet computer, desktop computer, etc., equipped with the database redundancy device.

[0154] It is understood that the technical solution provided in this embodiment includes the aforementioned database redundancy device. This device achieves high redundancy and high data synchronization reliability by installing cluster components on the four servers in the cluster containing the database. The cluster components include a keepalived component and an NDB Cluster. The four servers with the cluster components are divided into two groups, and primary / standby redundancy is configured for the servers in each group. The two servers that have completed the primary / standby redundancy configuration are identified as a database cluster. The four servers behind the cluster are configured with ring primary / standby redundancy to form redundancy between database clusters. If a server in any cluster is identified as the primary server of a server in another cluster, the other server in that cluster is identified as the standby server of the remaining server in the other cluster. This achieves high redundancy and high data synchronization reliability between clusters, solving the problem that existing schemes using MySQL databases for redundancy cannot achieve the function of primary / standby disaster recovery between data centers.

[0155] Furthermore, this application provides a computer-readable storage medium storing computer instructions for causing a computer to perform the steps of any of the methods described above. The storage medium may be a magnetic disk, optical disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk drive (HDD), or solid-state drive (SSD), etc.; the storage medium may also include combinations of the above types of memory.

[0156] It is understood that the same or similar parts in the above embodiments can be referred to each other, and the contents not described in detail in some embodiments can be referred to the same or similar contents in other embodiments.

[0157] It should be noted that in the description of this application, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Furthermore, in the description of this application, unless otherwise stated, "multiple" or "more" means at least two.

[0158] It should be understood that when an element is referred to as "fixed to" or "set on" another element, it may be directly on the other element or may have an intervening element present at the same time; when an element is referred to as "connected to" another element, it may be directly connected to the other element or may have an intervening element present at the same time. In addition, the term "connected" as used herein may include wireless connections; the word "and / or" as used includes any unit and all combinations of one or more of the associated listed items.

[0159] Any process or method description in the flowchart or otherwise herein can be understood as: representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the function involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0160] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0161] Those skilled in the art will understand that all or part of the steps of the methods described in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it includes one or a combination of the steps of the method embodiments.

[0162] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0163] The storage media mentioned above can be read-only memory, disk, or optical disk, etc.

[0164] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0165] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A database redundancy method, characterized in that, include: Install cluster components on the four servers where the database is located. The cluster components include keepalived and NDB Cluster. The four servers are: the first server, the second server, the third server, and the fourth server. The four servers equipped with cluster components are divided into two groups. Primary / standby redundancy is configured for each group of servers, and the two servers with completed primary / standby redundancy configurations are defined as a database cluster. Specifically, if the first and second servers are configured as the first database cluster, and the third and fourth servers are configured as the second database cluster, the primary / standby redundancy configuration for each group includes: The first and second servers are configured with primary / standby redundancy according to preset configuration steps, specifically including: installing keepalived on the first and second servers; modifying the keepalived configuration file keepalived.conf on the first and second servers to configure the local address and floating address, and starting keepalived; wherein, the server configured with the floating address is the primary server; deploying NDBCluster on the first and second servers; starting the relevant NDB Cluster processes on the first and second servers sequentially; if the first server is the primary server and the second server is the standby server, after keepalived on the first server detects an abnormal process of the NDB Cluster, the floating address is switched to the second server, specifically including: establishing a connection between the database client and the MySQL API node in the NDB Cluster on the first server for data access and operation; after keepalived on the first server detects an abnormal process of the MySQL API node on the first server, the floating address is switched to the second server; Based on the configuration steps of the first and second servers, the third and fourth servers are configured with primary and backup redundancy. To achieve redundancy between the database clusters, the four servers behind the cluster are configured with a ring primary-backup configuration. This includes modifying the MySQL API node parameters in the MySQL server configuration file my.cnf of each server in the first and second database clusters. Configure the ring redundancy relationship between data nodes in the first and second database clusters.

2. The method according to claim 1, characterized in that, The deployment of NDB Cluster on the first server and the second server includes: Install MySQL Cluster on the first and second servers; Modify the config.ini configuration file for MySQL Cluster on both the first and second servers; Modify the configuration file my.cnf for the first and second MySQL servers.

3. The method according to claim 1, characterized in that, The sequential startup of the relevant NDB Cluster processes on the first server and the second server includes: Start the NDB management process, NDB data node, and MySQL API node on the first and second servers in sequence.

4. The method according to claim 1, characterized in that, The configuration of the ring redundancy relationship of data nodes in the first and second database clusters includes: A circular data redundancy relationship is determined among databases on different servers; wherein, the data node of the first server serves as the primary data node of the third server, and the data node of the fourth server serves as the primary data node of the second server; Connect the MySQL API nodes of the third and second servers to configure the master-slave relationship between the servers in the cluster; Connect the MySQL API nodes of the third and second servers to initiate the master-slave configuration between the cluster servers; Connect to the MySQL API nodes of the third and second servers to check if master-slave replication between the clusters is effective.

5. A database redundancy device, characterized in that, include: The cluster configuration module is used to divide four servers with cluster components installed into two groups, configure primary and secondary redundancy for the servers in each group, and determine the two servers that have completed the primary and secondary redundancy configuration as a database cluster. The four servers include: a first server, a second server, a third server, and a fourth server. If the first server and the second server are configured as the first database cluster, the cluster configuration module is used to configure primary and secondary redundancy for the first server and the second server according to preset configuration steps, specifically including: installing keepalived on the first server and the second server; modifying the keepalived configuration file keepalived.conf on the first server and the second server, configuring the local address and floating address, and starting keepalived; wherein the server configured with the floating address is the primary server; deploying NDB Cluster on the first server and the second server; sequentially starting the relevant NDB Cluster processes on the first server and the second server respectively; if the first server is the primary server and the second server is the secondary server, after keepalived on the first server detects an abnormality in the NDB Cluster process, switching the floating address to the second server, specifically including: establishing a connection between the database client and the MySQL API node in the NDB Cluster on the first server. Perform data access and operations; after the keepalived monitoring of the first server detects an abnormal process of the MySQL API node of the first server, switch the floating address to the second server; according to the configuration steps of the first and second servers, configure the third and fourth servers with primary and backup redundancy. The inter-cluster configuration module is used to configure ring-shaped primary-backup redundancy for the four servers behind the cluster, forming redundancy between the database clusters. This includes: modifying the MySQL API node parameters in the MySQL server configuration file my.cnf of each server in the first and second database clusters; and configuring the ring-shaped redundancy relationship of data nodes in the first and second database clusters.

6. An electronic device, characterized in that, include: The database redundancy device according to claim 5.

Images