WO2024083259A1 - 主备数据库集群及选主方法、计算设备及存储介质 - Google Patents

主备数据库集群及选主方法、计算设备及存储介质 Download PDF

Info

Publication number
WO2024083259A1
WO2024083259A1 PCT/CN2023/126010 CN2023126010W WO2024083259A1 WO 2024083259 A1 WO2024083259 A1 WO 2024083259A1 CN 2023126010 W CN2023126010 W CN 2023126010W WO 2024083259 A1 WO2024083259 A1 WO 2024083259A1
Authority
WO
WIPO (PCT)
Prior art keywords
master
node
database
standby
renewal
Prior art date
Application number
PCT/CN2023/126010
Other languages
English (en)
French (fr)
Inventor
张刚
Original Assignee
中移(苏州)软件技术有限公司
中国移动通信集团有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中移(苏州)软件技术有限公司, 中国移动通信集团有限公司 filed Critical 中移(苏州)软件技术有限公司
Publication of WO2024083259A1 publication Critical patent/WO2024083259A1/zh

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1438—Restarting or rejuvenating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Definitions

  • the present invention relates to the field of database technology, and in particular to, but not limited to, a master-slave database cluster and a master selection method, a computing device, and a storage medium.
  • StatefulSet is used to implement stateful applications.
  • yaml YAML Ain't Markup Language, abbreviated as yaml, a data serialization language that can be used with most programming languages and is often used to write configuration files
  • yaml YAML Ain't Markup Language
  • yaml a data serialization language that can be used with most programming languages and is often used to write configuration files
  • a series of scripts including detecting the database instance status and performing master-slave switching are usually defined. When the preset conditions are met, the corresponding scripts are triggered, which to a certain extent ensures the high availability of the master-slave cluster. Usability.
  • the database cluster still has the following problems in the master-slave switching: First, it is easy to have a brain split. When there is a problem with the network connectivity of the master and standby nodes, the standby node will think that the master node has hung up, and the standby-to-master logic will be triggered.
  • the master node is still continuing to provide services, resulting in a "dual-master" problem, causing database cluster abnormalities;
  • the "one-time” script because the triggering conditions and the execution script after the conditions are met are solidified in the yaml file, when the triggering conditions are met, the cluster will execute the script in sequence, and when the execution is completed, due to the switch of the master and standby nodes, the original script will no longer be used, and the effect of continuous use cannot be achieved. If an abnormality occurs again, manual processing is required; third, in most scenarios, the time consumed by the process of upgrading the standby to the master is longer than the restart of the original master node.
  • the present invention is proposed to provide a master-slave database cluster and master selection method, computing device and storage medium that overcome the robustness and availability problems of the above database cluster in the master-slave switching process.
  • a method for selecting a master in a master-slave database cluster comprising:
  • the first master selection component of the first node periodically executes a renewal operation of the resource lock, and determines whether the renewal operation is successful within a first preset time threshold. If so, the renewal time of the resource lock is updated to the current time; if not, the first node kills the database process and restarts the database process in read-only mode, triggering the execution of the master-slave operation of the first node;
  • the second master election component of the second node periodically polls the renewal time of the resource lock to determine the current time Whether the time difference with the renewal time exceeds the second preset time threshold, if so, trigger the execution of the backup-to-main operation of the second node.
  • the method further includes:
  • the first master election component of the first node checks whether a new master node is generated in the cluster
  • the triggering of executing the active/standby operation of the first node specifically includes: if the first master election component of the first node checks that a new master node is generated in the cluster, triggering the execution of the active/standby operation of the first node;
  • the method further includes: if the first master election component of the first node checks that no new master node is generated in the cluster, then attempting to acquire a resource lock and perform operations as a master node.
  • triggering the execution of the active/standby operation of the first node further includes:
  • An operation of establishing a master-standby relationship with the second node switched to the master node is performed.
  • the method before triggering the execution of the standby switching master operation of the second node, the method further includes:
  • the preparation operation for performing the standby switching to the primary further includes:
  • the method further includes:
  • the second node is used as a standby node again and connected to a new master node.
  • the second preset time threshold is greater than the first preset time threshold.
  • a master-standby database cluster comprising: a first node and a second node;
  • the first node includes:
  • a first selection master component is configured to periodically execute a renewal operation of the resource lock, determine whether the renewal operation is successful within a first preset time threshold, and if so, update the renewal time of the resource lock to the current time;
  • the first database component is configured to kill the database process and restart the database process in read-only mode if it is determined that the renewal operation is not successful within the first preset time threshold; trigger the execution of the primary-standby operation of the first node;
  • the second node includes:
  • the second master selection component is configured to periodically poll the renewal time of the resource lock to determine whether the time difference between the current time and the renewal time exceeds a second preset time threshold;
  • the second database component is configured to trigger the execution of the backup-to-main operation of the second node if it is determined that the time difference between the current time and the renewal time exceeds a second preset time threshold.
  • a computing device comprising: a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface communicate with each other via the communication bus;
  • the memory is configured to store at least one executable instruction, and the executable instruction enables the processor to execute operations corresponding to the master election method of the master-standby database cluster.
  • a storage medium wherein at least one executable instruction is stored in the storage medium, and the executable instruction enables a processor to execute operations corresponding to the above-mentioned method for selecting a master in a master-standby database cluster.
  • the first master selection component of the first node periodically performs a renewal operation of the resource lock, determines whether the renewal operation is successful within a first preset time threshold, and if so, updates the renewal time of the resource lock to the current time; if not, the first node kills the database process. And restart the database process in read-only mode, triggering the execution of the primary-standby switching operation of the first node; the second primary selection component of the second node periodically polls the renewal time of the resource lock, determines whether the time difference between the current time and the renewal time exceeds the second preset time threshold, and if so, triggers the execution of the secondary-standby switching operation of the second node.
  • the present invention realizes the use of distributed locks as the third-party primary selection logic, and performs automatic status detection and primary-standby switching in the primary selection process of the primary and standby database cluster based on the third-party primary selection logic, ensuring continuous monitoring and primary-standby switching capabilities, and improving the robustness and availability of the primary and standby clusters during the primary-standby switching process.
  • FIG. 1a shows a schematic diagram of a process flow of master-slave switching in a master selection method for a master-slave database cluster according to an embodiment of the present invention
  • FIG1b shows a schematic diagram of a process of switching from standby to master in a method for selecting a master in a master-standby database cluster according to an embodiment of the present invention
  • FIG2a shows a schematic diagram of a process flow of master-slave switching in a master selection method for a master-slave database cluster according to another embodiment of the present invention
  • FIG2b shows a schematic diagram of a process of switching from standby to master in a method for selecting a master in a master-standby database cluster according to another embodiment of the present invention
  • FIG3 is a schematic diagram showing a flow chart of a method for selecting a master in a master-slave database cluster according to another embodiment of the present invention.
  • FIG4 shows a schematic diagram of the structure of a master-slave database cluster according to an embodiment of the present invention
  • FIG. 5 shows a schematic diagram of the structure of a computing device according to an embodiment of the present invention.
  • Kubernetes Also known as K8s, it provides a mechanism for application deployment, planning, updating and maintenance. It can realize the functions of automatic deployment, automatic expansion and contraction, maintenance and other functions of container clusters. It is usually used to manage containerized applications on multiple hosts in cloud platforms. In Kubernetes, all containers run in Pods, and a Pod can carry one or more related containers.
  • ETCD It is a distributed consistent key-value storage system that provides a reliable way to store data that needs to be accessed by distributed systems or machine clusters. It is usually used for shared configuration and service discovery. In K8s, ETCD is the default storage system for K8s and is used to save all cluster data.
  • a Pod It is the smallest/simplest basic unit created or deployed by Kubernetes.
  • a Pod is a "logical host" in a container environment.
  • a Pod can encapsulate one or more application containers.
  • Leader Election mechanism It is a master-slave election method or mechanism of Kubernetes. When each instance is started, it tries to seize the lock resource. The instance that seizes the lock becomes the master node. The master node periodically updates the current timestamp. If the master node fails to update the timestamp within a given time interval, it is considered to have lost connection. At this time, other instances obtain the lock resource by preemption and become the new master node.
  • Figure 1a shows a schematic diagram of the process of master-slave switching in the master selection method of the master-slave database cluster of the embodiment of the present invention
  • Figure 1b shows a schematic diagram of the process of standby-master switching in the master selection method of the master-slave database cluster of the embodiment of the present invention.
  • This method combines the master selection mechanism with the database master-slave switching logic to form a leader selection component (Leader component).
  • Leader component Leader component
  • the leader component of the master-slave node interacts with the distributed lock to perform master-slave switching in a manner of jointly maintaining resource locks, including master-slave switching operations and standby-master switching operations.
  • the master-slave switching and standby-master switching are two parallel operations, which are interconnected and closely cooperated to jointly complete the master-slave switching operation of the master-slave database cluster.
  • the master-slave switching operation executes the step of the master node becoming the standby node
  • the standby-master switching operation executes the step of the standby node becoming the new master node.
  • the first master selection component periodically executes the renewal operation of the resource lock. If the renewal is unsuccessful, the master-slave switching operation of the first node is triggered.
  • the second master selection component periodically polls the renewal time of the resource lock.
  • the standby master-offset operation of the second node is triggered.
  • the master-offset operation in the master selection method of the master-standby database cluster includes the following steps:
  • Step A101 The first master election component of the first node periodically performs a resource lock renewal operation.
  • a master node can be manually selected or randomly initialized.
  • the node that is the master node in the current database cluster is called the first node, and the master selection component (called the first master selection component) is deployed on the first node as a competitive entity. Therefore, the first master selection component and the database master service program/process of the first node are set in the same master node, that is, the first node.
  • This embodiment is based on the Leader Election mechanism.
  • a distributed resource lock is defined and updated through the resource lock to ensure that the database master and backup resources can only be updated once when the resources are updated concurrently, and the distributed resource lock is updated regularly to realize the election of the master node.
  • the master node can continuously maintain its master node status or role by executing the resource lock renewal operation.
  • Step A102 Determine whether the renewal operation is successful within the first preset time threshold. If so, Execute step A103; if not, execute step A104.
  • the first master selection component of the first node determines whether the renewal operation is successful within the first preset time threshold. If the renewal operation is successful within the first preset time threshold, it indicates that the first node successfully attempts to obtain the lock and can continue to maintain its master node status or role; if the renewal operation is unsuccessful within the first preset time threshold, it means that the network of the first node is abnormal and the renewal operation will no longer be attempted.
  • the first preset time threshold can be the renewal timeout (such as 10 seconds)
  • the second preset time threshold below can be the lease time (such as 15 seconds)
  • the second preset time threshold can be slightly larger than the first preset time threshold, that is, the lease time is slightly larger than the renewal timeout, so that after the database process is restarted on the first node, there is still a chance to reacquire the resource lock.
  • Step A103 Update the renewal time of the resource lock to the current time.
  • the renewal time of the resource lock is updated to the current time to ensure that the resource lock is updated once when it is concurrently updated, and the election system of the master node is realized by combining the renewal time of the resource lock with the regular update. After step A103, continue to execute step A101.
  • Step A104 the first node kills the database process and restarts the database process in read-only mode, triggering the execution of the active/standby operation of the first node.
  • the first node kills or restarts the database process, and restarts the database process in read-only mode to ensure the consistency of the database during the active-standby switching process, and triggers the active-standby switching operation of the first node. It should be noted that the database process can be restarted in read-only mode after or at the same time as the first node kills the database process.
  • the operation of switching from standby to master in the master election method of the master-standby database cluster includes the following steps:
  • Step B101 The second master election component of the second node periodically polls the renewal time of the resource lock.
  • the master election component (called the second master election component) is The second master component and the database backup service program/process of the second node are deployed in each second node, and are set in the same backup node, namely the second node.
  • the second master selection component checks the renewal time in the distributed resource lock information by periodic polling or heartbeating.
  • Step B102 Determine whether the time difference between the current time and the renewal time exceeds a second preset time threshold. If so, execute step B103; if not, execute step B101.
  • step B103 Determine whether the time difference between the current time and the renewal time in the distributed resource lock information exceeds the second preset time threshold. If so, execute step B103; if not, it means that the lease of the first node (ie, the master node) has not expired, and continue to execute step B101.
  • Step B103 triggering the execution of the standby switching master operation of the second node.
  • the standby node switches to the master node.
  • the switch between the master and standby databases that is, switching the standby database to the master database
  • the first master selection component of the first node periodically executes the renewal operation of the resource lock, determines whether the renewal operation is successful within the first preset time threshold, and if so, updates the renewal time of the resource lock to the current time; if not, the first node kills the database process and restarts the database process in read-only mode, triggering the execution of the primary-to-standby operation of the first node; the second master selection component of the second node periodically polls the renewal time of the resource lock, determines whether the time difference between the current time and the renewal time exceeds the second preset time threshold, and if so, triggers the execution of the standby-to-primary operation of the second node.
  • the present invention performs automatic status detection and primary-standby switching in the primary-standby database cluster selection process based on the third-party master selection logic, ensures continuous monitoring and primary-standby switching capabilities, improves the robustness and availability of the primary-standby cluster during the primary-standby switching process, and reduces the time of primary-standby switching.
  • FIG2a shows a schematic diagram of the process of master-slave switching in a master selection method for a master-slave database cluster according to another embodiment of the present invention.
  • the master-slave switching operation process of this embodiment after the first node renewal operation fails and the database process is restarted, it is first checked whether a new master node is generated in the cluster, and whether to perform the master-slave switching operation is determined based on the check result.
  • the method includes the following steps: Steps:
  • Step A201 The first master election component of the first node periodically performs a resource lock renewal operation.
  • the database process status of the node is checked. If it is not started, polling and waiting are performed. If the database process is successfully started, proceed to the next step. Start the monitoring service to detect and record the database process status.
  • the first node selected as the master node executes the renewal operation of the resource lock every 1s.
  • Step A202 Determine whether the renewal operation is successful within the first preset time threshold, if so, execute step A203; if not, execute step A204.
  • the first master-elect component of the first node determines that the renewal operation is successful within the above-mentioned renewal timeout period, it indicates that the first node's attempt to obtain the lock is successful and it can continue to maintain its master node status or role; if it is determined that the renewal operation is unsuccessful within the above-mentioned renewal timeout period, it means that the network of the first node is abnormal and the renewal operation will no longer be attempted. Further, when the lease time is exceeded, the lease will become invalid.
  • the second preset time threshold is greater than the first preset time threshold, that is, the lease time is slightly greater than the renewal timeout.
  • Step A203 Update the renewal time of the resource lock to the current time.
  • step A203 Update the distributed resource lock, and update the renewal time in the distributed resource lock information to the current time, indicating that the distributed resource lock is in an occupied state at the current time. After step A203, continue to execute step A201.
  • Step A204 The first node kills the database process and restarts the database process in read-only mode.
  • the first node kills or restarts the database process and restarts the database process in read-only mode. Ensure the consistency of the database during the active-standby switchover process.
  • Step A205 The first master election component of the first node checks whether a new master node is generated in the cluster.
  • the first master election component of the first node checks whether a new master node is generated in the cluster to avoid the so-called "brain split” phenomenon caused by the emergence of two "brains” (i.e., master nodes) in the master-slave database cluster.
  • "Brain split” refers to the data inconsistency between the master and standby nodes in the master-slave cluster due to the emergence of two master nodes providing services at the same time. If the first master election component of the first node checks whether a new master node is generated in the cluster, the master-standby operation of the first node is triggered; if no new master node is generated, it attempts to obtain the resource lock and perform operations as the master node.
  • Step A206 triggering the execution of the active/standby operation of the first node.
  • Triggering the execution of the master-standby operation of the first node can reduce the time of the master-standby switching.
  • the master-standby operation of the first node specifically includes: setting the database of the first node to read-only mode and executing the operation of establishing a master-standby relationship with the second node that is switched to the master node.
  • Step A207 Try to acquire the resource lock and perform operations as the master node.
  • the first master-elect component of the first node checks that no new master node is generated in the cluster, it attempts to obtain the resource lock and perform operations as a master node. After an abnormal situation occurs in the first node, it restarts and continues to respond to services as a master node after successfully attempting to obtain the resource lock, thereby ensuring the long-term operation of the master-standby cluster and improving the robustness of the cluster.
  • the first selected master component of the first node checks whether the cluster generates a new master node. If not, it attempts to obtain the resource lock and executes the operation as the master node; if so, it executes the master-slave operation of the first node.
  • the present invention can avoid the "brain split" phenomenon in the master-slave database cluster by checking whether the cluster generates a new master node; when a new master node is generated, the master-slave operation is executed, and the master node automatically falls back to the standby node, reducing the time of the master-slave switch; when no new master node is generated, it attempts to obtain the resource lock and execute the operation as the master node to ensure the persistent operation of the master-slave cluster and improve the robustness of the cluster.
  • FIG2b shows a schematic diagram of a process of switching from standby to master in a method for selecting a master in a master-standby database cluster according to another embodiment of the present invention. Specifically, as shown in FIG2b , the method includes the following steps:
  • Step B201 The second master election component of the second node periodically polls the renewal time of the resource lock.
  • the master election component (second master election component) of the standby node (second node) periodically polls and checks the renewal time in the distributed resource lock information.
  • Step B202 Determine whether the time difference between the current time and the renewal time exceeds a second preset time threshold. If so, execute step B203; if not, execute step B201.
  • step B203 Determine whether the time difference between the current time and the renewal time in the distributed resource lock information exceeds the above lease time. If so, execute step B203; if not, it means that the lease of the first node (ie, the master node) has not expired, and continue to execute step B201.
  • Step B203 Execute the preparation operation of switching the backup to the primary.
  • Perform preparations for switching from standby to primary including shutting down replication between the primary and standby nodes, clearing primary and standby configuration information, and ensuring consistency with the database of the first node based on database logs.
  • the replication operation between the primary and standby databases is closed to stop the database replication operation between the primary and standby databases, including asynchronous replication, multi-threaded replication, and semi-synchronous replication operations between the primary and standby databases.
  • clearing the master and standby configuration information includes clearing the master and standby configuration information of the master node and the configuration information of the standby node.
  • the database log ensure that it is consistent with the database of the first node (i.e., the original master node). Since the integrity of the master and standby node databases depends on the database logs, the lost data can be synchronized to the standby node database through the database logs. Specifically, the database logs are analyzed to obtain the difference data, the data that has been executed, and the data that has not been written, and perform corresponding database operations to solve the inconsistency problem between the master and standby databases.
  • Step B204 Determine again whether the time difference between the current time and the renewal time exceeds the second preset time threshold. If so, execute step B205; if not, execute step B206.
  • the backup to primary switch operation After executing the preparation operation of the backup to primary switch, the backup to primary switch operation is not performed immediately, but it is determined again whether the time difference between the current time and the renewal time in the distributed resource lock information exceeds the above
  • the lease time fully considers some high-quality service features of the original master node (such as hardware, network, security, and stability) and the resource overhead or business impact of the master-slave switch by performing the backup-to-master operation in a re-confirmation or secondary confirmation manner, and minimizes the impact on the high availability of the master-slave database cluster.
  • Step B205 Execute the standby-to-main operation of the second node.
  • the active/standby switching operation of the second node is executed, that is, the standby node is automatically switched to the active node.
  • Step B206 Re-use the second node as a standby node and connect to the new master node.
  • the master-slave switch will not be performed, and the second node will be used as the standby node again and connected to the new master node.
  • the solution provided by the above embodiment of the present invention after executing the preparation operation of standby switching to master, again determines whether the time difference between the current time and the renewal time exceeds the second preset time threshold, that is, when the standby node has the conditions to become the new master node, the standby switching to master operation is not performed immediately, but again determines whether the time difference between the current time and the renewal time in the distributed resource lock information exceeds the second preset time threshold.
  • the present invention reduces the impact on the high availability of the master-standby database cluster to a minimum by performing the standby switching to master operation in a second or secondary confirmation manner, thereby minimizing the master-standby switching action.
  • FIG3 shows a flow chart of a method for selecting a master for a master-slave database cluster according to another embodiment of the present invention.
  • This method implements third-party master election logic based on the Leader Election mechanism of Kubernetes, and introduces a distributed resource lock to implement the method for selecting a master for a master-slave database cluster.
  • the Leader Election mechanism and the MySQL master-slave switching logic are combined to form a master election component Leader.
  • the master election component Leader is placed in the same Pod as a separate container (container) and the MySQL container (container).
  • the master election component Leader of the master and standby nodes interacts with ETCD to jointly maintain a distributed resource lock (lock), including the master-slave switching process (Master process) and the standby-master switching process (Slave process).
  • Lock distributed resource lock
  • the detailed process of the startup phase of the MySQL database cluster is as follows:
  • Step 1 After the leader of the active and standby nodes is started, check the startup status of the MySQL database process on the node. If it is not started, poll and wait. If the MySQL database is started, If the program is successfully started, go to step 2.
  • Step 2 Start the monitoring service to detect and record the database process status. For example, start the detection (such as health) service to monitor the process status of the MySQL port (such as port 9001). If the MySQL process is started, it is set to true, otherwise it is set to false.
  • start the detection such as health
  • MySQL port such as port 9001
  • Step 3 Initialize a LeaderElector as a competing entity, use its own ID as the unique identifier, and specify parameters such as the lease time (such as 15 seconds), renewal timeout (such as 10 seconds), and retry time (such as 1 second).
  • Step 4 The database instance Pod ends with 00 and 01 by default.
  • 00 is used as the primary node by default. Therefore, after the 01 node polls and waits for the 00 node to obtain the lock and become the leader, the subsequent steps are executed.
  • Step 5 By default, node 00 executes the operation of becoming the master.
  • step five further includes the following steps:
  • Step 6 After node 01 checks in step 4 that node 00 has acquired the lock, it starts to execute the operation of becoming a slave.
  • step six further includes the following steps:
  • Step 1 Execute the renewal operation every second, update the distributed lock, and update the renewalTime to the current time.
  • Step 2 If the renewal operation fails to succeed within 10 seconds, it means that there is a problem with the node network and the node will no longer attempt to renew the operation. This means that the lease will expire after 15 seconds.
  • Step 3 The node kills the mysqld process and exits itself.
  • Step 4 After Kubernetes restarts the service, the mysqld process will restart in read-only mode.
  • Step 5 After the leader component is restarted, try to recheck whether a new leader is generated in the cluster.
  • step five further includes the following steps:
  • step 6 of the startup process above If a new leader has been generated, execute step 6 of the startup process above.
  • Step 1 Poll and check the distributed lock information every 1 second.
  • Step 2 Check the renewalTime.
  • step 2 further includes the following steps:
  • the renewalTime is less than 15 seconds compared to the current time, it means that the leader node lease has not expired, then exit and proceed to step 2 of the polling operation.
  • Step 3 Perform preparation operations for upgrading the backup node to the primary node.
  • step three further includes the following steps:
  • Step 4 After the conditions for becoming the master node are met, the standby node is not promoted to the master node immediately, but attempts to obtain the resource lock again.
  • step 4 further includes the following steps:
  • the resource lock is not obtained, it means that a new master node has been generated, and then the node will reconnect itself to the new master node as a standby node.
  • Step 5 After the master-slave switch is completed, the new master node and the standby node continue to detect according to the above logic.
  • the solution provided by the above-mentioned embodiment of the present invention implements the third-party leader election logic based on the Leader Election mechanism of Kubernetes, and introduces a distributed resource lock to implement the leader election method of the master-slave database cluster.
  • the Leader Election mechanism and the database master-slave switching logic are combined to form a leader election component Leader.
  • the leader election component Leader is placed in the same Pod as the database container as a separate container.
  • the leader election component Leader and ETCD of the master and standby nodes interact to jointly maintain a distributed resource lock (lock).
  • the present invention performs automatic status detection and master-slave switching in the master election process of the master-slave database cluster based on the third-party leader election logic, ensuring continuous monitoring and master-slave switching capabilities, improving the robustness and availability of the master-slave cluster during the master-slave switching process, and reducing the master-slave switching time.
  • Fig. 4 shows a schematic diagram of the structure of the master-standby database cluster according to an embodiment of the present invention.
  • the master-standby database cluster 400 includes a first node 401 and a second node 402; wherein the first node 401 includes: a first master election component 4011 and a first database component 4012; the second node 402 includes: a second master election component 4021 and a second database component 4022.
  • the first master selection component 4011 is configured to periodically execute a renewal operation of the resource lock, determine whether the renewal operation is successful within a first preset time threshold, and if so, update the renewal time of the resource lock to the current time;
  • the first database component 4012 is configured to kill the database process and restart the database process in read-only mode if it is determined that the renewal operation is not successful within the first preset time threshold; trigger the execution of the primary-standby operation of the first node;
  • the second selected main component 4021 is configured to periodically poll the renewal time of the resource lock to determine whether the time difference between the current time and the renewal time exceeds a second preset time threshold;
  • the second database component 4022 is configured to trigger the execution of the backup-to-main operation of the second node if it is determined that the time difference between the current time and the renewal time exceeds a second preset time threshold.
  • the first primary selection component 4011 is further configured to:
  • the first database component 4012 is further configured to:
  • An operation of establishing a master-standby relationship with the second node switched to the master node is performed.
  • the second database component 4022 is further configured to:
  • the second database component 4022 is further configured to:
  • the second selected main component 4021 is further configured to:
  • the second database component 4022 performs a backup-to-main operation of the second node
  • the second database component 4022 re-uses the second node as a standby node and Connect to the new master node.
  • the second preset time threshold is greater than the first preset time threshold.
  • the first master selection component of the first node periodically executes the renewal operation of the resource lock, determines whether the renewal operation is successful within the first preset time threshold, and if so, updates the renewal time of the resource lock to the current time; if not, the first node kills the database process and restarts the database process in read-only mode, triggering the execution of the primary-to-standby operation of the first node; the second master selection component of the second node periodically polls the renewal time of the resource lock, determines whether the time difference between the current time and the renewal time exceeds the second preset time threshold, and if so, triggers the execution of the standby-to-primary operation of the second node.
  • the present invention performs automatic status detection and primary-standby switching in the primary-standby database cluster selection process based on the third-party master selection logic, ensures continuous monitoring and primary-standby switching capabilities, improves the robustness and availability of the primary-standby cluster during the primary-standby switching process, and reduces the time of primary-standby switching.
  • FIG5 is a schematic diagram showing the structure of an embodiment of a computing device according to the present invention.
  • the specific embodiment of the present invention does not limit the specific implementation of the computing device.
  • the computing device may include: a processor (processor) 502, a communication interface (Communications Interface) 504, a memory (memory) 506, and a communication bus 508.
  • processor processor
  • communication interface Communication Interface
  • memory memory
  • the processor 502, the communication interface 504, and the memory 506 communicate with each other via the communication bus 508.
  • the communication interface 504 is configured to communicate with network elements of other devices such as clients or other servers.
  • the processor 502 is configured to execute the program 510, which can specifically execute the relevant steps in the embodiment of the method for selecting a master configured in the master-slave database cluster.
  • the program 510 may include program codes, which include computer operation instructions.
  • the processor 502 may be a central processing unit (CPU), or an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present invention.
  • the one or more processors included in the computing device may be processors of the same type, such as one or more CPUs; or processors of different types, such as one or more CPUs and one or more ASICs.
  • the memory 506 is configured to store the program 510.
  • the memory 506 may include a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), such as at least one disk storage.
  • the program 510 may be specifically configured to enable the processor 502 to perform the following operations:
  • the first master selection component of the first node periodically executes a renewal operation of the resource lock, and determines whether the renewal operation is successful within a first preset time threshold. If so, the renewal time of the resource lock is updated to the current time; if not, the first node kills the database process and restarts the database process in read-only mode, triggering the execution of the master-slave operation of the first node;
  • the second master election component of the second node periodically polls the renewal time of the resource lock to determine whether the time difference between the current time and the renewal time exceeds a second preset time threshold. If so, trigger the execution of the backup master operation of the second node.
  • the program 510 enables the processor to perform the following operations:
  • the first master election component of the first node checks whether a new master node is generated in the cluster
  • the first master election component of the first node detects that a new master node is generated in the cluster, triggering execution of a master-slave operation of the first node;
  • the first master election component of the first node After the database process is restarted in read-only mode, if the first master election component of the first node checks that no new master node is generated in the cluster, it attempts to obtain a resource lock and perform operations as a master node.
  • program 510 enables the processor to perform the following operations:
  • An operation of establishing a master-standby relationship with the second node switched to the master node is performed.
  • the program 510 before triggering the execution of the standby switching master operation of the second node, the program 510 enables the processor to perform the following operations:
  • program 510 enables the processor to perform the following operations:
  • the program 510 enables the processor to perform the following operations:
  • the second node is used as a standby node again and connected to a new master node.
  • the second preset time threshold is greater than the first preset time threshold.
  • the first master selection component of the first node periodically executes the renewal operation of the resource lock, determines whether the renewal operation is successful within the first preset time threshold, and if so, updates the renewal time of the resource lock to the current time; if not, the first node kills the database process and restarts the database process in read-only mode, triggering the execution of the primary-to-standby operation of the first node; the second master selection component of the second node periodically polls the renewal time of the resource lock, determines whether the time difference between the current time and the renewal time exceeds the second preset time threshold, and if so, triggers the execution of the standby-to-primary operation of the second node.
  • the present invention performs automatic status detection and primary-standby switching in the primary-standby database cluster selection process based on the third-party master selection logic, ensures continuous monitoring and primary-standby switching capabilities, improves the robustness and availability of the primary-standby cluster during the primary-standby switching process, and reduces the time of primary-standby switching.
  • An embodiment of the present invention provides a non-volatile computer storage medium, wherein the non-volatile computer storage medium stores at least one executable instruction, and the computer executable instruction can execute the master election method for the master-slave database cluster in any of the above method embodiments.
  • modules in the devices in the embodiments may be adaptively changed and arranged in one or more devices different from the embodiments.
  • the modules or units or components in the embodiments may be combined into one module or unit or component, and in addition they may be divided into a plurality of submodules or subunits or subcomponents. Except that at least some of such features and/or processes or units are mutually exclusive, all features disclosed in this specification (including the accompanying claims, abstracts and drawings) and all processes or units of any method or device disclosed in this manner may be combined in any combination. Unless otherwise expressly stated, each feature disclosed in this specification (including the accompanying claims, abstracts and drawings) may be replaced by an alternative feature providing the same, equivalent or similar purpose.
  • the various component embodiments of the present invention can be implemented in hardware, or in software modules running on one or more processors, or in a combination thereof. It should be understood by those skilled in the art that a microprocessor or digital signal processor (DSP) can be used in practice to implement some or all of the functions of some or all of the components according to an embodiment of the present invention.
  • DSP digital signal processor
  • the present invention can also be implemented as a device or apparatus program (e.g., computer program and computer program product) for executing part or all of the methods described herein.
  • Such a program implementing the present invention can be stored on a computer-readable medium, or can have the form of one or more signals. Such a signal can be downloaded from an Internet website, or provided on a carrier signal, or provided in any other form.
  • the embodiment of the present application provides a master-standby database cluster and a master selection method, a computing device and a storage medium.
  • the master-standby database cluster and the master selection method thereof include: a first master selection component of a first node periodically performs a resource lock renewal operation, determines whether the renewal operation is successful within a first preset time threshold, and if so, updates the resource lock renewal time to the current time; if not, the first node kills the database process and restarts the database process in read-only mode, triggering the execution of the master cutover of the first node;
  • the second master selection component of the second node periodically polls the renewal time of the resource lock to determine whether the time difference between the current time and the renewal time exceeds the second preset time threshold.
  • the second node's standby switching operation is triggered.
  • the above method is used to implement the scheme, and the distributed lock is used as the third-party master selection logic.
  • the third-party master selection logic Based on the third-party master selection logic, automatic status detection and master-slave switching are performed during the master selection process of the master-slave database cluster, ensuring continuous monitoring and master-slave switching capabilities, and improving the robustness and availability of the master-slave cluster during the master-slave switching process.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Quality & Reliability (AREA)
  • Computing Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明公开了一种主备数据库集群及选主方法、计算设备及存储介质，包括：第一节点的第一选主组件定期执行资源锁的续约操作，判断续约操作是否在第一预设时间阈值内成功，若是，则将资源锁的续约时间更新为当前时间；若否，则第一节点杀掉数据库进程，并以只读方式重启数据库进程，触发执行第一节点的主切备操作；第二节点的第二选主组件定期轮询资源锁的续约时间，判断当前时间与续约时间的时间差是否超过第二预设时间阈值，若是，触发执行第二节点的备切主操作。本发明以分布式锁作为第三方选主逻辑，基于该逻辑在主备集群选主过程中进行自动化状态检测和主备切换，确保了持续监测和主备切换能力，提升了主备集群的健壮性及可用性。

Description

主备数据库集群及选主方法、计算设备及存储介质
相关申请的交叉引用
本申请要求在2022年10月21日提交中国专利局、申请号为202211293217.7、申请名称为“主备数据库集群及选主方法、计算设备及计算机存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本发明涉及数据库技术领域，涉及但不限于一种主备数据库集群及选主方法、计算设备及存储介质。
背景技术
随着云原生技术的发展，数据库上云已经成为一种趋势，在容器环境下，主备架构数据库集群的高可用性面临更多的挑战。容器的弹性特性以及容器网络的波动性很容易导致数据库集群挂掉或者出现脑裂，并且对数据库集群进行自动检测及主动修复也会面临更多的难度。比如，在Kubernetes内部域名系统(Domain Name System，DNS)解析出现问题的情况下，主备间的网络将会阻塞，备节点误以为主节点已经挂掉而将自己提升为主节点，进而导致脑裂的发生。
当前常用的容器化方法是基于Kubernetes内置的StatefulSet资源实现，StatefulSet用于实现有状态的应用。例如，在启动MySQL主备集群的yaml(YAML Ain't Markup Language，简称yaml，一种数据序列化语言，可配合大多数编程语言使用，多应用于编写配置文件)文件中，通常会定义一系列包括检测数据库实例状态以及进行主备切换的脚本等，在达到预设的条件的情况下，则触发相对应的脚本，在一定程度上保证了主备集群的高可 用性。
然而，相关技术中数据库集群在主备切换方面仍存在以下问题：一是容易出现脑裂，在主备节点网络连通性出现问题的情况下，备节点会认为主节点已经挂掉了，则触发备升主逻辑，而实际上主节点还在继续提供服务，从而造成“双主”的问题，导致数据库集群异常；二是脚本的“一次性”，由于触发条件以及达到条件后的执行脚本都固化在yaml文件中，当达到触发条件后，集群将按序执行脚本，当执行结束后，由于主备节点发生了切换，原有的脚本将不再使用，无法达到持续使用的效果，如果再次出现异常，则需要进行人工处理；三是在大多数场景下，备升为主的流程所消耗的时间比原来主节点重新启动要长，由于脚本一旦执行将不可逆，直到操作完成，因此，当发现原主启动后，备升主的操作并不能自动终止，导致主备切换过程不可回退；四是容易误判，容器网络的复杂性以及波动性有时会导致脚本的误判，从而错误的触发了主备切换流程，增加了集群不可服务时间。
发明内容
鉴于上述问题，提出了本发明以便提供一种克服上述数据库集群在主备切换过程中存在的健壮性及可用性问题的主备数据库集群及选主方法、计算设备及存储介质。
根据本发明的一个方面，提供了一种主备数据库集群的选主方法，所述方法包括：
第一节点的第一选主组件定期执行资源锁的续约操作，判断续约操作是否在第一预设时间阈值内成功，若是，则将资源锁的续约时间更新为当前时间；若否，则所述第一节点杀掉数据库进程，并以只读方式重启数据库进程，触发执行第一节点的主切备操作；
第二节点的第二选主组件定期轮询资源锁的续约时间，判断当前时间 与续约时间的时间差是否超过第二预设时间阈值，若是，触发执行第二节点的备切主操作。
在一种可选的方式中，在所述第一节点杀掉数据库进程，并以只读方式重启数据库进程之后，所述方法还包括：
所述第一节点的第一选主组件检查集群是否产生新的主节点；
则所述触发执行第一节点的主切备操作具体包括：若所述第一节点的第一选主组件检查集群产生新的主节点，则触发执行所述第一节点的主切备操作；
则在所述以只读方式重启数据库进程之后，所述方法还包括：若所述第一节点的第一选主组件检查集群没有产生新的主节点，则尝试获取资源锁并执行作为主节点的操作。
在一种可选的方式中，所述触发执行第一节点的主切备操作进一步包括：
将第一节点的数据库设置为只读方式；
执行与切换为主节点的第二节点建立主备关系的操作。
在一种可选的方式中，在所述触发执行第二节点的备切主操作之前，所述方法还包括：
执行备切主的准备操作。
在一种可选的方式中，所述执行备切主的准备操作进一步包括：
关闭主备之间的复制操作；
清空主备配置信息；
根据数据库日志确保和所述第一节点的数据库保持一致。
在一种可选的方式中，在所述执行备切主的准备操作之后还包括：
再次判断当前时间与续约时间的时间差是否超过第二预设时间阈值；
若是，则执行第二节点的备切主操作；
若否，则重新将所述第二节点作为备节点并连接新的主节点。
在一种可选的方式中，所述第二预设时间阈值大于第一预设时间阈值。
根据本发明的另一方面，提供了一种主备数据库集群，包括：第一节点和第二节点；
其中，所述第一节点包括：
第一选主组件，配置于定期执行资源锁的续约操作，判断续约操作是否在第一预设时间阈值内成功，若是，则将资源锁的续约时间更新为当前时间；
第一数据库组件，配置于若判断出续约操作没有在第一预设时间阈值内成功，则杀掉数据库进程，并以只读方式重启数据库进程；触发执行第一节点的主切备操作；
所述第二节点包括：
第二选主组件，配置于定期轮询资源锁的续约时间，判断当前时间与续约时间的时间差是否超过第二预设时间阈值；
第二数据库组件，配置于若判断出当前时间与续约时间的时间差超过第二预设时间阈值，触发执行第二节点的备切主操作。
根据本发明的又一方面，提供了一种计算设备，包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；
所述存储器配置于存放至少一可执行指令，所述可执行指令使所述处理器执行上述主备数据库集群的选主方法对应的操作。
根据本发明的再一方面，提供了一种存储介质，所述存储介质中存储有至少一可执行指令，所述可执行指令使处理器执行如上述主备数据库集群的选主方法对应的操作。
根据本发明提供的方案，第一节点的第一选主组件定期执行资源锁的续约操作，判断续约操作是否在第一预设时间阈值内成功，若是，则将资源锁的续约时间更新为当前时间；若否，则所述第一节点杀掉数据库进程， 并以只读方式重启数据库进程，触发执行第一节点的主切备操作；第二节点的第二选主组件定期轮询资源锁的续约时间，判断当前时间与续约时间的时间差是否超过第二预设时间阈值，若是，触发执行第二节点的备切主操作。本发明实现了以分布式锁作为第三方选主逻辑，基于该第三方选主逻辑在主备数据库集群选主过程中进行自动化状态检测和主备切换，确保了持续监测和主备切换能力，在主备切换过程中提升了主备集群的健壮性及可用性。
上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。
附图说明
通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：
图1a示出了本发明实施例的主备数据库集群的选主方法中主切备的流程示意图；
图1b示出了本发明实施例的主备数据库集群的选主方法中备切主的流程示意图；
图2a示出了本发明另一个实施例的主备数据库集群的选主方法中主切备的流程示意图；
图2b示出了本发明另一个实施例的主备数据库集群的选主方法中备切主的流程示意图；
图3示出了本发明又一个实施例的主备数据库集群的选主方法的流程示意图；
图4示出了本发明实施例的主备数据库集群的结构示意图；
图5示出了本发明实施例的计算设备的结构示意图。
具体实施方式
下面将参照附图更详细地描述本发明的示例性实施例。虽然附图中显示了本发明的示例性实施例，然而应当理解，可以以各种形式实现本发明而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本发明，并且能够将本发明的范围完整的传达给本领域的技术人员。
在实施本发明实施例之前，对下文中涉及的技术术语在此进行统一解释：
Kubernetes：又称K8s，提供了应用部署、规划、更新及维护的一种机制，可实现容器集群的自动化部署、自动扩缩容、维护等功能，通常用于管理云平台中多个主机上的容器化的应用，在Kubernetes中，所有的容器均在Pod中运行，一个Pod可以承载一个或者多个相关的容器。
ETCD：是一个分布式一致性键值存储系统，提供了一种可靠的方式来存储需要由分布式系统或机器集群访问的数据，通常用于共享配置和服务发现。在K8s中，ETCD作为K8s默认的存储系统，用于保存所有的集群数据。
Pod：是Kubernetes创建或部署的最小/最简单的基本单位，一个Pod是一个容器环境下的“逻辑主机”，一个Pod可封装一个或多个应用容器。
Leader Election机制：是Kubernetes的一种主从选主方式或机制，在每个实例启动的情况下，都尝试抢占锁资源，抢到锁的实例则成为主节点身份或地位，主节点定期更新当前时间戳，如果主节点未能在给定的时间间隔内更新时间戳则认为其已经失联，此时其它实例以抢占的方式获得锁资源并成为新的主节点。
图1a示出了本发明实施例的主备数据库集群的选主方法中主切备的流程示意图，图1b示出了本发明实施例的主备数据库集群的选主方法中备切主的流程示意图。本方法将选主机制和数据库主备切换逻辑进行结合，形成选主组件(Leader组件)，在数据库集群启动时，将选主组件和数据库进程放置在同一个节点中，由主备节点的Leader组件与分布式锁交互，以共同维护资源锁的方式进行主备切换，包括主切备操作和备切主操作，主切备和备切主为两个并列的操作，二者相互联系、密切配合共同完成主备数据库集群主备切换操作。主切备操作执行主节点成为备节点的步骤，备切主操作执行备节点成为新的主节点的步骤。在主切备操作中，第一选主组件定期执行资源锁的续约操作，如果续约不成功则触发第一节点的主切备操作。在备切主操作中，第二选主组件定期轮询资源锁的续约时间，若当前时间与续约时间的时间差超过预设时间阈值，则触发第二节点的备切主操作。具体地，如图1a所示，主备数据库集群的选主方法中主切备的操作包括以下步骤：
步骤A101：第一节点的第一选主组件定期执行资源锁的续约操作。
数据库集群启动后，数据库主备节点也相应启动，可人工选定或随机初始化一个主节点，本实施例中将当前数据库集群中为主节点的节点称为第一节点，将选主组件(称为第一选主组件)部署于第一节点并作为竞争实体。由此，第一选主组件和第一节点的数据库主服务程序/进程设置于同一个主节点即第一节点中。
本实施例基于Leader Election机制，为了保障数据库主备数据资源的一致性，定义分布式资源锁并通过资源锁的方式更新资源，保证在并发更新资源时数据库主备资源只能被更新一次，并定期更新分布式资源锁以实现主节点的选举。对于拥有分布式资源锁的主节点，主节点通过执行资源锁的续约操作可持续保持其主节点地位或角色。
步骤A102：判断续约操作是否在第一预设时间阈值内成功，若是，则 执行步骤A103；若否，则执行步骤A104。
第一节点的第一选主组件判断续约操作是否在第一预设时间阈值内成功，若在第一预设时间阈值内续约操作成功，则表明第一节点尝试获取锁成功，可持续保持其主节点地位或角色；若在第一预设时间阈值内续约操作未成功，意味着第一节点的网络出现异常，将不再尝试续约操作。需要说明的是，第一预设时间阈值可以是续约超时时间(如10秒)，下文中的第二预设时间阈值可以是租约时间(如15秒)；第二预设时间阈值可以略大于第一预设时间阈值，即，租约时间略大于续约超时时间，以便于后续在第一节点重启数据库进程后，仍有机会重新获取到资源锁。
步骤A103：将资源锁的续约时间更新为当前时间。
将资源锁的续约时间更新为当前时间，保证并发更新资源锁时被更新一次，结合定期更新资源锁的续约时间方式实现主节点的选举制。在步骤A103之后，继续执行步骤A101。
步骤A104：第一节点杀掉数据库进程，并以只读方式重启数据库进程，触发执行第一节点的主切备操作。
当第一节点续约操作失败后，第一节点杀掉或重启数据库进程，并以只读方式重启数据库进程，以保证主备切换过程中数据库的一致性，以及，触发执行第一节点的主切备操作。需要说明的是，可以在第一节点杀掉数据库进程之后或同时以只读方式重启数据库进程。
对于数据库主备切换，在数据库主库宕机或异常的情况下，切断数据库主库的流量并查看数据库备库的复制状态，然后将数据库主库转为备库完成主切备切换，即将数据库流量切向新的主库。
如图1b所示，主备数据库集群的选主方法中备切主的操作包括以下步骤：
步骤B101：第二节点的第二选主组件定期轮询资源锁的续约时间。
对于备节点(称为第二节点)，将选主组件(称为第二选主组件)部 署在各个第二节点，第二选主组件和第二节点的数据库备服务程序/进程设置于同一个备节点即第二节点中。
具体地，第二选主组件通过定期轮询或心跳方式检查分布式资源锁信息中的续约时间。
步骤B102：判断当前时间与续约时间的时间差是否超过第二预设时间阈值，若是，则执行步骤B103；若否，则执行步骤B101。
判断当前时间与分布式资源锁信息中续约时间的时间差是否超过第二预设时间阈值，若超过，则执行步骤B103；若未超过，则表示第一节点(即主节点)的租约未过期，继续执行步骤B101。
步骤B103：触发执行第二节点的备切主操作。
主节点宕机或异常时备节点切换为主节点，对于数据库主备的切换，即将备库切换为主库，通常需要核验或追加数据以解决部分主库数据没有完全同步至备库的问题。
本发明上述实施例提供的方案，第一节点的第一选主组件定期执行资源锁的续约操作，判断续约操作是否在第一预设时间阈值内成功，若是，则将资源锁的续约时间更新为当前时间；若否，则所述第一节点杀掉数据库进程，并以只读方式重启数据库进程，触发执行第一节点的主切备操作；第二节点的第二选主组件定期轮询资源锁的续约时间，判断当前时间与续约时间的时间差是否超过第二预设时间阈值，若是，触发执行第二节点的备切主操作。本发明基于第三方选主逻辑在主备数据库集群选主过程中进行自动化状态检测和主备切换，确保了持续监测和主备切换能力，在主备切换过程中提升了主备集群的健壮性及可用性，并降低了主备切换的时间。
图2a示出了本发明另一个实施例的主备数据库集群的选主方法中主切备的流程示意图。在本实施例的主切备操作过程中，第一节点续约操作失败、重启数据库进程后，先检查集群内是否有新的主节点产生，根据检查结果确定是否执行主切备操作。具体地，如图2a所示，该方法包括以下步 骤：
步骤A201：第一节点的第一选主组件定期执行资源锁的续约操作。
本实施例中，主备节点的选主组件启动后，检查所在节点数据库进程状态，如果没有启动则轮询等待。如果数据库进程启动成功，进入下一步。启动监听服务，用于检测并记录数据库进程状态。初始化一个主节点作为竞争实体，以分布式资源锁的ID作为唯一标识，同时指定租约时间(即第二预设时间阈值，如15s)、续约超时时间(即第一预设时间阈值，如10s)以及重试时间(如1s)等参数。被选为主节点的第一节点每隔1s执行资源锁的续约操作。
步骤A202：判断续约操作是否在第一预设时间阈值内成功，若是，则执行步骤A203；若否，则执行步骤A204。
第一节点的第一选主组件若判断出续约操作在上述续约超时时间内成功，则表明第一节点尝试获取锁成功，可持续保持其主节点地位或角色；若判断出续约操作在上述续约超时时间内未成功，意味着第一节点的网络出现异常，将不再尝试续约操作，进一步的当超过租约时间后，租约将失效。
可选地，所述第二预设时间阈值大于第一预设时间阈值，即租约时间略大于续约超时时间。后续在第一节点重启数据库进程后，仍有机会重新获取到资源锁，继续以主节点的角色响应服务，由此提升了主备集群的健壮性。
步骤A203：将资源锁的续约时间更新为当前时间。
更新分布式资源锁，将分布式资源锁信息中的续约时间更新为当前时间，表明当前时间该分布式资源锁处于占有状态。在步骤A203之后，继续执行步骤A201。
步骤A204：第一节点杀掉数据库进程，并以只读方式重启数据库进程。
第一节点杀掉或重启数据库进程，并以只读方式重启数据库进程，以 保证主备切换过程中数据库的一致性。
步骤A205：第一节点的第一选主组件检查集群是否产生新的主节点。
第一节点的第一选主组件检查集群是否产生新的主节点，以避免在主备数据库集群中出现了两个“大脑”(即主节点)而产生所谓的“脑裂”现象。“脑裂”是指在主备集群中由于出现两个主节点同时提供服务而导致主备节点之间的数据不一致性。若所述第一节点的第一选主组件检查集群产生新的主节点，则触发执行所述第一节点的主切备操作；若没有产生新的主节点，则尝试获取资源锁并执行作为主节点的操作。
步骤A206：触发执行第一节点的主切备操作。
触发执行所述第一节点的主切备操作，即由主节点自动回退到备节点，可降低主备切换的时间，第一节点的主切备操作具体包括：将第一节点的数据库设置为只读方式以及执行与切换为主节点的第二节点建立主备关系的操作。
步骤A207：尝试获取资源锁并执行作为主节点的操作。
若所述第一节点的第一选主组件检查集群没有产生新的主节点，则尝试获取资源锁并执行作为主节点的操作，在第一节点出现异常情况后进行重启，并在尝试获取资源锁成功后，继续作为主节点响应服务，确保主备集群持久的工作，提升了集群的健壮性。
本发明上述实施例提供的方案，在第一节点杀掉数据库进程，并以只读方式重启数据库进程之后，第一节点的第一选主组件检查集群是否产生新的主节点，若否，则尝试获取资源锁并执行作为主节点的操作；若是，则执行第一节点的主切备操作。本发明通过检查集群是否产生新的主节点，可避免在主备数据库集群中出现“脑裂”现象；当产生新的主节点时执行主切备操作，主节点自动回退到备节点，降低了主备切换的时间；当没有产生新的主节点，则尝试获取资源锁并执行作为主节点的操作，以确保主备集群持久工作，提升了集群的健壮性。
图2b示出了本发明另一个实施例的主备数据库集群的选主方法中备切主的流程示意图。具体地，如图2b所示，该方法包括以下步骤：
步骤B201：第二节点的第二选主组件定期轮询资源锁的续约时间。
备节点(第二节点)的选主组件(第二选主组件)定期轮询检查分布式资源锁信息中的续约时间。
步骤B202：判断当前时间与续约时间的时间差是否超过第二预设时间阈值，若是，则执行步骤B203；若否，则执行步骤B201。
判断当前时间与分布式资源锁信息中续约时间的时间差是否超过上述租约时间，若超过，则执行步骤B203；若未超过，则表示第一节点(即主节点)的租约未过期，继续执行步骤B201。
步骤B203：执行备切主的准备操作。
执行备切主的准备操作，包括关闭主备之间的复制操作、清空主备配置信息以及根据数据库日志确保和第一节点的数据库保持一致。
具体地，关闭主备之间的复制操作，以停止主备数据库之间的数据库复制操作，包括主备之间的异步复制、多线程复制以及半同步复制操作。
具体地，清空主备配置信息，包括清除主节点的主备配置信息和备节点的配置信息。
根据数据库日志确保和所述第一节点(即原主节点)的数据库保持一致，由于主备节点数据库的完整性依赖于数据库日志，可以通过数据库日志把丢失的部分数据同步至备节点数据库，具体地，对数据库日志进行分析，获取差异的数据、已经执行的数据以及未写入数据并进行相应的数据库操作以解决主备数据库不一致的问题。
步骤B204：再次判断当前时间与续约时间的时间差是否超过第二预设时间阈值，若是，则执行步骤B205；若否，则执行步骤B206。
在执行备切主的准备操作之后，并不立即进行备切主的操作，而是再次判断当前时间与分布式资源锁信息中的续约时间的时间差是否超过上述 租约时间，通过以再次或二次确认的方式进行备切主操作，充分考虑了原主节点的一些优质服务特性(如硬件、网络、安全及稳定性等)以及主备切换的资源开销或业务影响，尽量对主备数据库集群高可用性的影响降低至最小。
步骤B205：执行第二节点的备切主操作。
执行所述第二节点的主切备操作，即由备节点自动切换为主节点。
步骤B206：重新将第二节点作为备节点并连接新的主节点。
主节点的租约未过期或已经有了新的主节点产生，则不进行主备切换，重新将第二节点作为备节点并连接新的主节点。
本发明上述实施例提供的方案，在执行备切主的准备操作之后，再次判断当前时间与续约时间的时间差是否超过第二预设时间阈值，即当备节点具备成为新的主节点条件之后，并不立即进行备切主的操作，而是再次判断当前时间与分布式资源锁信息中的续约时间的时间差是否超过第二预设时间阈值。本发明通过以再次或二次确认的方式进行备切主操作，对主备数据库集群高可用性的影响降低至最小，实现了主备切换动作的最小化。
图3示出了本发明又一个实施例的主备数据库集群的选主方法的流程示意图。本方法基于Kubernetes的Leader Election机制实现第三方选主逻辑，并引入分布式资源锁实现主备数据库集群的选主方法。并以MySQL数据库为例，将Leader Election机制和MySQL主备切换逻辑进行结合形成选主组件Leader，在MySQL数据库集群启动时，选主组件Leader作为一个单独的容器(container)和MySQL容器(container)放置在同一个Pod中，由主备节点的选主组件Leader和ETCD交互，共同维护一个分布式资源锁(锁)，包括主切备流程(Master流程)和备切主流程(Slave流程)。
在一种可选的方式中，MySQL数据库集群的启动阶段详细流程如下：
步骤一：主备节点选主组件Leader启动后，检查所在节点的MySQL数据库进程的启动状态，如果没有启动则轮询等待；如果MySQL数据库进 程启动成功，则进入步骤二。
步骤二：启动监听服务，用于检测并记录数据库进程状态。例如，启动检测(如health)服务监听MySQL端口(如9001端口)的进程状态，在MySQL进程启动的情况下，则置为真(true)，否则置为假(false)。
步骤三：初始化一个LeaderElector作为竞争实体，以自身ID作为唯一标识，同时指定租约时间(如15秒)、续约超时时间(如10秒)、重试时间(如1秒)等参数。
步骤四：数据库实例Pod默认以00和01结尾，Pod第一次启动默认以00作为主节点，因此，01节点轮询等待00节点获取锁称为leader之后，执行后续步骤。
步骤五：默认00节点执行成为master的操作。
可选地，步骤五进一步包括以下步骤：
尝试获取锁，若获得则继续，若未获得则继续执行轮询操作，获取之后，分布式锁的信息如表1所示：
表1
执行成为master的SQL操作。
执行renew操作，更新租约，以持续保持leadership地位。
步骤六：01节点经过步骤四检查到00节点已经获取到锁之后，开始执行成为slave的操作。
可选地，步骤六进一步包括以下步骤：
将自己设置为只读状态。
执行SQL语句与master建立主从关系。
检查租约状态，判断自己是否可以获得锁。
进一步的，参见图3所示的过程检测及主备切换详细流程，对拥有锁的master节点来说：
步骤一：每秒钟执行renew操作，更新分布式锁，将renewTime更新为当前时间。
步骤二：如renew操作超过10秒还未成功，意味着该节点网络发生问题，将不再尝试执行renew操作，这意味着超过15s后，租约将失效。
步骤三：节点杀掉(kill)mysqld进程，并自我退出。
步骤四：Kubernetes重新拉起服务之后，mysqld进程将以只读方式重新启动。
步骤五：leader组件重启后尝试重新检查集群是否有新的leader产生。
可选地，步骤五进一步包括以下步骤：
如已经有新的leader产生，则执行启动过程上述步骤六操作。
如发现没有新的leader产生，意味着当前还没有新的主节点，则尝试获取锁并执行成为master的操作。
进一步的，对于备节点来说：
步骤一：每隔1秒轮询检查分布式锁信息。
步骤二：检查其中的renewTime。
可选地，步骤二进一步包括以下步骤：
如果renewTime和当前时间相比未超过15秒，意味着leader节点租约未过期，则退出，轮询操作步骤二。
如果超过15秒，则表示当前没有节点获得锁。备节点认为主节点可能发生了异常，则执行下一步。
步骤三：执行备升主的准备操作。
可选地，步骤三进一步包括以下步骤：
关闭备升主的准备操作。
清空主从配置信息。
应用binlog日志，确保和原主节点数据库保持一致。
步骤四：具备了成为主节点的条件之后，并不立即进行备升主操作，而是再次尝试获取资源锁。
可选地，步骤四进一步包括以下步骤：
如果获取到锁，则确定当前没有新的主节点产生，开始执行备升主操作。
如果没有获取到资源锁，说明已经有了新的主节点产生，则重新将自身作为备节点连向新的主节点。
步骤五：主备切换结束，新的主节点和备节点按上述逻辑继续检测。
本发明上述实施例提供的方案，本方法基于Kubernetes的Leader Election机制实现第三方选主逻辑，并引入分布式资源锁实现主备数据库集群的选主方法。将Leader Election机制和数据库主备切换逻辑进行结合形成选主组件Leader，选主组件Leader作为一个单独的容器和数据库容器放置在同一个Pod中，由主备节点的选主组件Leader和ETCD交互，共同维护一个分布式资源锁(锁)。本发明基于第三方选主逻辑在主备数据库集群选主过程中进行自动化状态检测和主备切换，确保了持续监测和主备切换能力，在主备切换过程中提升了主备集群的健壮性及可用性，并降低了主备切换的时间。
图4示出了本发明实施例的主备数据库集群的结构示意图。主备数据库集群400包括第一节点401和第二节点402；其中，所述第一节点401包括：第一选主组件4011和第一数据库组件4012；所述第二节点402包括：第二选主组件4021和第二数据库组件4022。
所述第一选主组件4011，配置于定期执行资源锁的续约操作，判断续约操作是否在第一预设时间阈值内成功，若是，则将资源锁的续约时间更新为当前时间；
所述第一数据库组件4012，配置于若判断出续约操作没有在第一预设时间阈值内成功，则杀掉数据库进程，并以只读方式重启数据库进程；触发执行第一节点的主切备操作；
所述第二选主组件4021，配置于定期轮询资源锁的续约时间，判断当前时间与续约时间的时间差是否超过第二预设时间阈值；
所述第二数据库组件4022，配置于若判断出当前时间与续约时间的时间差超过第二预设时间阈值，触发执行第二节点的备切主操作。
在一种可选的方式中，所述第一选主组件4011进一步配置于：
检查集群是否产生新的主节点，若是，则触发执行所述第一节点的主切备操作；若否，则尝试获取资源锁并执行作为主节点的操作。
在一种可选的方式中，所述第一数据库组件4012进一步配置于：
将第一节点的数据库设置为只读方式；
执行与切换为主节点的第二节点建立主备关系的操作。
在一种可选的方式中，所述第二数据库组件4022进一步配置于：
执行备切主的准备操作。
在一种可选的方式中，所述第二数据库组件4022进一步配置于：
关闭主备之间的复制操作；
清空主备配置信息；
根据数据库日志确保和所述第一节点的数据库保持一致。
在一种可选的方式中，所述第二选主组件4021进一步配置于：
再次判断当前时间与续约时间的时间差是否超过第二预设时间阈值；
若是，则所述第二数据库组件4022执行第二节点的备切主操作；
若否，则所述第二数据库组件4022重新将所述第二节点作为备节点并 连接新的主节点。
在一种可选的方式中，所述第二预设时间阈值大于第一预设时间阈值。
本发明上述实施例提供的方案，第一节点的第一选主组件定期执行资源锁的续约操作，判断续约操作是否在第一预设时间阈值内成功，若是，则将资源锁的续约时间更新为当前时间；若否，则所述第一节点杀掉数据库进程，并以只读方式重启数据库进程，触发执行第一节点的主切备操作；第二节点的第二选主组件定期轮询资源锁的续约时间，判断当前时间与续约时间的时间差是否超过第二预设时间阈值，若是，触发执行第二节点的备切主操作。本发明基于第三方选主逻辑在主备数据库集群选主过程中进行自动化状态检测和主备切换，确保了持续监测和主备切换能力，在主备切换过程中提升了主备集群的健壮性及可用性，并降低了主备切换的时间。
图5示出了本发明计算设备实施例的结构示意图，本发明具体实施例并不对计算设备的具体实现做限定。
如图5所示，该计算设备可以包括：处理器(processor)502、通信接口(Communications Interface)504、存储器(memory)506、以及通信总线508。
其中：处理器502、通信接口504、以及存储器506通过通信总线508完成相互间的通信。通信接口504，配置于与其它设备比如客户端或其它服务器等的网元通信。处理器502，配置于执行程序510，具体可以执行上述配置于主备数据库集群的选主方法实施例中的相关步骤。
具体地，程序510可以包括程序代码，该程序代码包括计算机操作指令。
处理器502可能是中央处理器CPU，或者是特定集成电路ASIC(Application Specific Integrated Circuit)，或者是被配置成实施本发明实施例的一个或多个集成电路。计算设备包括的一个或多个处理器，可以是同一类型的处理器，如一个或多个CPU；也可以是不同类型的处理器，如一个或多个CPU以及一个或多个ASIC。
存储器506，配置于存放程序510。存储器506可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。
程序510具体可以配置于使得处理器502执行以下操作：
第一节点的第一选主组件定期执行资源锁的续约操作，判断续约操作是否在第一预设时间阈值内成功，若是，则将资源锁的续约时间更新为当前时间；若否，则所述第一节点杀掉数据库进程，并以只读方式重启数据库进程，触发执行第一节点的主切备操作；
第二节点的第二选主组件定期轮询资源锁的续约时间，判断当前时间与续约时间的时间差是否超过第二预设时间阈值，若是，触发执行第二节点的备切主操作。
在一种可选的方式中，在所述第一节点杀掉数据库进程，并以只读方式重启数据库进程之后，所述程序510使所述处理器执行以下操作：
所述第一节点的第一选主组件检查集群是否产生新的主节点；
若所述第一节点的第一选主组件检查集群产生新的主节点，则触发执行所述第一节点的主切备操作；
则在所述以只读方式重启数据库进程之后，若所述第一节点的第一选主组件检查集群没有产生新的主节点，则尝试获取资源锁并执行作为主节点的操作。
在一种可选的方式中，所述程序510使所述处理器执行以下操作：
将第一节点的数据库设置为只读方式；
执行与切换为主节点的第二节点建立主备关系的操作。
在一种可选的方式中，在所述触发执行第二节点的备切主操作之前，所述程序510使所述处理器执行以下操作：
执行备切主的准备操作。
在一种可选的方式中，所述程序510使所述处理器执行以下操作：
关闭主备之间的复制操作；
清空主备配置信息；
根据数据库日志确保和所述第一节点的数据库保持一致。
在一种可选的方式中，在所述执行备切主的准备操作之后，所述程序510使所述处理器执行以下操作：
再次判断当前时间与续约时间的时间差是否超过第二预设时间阈值；
若是，则执行第二节点的备切主操作；
若否，则重新将所述第二节点作为备节点并连接新的主节点。
在一种可选的方式中，所述第二预设时间阈值大于第一预设时间阈值。
本发明上述实施例提供的方案，第一节点的第一选主组件定期执行资源锁的续约操作，判断续约操作是否在第一预设时间阈值内成功，若是，则将资源锁的续约时间更新为当前时间；若否，则所述第一节点杀掉数据库进程，并以只读方式重启数据库进程，触发执行第一节点的主切备操作；第二节点的第二选主组件定期轮询资源锁的续约时间，判断当前时间与续约时间的时间差是否超过第二预设时间阈值，若是，触发执行第二节点的备切主操作。本发明基于第三方选主逻辑在主备数据库集群选主过程中进行自动化状态检测和主备切换，确保了持续监测和主备切换能力，在主备切换过程中提升了主备集群的健壮性及可用性，并降低了主备切换的时间。
本发明实施例提供了一种非易失性计算机存储介质，所述非易失性计算机存储介质存储有至少一可执行指令，该计算机可执行指令可执行上述任意方法实施例中的主备数据库集群的选主方法。
在此提供的算法或显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明实施例也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的 最佳实施方式。
在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。
类似地，应当理解，为了精简本发明并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明实施例的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。
本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
此外，本领域的技术人员能够理解，尽管在此的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。
应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。上述实施例中的步骤，除有特殊说明外，不应理解为对执行顺序的限定。
工业实用性
本申请实施例提供了一种主备数据库集群及选主方法、计算设备及存储介质，主备数据库集群及其选主方法包括：第一节点的第一选主组件定期执行资源锁的续约操作，判断续约操作是否在第一预设时间阈值内成功，若是，则将资源锁的续约时间更新为当前时间；若否，则所述第一节点杀掉数据库进程，并以只读方式重启数据库进程，触发执行第一节点的主切 备操作；第二节点的第二选主组件定期轮询资源锁的续约时间，判断当前时间与续约时间的时间差是否超过第二预设时间阈值，若是，触发执行第二节点的备切主操作。采用上述方法实现方案，实现了以分布式锁作为第三方选主逻辑，基于该第三方选主逻辑在主备数据库集群选主过程中进行自动化状态检测和主备切换，确保了持续监测和主备切换能力，在主备切换过程中提升了主备集群的健壮性及可用性。

Claims (10)

  1. 一种主备数据库集群的选主方法，所述方法包括：
    第一节点的第一选主组件定期执行资源锁的续约操作，判断续约操作是否在第一预设时间阈值内成功，若是，则将资源锁的续约时间更新为当前时间；若否，则所述第一节点杀掉数据库进程，并以只读方式重启数据库进程，触发执行第一节点的主切备操作；
    第二节点的第二选主组件定期轮询资源锁的续约时间，判断当前时间与续约时间的时间差是否超过第二预设时间阈值，若是，触发执行第二节点的备切主操作。
  2. 根据权利要求1所述的方法，其中，在所述第一节点杀掉数据库进程，并以只读方式重启数据库进程之后，所述方法还包括：
    所述第一节点的第一选主组件检查集群是否产生新的主节点；
    则所述触发执行第一节点的主切备操作具体包括：
    若所述第一节点的第一选主组件检查集群产生新的主节点，则触发执行所述第一节点的主切备操作；
    则在所述以只读方式重启数据库进程之后，所述方法还包括：若所述第一节点的第一选主组件检查集群没有产生新的主节点，则尝试获取资源锁并执行作为主节点的操作。
  3. 根据权利要求1所述的方法，其中，所述触发执行第一节点的主切备操作进一步包括：
    将第一节点的数据库设置为只读方式；
    执行与切换为主节点的第二节点建立主备关系的操作。
  4. 根据权利要求1所述的方法，其中，在所述触发执行第二节点的备切主操作之前，所述方法还包括：
    执行备切主的准备操作。
  5. 根据权利要求4所述的方法，其中，所述执行备切主的准备操作进一步包括：
    关闭主备之间的复制操作；
    清空主备配置信息；
    根据数据库日志确保和所述第一节点的数据库保持一致。
  6. 根据权利要求4所述的方法，其中，在所述执行备切主的准备操作之后还包括：
    再次判断当前时间与续约时间的时间差是否超过第二预设时间阈值；
    若是，则执行第二节点的备切主操作；
    若否，则重新将所述第二节点作为备节点并连接新的主节点。
  7. 根据权利要求1所述的方法，其中，所述第二预设时间阈值大于第一预设时间阈值。
  8. 一种主备数据库集群，包括：第一节点和第二节点；
    其中，所述第一节点包括：
    第一选主组件，配置于定期执行资源锁的续约操作，判断续约操作是否在第一预设时间阈值内成功，若是，则将资源锁的续约时间更新为当前时间；
    第一数据库组件，配置于若判断出续约操作没有在第一预设时间阈值内成功，则杀掉数据库进程，并以只读方式重启数据库进程；触发执行第一节点的主切备操作；
    所述第二节点包括：
    第二选主组件，配置于定期轮询资源锁的续约时间，判断当前时间与续约时间的时间差是否超过第二预设时间阈值；
    第二数据库组件，配置于若判断出当前时间与续约时间的时间差超过第二预设时间阈值，触发执行第二节点的备切主操作。
  9. 一种计算设备，包括：处理器、存储器、通信接口和通信总线，所 述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；
    所述存储器配置于存放至少一可执行指令，所述可执行指令使所述处理器执行如权利要求1-7中任一项所述的主备数据库集群的选主方法对应的操作。
  10. 一种存储介质，所述存储介质中存储有至少一可执行指令，所述可执行指令使处理器执行如权利要求1-7中任一项所述的主备数据库集群的选主方法对应的操作。
PCT/CN2023/126010 2022-10-21 2023-10-23 主备数据库集群及选主方法、计算设备及存储介质 WO2024083259A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202211293217.7A CN116263727A (zh) 2022-10-21 2022-10-21 主备数据库集群及选主方法、计算设备及计算机存储介质
CN202211293217.7 2022-10-21

Publications (1)

Publication Number Publication Date
WO2024083259A1 true WO2024083259A1 (zh) 2024-04-25

Family

ID=86722781

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/126010 WO2024083259A1 (zh) 2022-10-21 2023-10-23 主备数据库集群及选主方法、计算设备及存储介质

Country Status (2)

Country Link
CN (1) CN116263727A (zh)
WO (1) WO2024083259A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116263727A (zh) * 2022-10-21 2023-06-16 中移(苏州)软件技术有限公司 主备数据库集群及选主方法、计算设备及计算机存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180331888A1 (en) * 2015-12-08 2018-11-15 Alibaba Group Holding Limited Method and apparatus for switching service nodes in a distributed storage system
CN113497737A (zh) * 2021-05-13 2021-10-12 曙光信息产业(北京)有限公司 系统拓扑结构维护方法、装置、计算机设备和存储介质
CN114238495A (zh) * 2021-11-25 2022-03-25 中国建设银行股份有限公司 数据库主备集群切换方法、装置、计算机设备及存储介质
CN114860848A (zh) * 2022-07-06 2022-08-05 北京奥星贝斯科技有限公司 分布式数据库系统的选主方法及装置
CN116263727A (zh) * 2022-10-21 2023-06-16 中移(苏州)软件技术有限公司 主备数据库集群及选主方法、计算设备及计算机存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180331888A1 (en) * 2015-12-08 2018-11-15 Alibaba Group Holding Limited Method and apparatus for switching service nodes in a distributed storage system
CN113497737A (zh) * 2021-05-13 2021-10-12 曙光信息产业(北京)有限公司 系统拓扑结构维护方法、装置、计算机设备和存储介质
CN114238495A (zh) * 2021-11-25 2022-03-25 中国建设银行股份有限公司 数据库主备集群切换方法、装置、计算机设备及存储介质
CN114860848A (zh) * 2022-07-06 2022-08-05 北京奥星贝斯科技有限公司 分布式数据库系统的选主方法及装置
CN116263727A (zh) * 2022-10-21 2023-06-16 中移(苏州)软件技术有限公司 主备数据库集群及选主方法、计算设备及计算机存储介质

Also Published As

Publication number Publication date
CN116263727A (zh) 2023-06-16

Similar Documents

Publication Publication Date Title
JP7362650B2 (ja) タスク処理方法、装置及びシステム
US10020980B2 (en) Arbitration processing method after cluster brain split, quorum storage apparatus, and system
US7017082B1 (en) Method and system for a process manager
US6983397B2 (en) Method, system, and program for error handling in a dual adaptor system where one adaptor is a master
US9348706B2 (en) Maintaining a cluster of virtual machines
WO2024083259A1 (zh) 主备数据库集群及选主方法、计算设备及存储介质
EP3550436A1 (en) Method and apparatus for detecting and recovering fault of virtual machine
WO2016180005A1 (zh) 处理虚拟机集群的方法和计算机系统
US11461198B2 (en) Method to disable or reboot unresponsive device with active uplink in a ring network
US20220138036A1 (en) Safely recovering workloads within a finite timeframe from unhealthy cluster nodes
EP3499373B1 (en) Method and apparatus for processing process
JP6421516B2 (ja) サーバ装置、冗長構成サーバシステム、情報引継プログラム及び情報引継方法
US10992770B2 (en) Method and system for managing network service
JP5435205B2 (ja) マルチノードシステム、ノード、メモリダンプ処理方法、及びプログラム
JP2002149437A (ja) ソフトウェア再起動方法
US7930338B2 (en) Observer for grid-enabled software applications
US20240036968A1 (en) Managing service configuration attempts for a host in response to failure
US11921605B2 (en) Managing applications in a cluster
JP2005043960A (ja) サーバ、オンラインパッチ処理方法及びプログラム
JP2022174535A (ja) クラスタシステム、監視システム、監視方法、及びプログラム
CN116723196A (zh) 一种服务器集群的健康监测方法及装置
CN117640349A (zh) 网络附加存储系统集群的故障恢复方法、装置及主机设备
CN117971392A (zh) 一种虚拟机防脑裂方法及服务器

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23879244

Country of ref document: EP

Kind code of ref document: A1