Method, storage medium and device for automatic failover of database cluster
By acquiring fault signals in the database cluster and selecting the highest-priority standby database for failover, the problem of arbitrator impulsive failure is solved, thus improving the availability and stability of the system.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- CETC JINCANG (BEIJING) TECH CO LTD
- Filing Date
- 2022-12-27
- Publication Date
- 2026-06-05
AI Technical Summary
In existing technologies, during the automatic failover process of database clusters, the arbitrator may die due to impulsiveness, rendering the automatic failover system unavailable and affecting the availability of the cluster and the system.
By acquiring the fault signal of the primary database, failover commands are sent to multiple standby databases to attempt to obtain feedback information. If this fails, attempts are made to connect to other standby databases. If this also fails, the arbitrator is stopped from running. After confirming that the target standby database has been successfully upgraded to the primary database, the arbitrator configuration status is updated, and the next standby database in the order of priority is selected until success is achieved.
This prevented the arbitrator from dying impulsively, improved the availability of the database cluster and automatic failover system, and ensured the stability and reliability of the system.
Smart Images

Figure CN116126970B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of databases, and in particular to automatic failover methods, storage media, and devices for database clusters. Background Technology
[0002] In a failover system using an arbitrator (observer), the automatic failover process in the Oracle solution is as follows: Figure 1 As shown. When the primary database is objectively absent (i.e., the active observer and all standby databases confirm the primary database's absence), the active observer sends a "failover command" to the target standby database. Upon receiving the "failover command" from the active observer, the target standby database updates its configuration state and promotes itself to primary. Once successfully promoted to primary, the target standby database sends a "failover success response" to the active observer. If the arbitrator receives the "failover success response" from the target standby database, it updates its configuration state and enters a periodic Ping (and propagates the configuration state). If the arbitrator does not receive the "failover success response" from the target standby database within a timeout period, it automatically "dies."
[0003] In Oracle's automatic failover flowchart, if the active observer sends a failover command to the target standby database after the primary database becomes objectively absent, and does not receive a "failover success response" from the target standby database within a timeout period, it will "die" on its own. This operation can lead to three outcomes: 1. The target standby database has actually successfully become the primary database, but the active observer has not received a "failover success response," and then the active observer "dies." If redundant observers exist in the system, they will register with the new primary database as new active observers. In this case, the cluster is available, and the automatic failover system is also available. 2. The target standby database has actually successfully become the primary database, but the active observer has not received a "failover success response," and then the active observer "dies." If there are no redundant observers in the system, no new active observers can be generated. In this case, the cluster is available, but the automatic failover system is unavailable due to the lack of active observers. 3. The target standby database has indeed failed to become the primary database, and then the active observer "dies." Since the cluster is without a primary database, even if redundant observers exist, they cannot obtain authorization from the primary database to become new active observers. In this case, the cluster is unavailable due to the lack of a primary database, and the automatic failover system is also unavailable due to the lack of active observers. Summary of the Invention
[0004] One object of the present invention is to provide an automatic failover method, storage medium and device for database clusters that can solve any of the above problems.
[0005] A further objective of this invention is to enhance the stability of the automatic failover system.
[0006] Specifically, this invention provides an automatic failover method for a database cluster, the database cluster including an arbitrator, a primary database, and multiple standby databases. The arbitrator is used to observe the operating status of the primary and standby databases. The automatic failover method includes:
[0007] Obtain fault signals from the primary database;
[0008] Send failover commands to the target standby database among multiple standby databases;
[0009] Attempt to obtain feedback information sent by the target standby database, including the execution results of the target standby database in response to the failover command;
[0010] If the attempt fails, try connecting to other standby databases besides the target standby database.
[0011] If attempts to connect to other backup databases fail, the arbitrator will stop operating.
[0012] Furthermore, after attempting to obtain feedback information sent by the target backup database, the process also includes:
[0013] If the attempt is successful, adjust the running status of the database cluster based on the feedback information.
[0014] Furthermore, the steps for adjusting the operating status of the database cluster based on feedback information include:
[0015] Determine if the feedback message indicates that the failover command failed to execute.
[0016] If so, select the next-ranked synchronous standby database among the multiple standby databases as the new target standby database, and send a failover command to the new target standby database.
[0017] Furthermore, after determining whether the feedback information indicates a failure in the execution of the failover command, the process also includes:
[0018] If so, promote the target backup database to the primary database and update the arbitrator's configuration status.
[0019] Furthermore, the step of attempting to connect to other standby databases besides the target standby database also includes:
[0020] If the attempt is successful, obtain the response information from other backup databases;
[0021] Determine whether the target backup database has been successfully upgraded to the primary database based on the response information;
[0022] If so, update the arbitrator's configuration status.
[0023] Furthermore, after determining whether the target standby database has been successfully upgraded to the primary database based on the response information, the process also includes:
[0024] If the target standby database fails to be upgraded to the primary database, then try to select the next-ranked synchronous standby database as the new target standby database.
[0025] If the attempt is successful, a failover command is sent to the new target standby database.
[0026] Furthermore, the steps to attempt to select the next synchronous backup database as the new target backup database include:
[0027] If the attempt fails, continue to select the next synchronous standby database in the order of the new target standby database as the target standby database to be executed, until an executable target standby database is obtained, and then send a failover command to the executable target standby database.
[0028] Furthermore, the target backup database is determined by pre-setting priorities for the synchronous backup databases among multiple backup databases, with the synchronous backup database having the highest priority being the target backup database.
[0029] According to another aspect of the present invention, a machine-readable storage medium is also provided, on which a machine-executable program is stored, which, when executed by a processor, implements any of the above-described automatic failover methods for database clusters.
[0030] According to another aspect of the present invention, a computer device is also provided, including a memory, a processor, and a machine-executable program stored in the memory and running on the processor, wherein the processor executes the machine-executable program to implement any of the above-described automatic failover methods for database clusters.
[0031] This invention discloses an automatic failover method for a database cluster. The database cluster includes an arbitrator, a primary database, and multiple standby databases. The arbitrator is used to observe the operational status of the primary and standby databases. The automatic failover method includes: acquiring a fault signal from the primary database; sending a failover command to a target standby database among the multiple standby databases; attempting to acquire feedback information from the target standby database, including the execution result of the target standby database in response to the failover command; if the attempt fails, attempting to connect to other standby databases besides the target standby database; and stopping the arbitrator if attempts to connect to other standby databases fail. This invention's automatic failover method for a database cluster avoids unavailability caused by the arbitrator's impulsive "death," significantly improving the availability of the cluster and the automatic failover system.
[0032] The above and other objects, advantages and features of the present invention will become more apparent to those skilled in the art from the following detailed description of specific embodiments of the invention in conjunction with the accompanying drawings. Attached Figure Description
[0033] The following sections will describe some specific embodiments of the invention in detail by way of example and not limitation, with reference to the accompanying drawings. The same reference numerals in the drawings denote the same or similar parts or portions. Those skilled in the art should understand that these drawings are not necessarily drawn to scale. In the drawings:
[0034] Figure 1 This is a flowchart illustrating the steps of automatic failover in existing technologies;
[0035] Figure 2 This is a flowchart illustrating the steps of an automatic failover method for a database cluster according to an embodiment of the present invention;
[0036] Figure 3 This is a flowchart illustrating the steps of an automatic failover method for a database cluster according to another embodiment of the present invention;
[0037] Figure 4 This is a flowchart illustrating the steps of an automatic failover method for a database cluster according to yet another embodiment of the present invention;
[0038] Figure 5 This is a flowchart illustrating the steps of an automatic failover method for a database cluster according to yet another embodiment of the present invention;
[0039] Figure 6 This is a flowchart illustrating the steps of an automatic failover method for a database cluster according to yet another embodiment of the present invention;
[0040] Figure 7 This is a schematic diagram of a machine-readable storage medium according to an embodiment of the present invention; and
[0041] Figure 8 This is a schematic diagram of a computer device according to an embodiment of the present invention. Detailed Implementation
[0042] Figure 2 This is a flowchart illustrating the steps of an automatic failover method for a database cluster according to an embodiment of the present invention. The database cluster in this embodiment includes an arbitrator, a primary database, and multiple standby databases. The arbitrator is used to observe the operating status of the primary and standby databases. Figure 2 As shown, the automatic failover method in this embodiment includes:
[0043] Step S102: Obtain the fault signal of the primary database. The fault signal of the primary database can be an objective absence signal of the primary database.
[0044] Step S104: Send a failover command to the target standby database among the multiple standby databases. The target standby database is determined by pre-setting priorities for the synchronous standby databases among the multiple standby databases, with the synchronous standby database having the highest priority being the target standby database.
[0045] Step S106: Attempt to obtain feedback information sent by the target standby database. The feedback information includes the execution result of the target standby database in response to the failover command. If the attempt fails, proceed to step S108.
[0046] Step S108: Attempt to connect to other standby databases besides the target standby database. If the attempt fails, proceed to step S110.
[0047] Step S110: Stop the arbitrator's operation and enter the periodic Ping state, and through...
[0048] The automatic failover method for the database cluster in this embodiment avoids the unavailability of automatic failover due to the impulsive "death" of the arbitrator, and greatly improves the availability of the cluster and the automatic failover system.
[0049] Figure 3 This is a flowchart illustrating the steps of an automatic failover method for a database cluster according to another embodiment of the present invention. Figure 3 As shown, the automatic failover method for the database cluster in this embodiment includes:
[0050] Step S202: Obtain the fault signal from the master database.
[0051] Step S204: Send a failover command to the target standby database among the multiple standby databases.
[0052] Step S206: Attempt to obtain feedback information sent by the target standby database. The feedback information includes the target standby database's execution result of the failover command. If the attempt fails, proceed to step S208. If the attempt succeeds, proceed to step S212.
[0053] Step S208: Attempt to connect to other standby databases besides the target standby database. If the attempt fails, proceed to step S210.
[0054] Step S210: Stop the arbitrator's operation.
[0055] Step S212: Adjust the running status of the database cluster based on the feedback information.
[0056] Figure 4 This is a flowchart illustrating the steps of an automatic failover method for a database cluster according to another embodiment of the present invention. Figure 4 As shown, the step of adjusting the operating state of the database cluster based on feedback information in the automatic failover method for the database cluster in this embodiment includes:
[0057] Step S302: Determine if the feedback information indicates that the failover command failed to execute. If yes, proceed to step S304. If no, proceed to step S308.
[0058] Step S304: Select the synchronous backup database that is next in order to the target backup database among multiple backup databases as the new target backup database.
[0059] Step S306: Send a failover command to the new target backup database.
[0060] Step S308: Promote the target standby database to the primary database and update the arbitrator's configuration status.
[0061] Figure 5 This is a flowchart illustrating the steps of an automatic failover method for a database cluster according to another embodiment of the present invention. Figure 5 As shown, the automatic failover method for the database cluster in this embodiment includes:
[0062] Step S402: Obtain the fault signal from the master database.
[0063] Step S404: Send a failover command to the target standby database among the multiple standby databases.
[0064] Step S406: Attempt to obtain feedback information sent by the target backup database. If the attempt fails, proceed to step S408. If the attempt succeeds, proceed to step S412.
[0065] Step S408: Attempt to connect to other standby databases besides the target standby database. If the attempt fails, proceed to step S410.
[0066] Step S410: Stop the arbitrator's operation.
[0067] Step S412: Obtain response information from other backup databases.
[0068] Step S414: Determine whether the target standby database has been successfully upgraded to the primary database based on the response information. If yes, proceed to step S416.
[0069] Step S416: Update the arbitrator's configuration status.
[0070] Figure 6 This is a flowchart illustrating the steps of an automatic failover method for a database cluster according to another embodiment of the present invention. Figure 6 As shown, the automatic failover method for the database cluster in this embodiment includes:
[0071] Step S502: Obtain the fault signal from the master database.
[0072] Step S504: Send a failover command to the target standby database among the multiple standby databases.
[0073] Step S506: Attempt to obtain feedback information sent by the target backup database. If the attempt fails, proceed to step S508.
[0074] Step S508: Attempt to connect to other standby databases besides the target standby database. If the attempt fails, proceed to step S510. If the attempt succeeds, proceed to step S512.
[0075] Step S510: Stop the arbitrator's operation.
[0076] Step S512: Obtain response information from other backup databases.
[0077] Step S514: Determine whether the target standby database has been successfully upgraded to the primary database based on the response information. If yes, proceed to step S516. If no, proceed to step S518.
[0078] Step S516: Update the arbitrator's configuration status.
[0079] Step S518: Attempt to select the next-ranked synchronous backup database as the new target backup database. If the attempt is successful, proceed to step S520. If the attempt fails, proceed to step S522.
[0080] Step S520: Send a failover command to the new target backup database.
[0081] Step S522: Continue to select the next-order synchronous standby database in the new target standby database as the target standby database to be executed, until an executable target standby database is obtained, and send a failover command to the executable target standby database.
[0082] In this embodiment of the automatic failover method for the database cluster, after confirming the objective absence of the primary database, the arbitrator sends a "failover command" to the target standby database. Upon receiving the "failover command" from the arbitrator, the target standby database updates its configuration status and promotes itself to primary. If the target standby database successfully becomes primary, it sends a "failover success response" to the arbitrator; if the promotion fails, it sends a "failover failure response" to the arbitrator.
[0083] If the arbitrator receives a "failover success response" from the target standby database, it will update the configuration status, enter a periodic Ping, and propagate the configuration status.
[0084] If the arbitrator receives a "failover failure response" from the target backup database, it will select the next highest priority (the higher the priority, the earlier the ranking) synchronous backup database as the new target backup database.
[0085] If the arbitrator does not receive a "failover success / failure response" within the timeout period, it will ping other backup databases. If it cannot ping other backup databases, it means that the arbitrator is objectively absent, and the arbitrator itself is "dead".
[0086] If other standby databases can be pinged, the arbitrator determines whether the target standby database has successfully become the primary database based on their responses. If the target standby database has successfully become the primary database, the arbitrator updates its configuration status and enters periodic ping. Otherwise, the arbitrator selects the next synchronous standby database in the order of priority as the new target standby database. If a new target standby database is selected, a failover is initiated to the new target standby database.
[0087] The automatic failover method for database clusters in this embodiment solves the problems of "adverse outcome 2 (i.e., the automatic failover system becomes unavailable)" and "adverse outcome 3 (i.e., the cluster becomes unavailable, and the automatic failover system becomes unavailable)" caused by the "impulsive death of active observers" in the above-mentioned Oracle solution. This embodiment greatly improves the availability of the cluster and the automatic failover system.
[0088] This embodiment also provides a machine-readable storage medium and a computer device. Figure 7 This is a schematic diagram of a machine-readable storage medium according to an embodiment of the present invention. Figure 8 This is a schematic diagram of a computer device according to an embodiment of the present invention.
[0089] The machine-readable storage medium 40 stores a machine-executable program 41 thereon, which, when executed by a processor, implements the automatic failover method for the database cluster of any of the above embodiments.
[0090] Computer device 50 may include memory 520, processor 510 and machine-executable program 41 stored on memory 520 and running on processor 510, and processor 510 implements the automatic failover method of database cluster of any of the above embodiments when executing machine-executable program 41.
[0091] It should be noted that the logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be specifically implemented in any machine-readable storage medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-based system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).
[0092] For the purposes of this embodiment, the machine-readable storage medium 40 can be any means capable of containing, storing, communicating, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, the computer-readable medium 40 can even be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.
[0093] It should be understood that various parts of the present invention 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.
[0094] Computer device 50 can be, for example, a server, desktop computer, laptop computer, tablet computer, or smartphone. In some examples, computer device 50 can be a cloud computing node. Computer device 50 can be described in the general context of computer system executable instructions (such as program modules) executed by a computer system. Typically, program modules can include routines, programs, object programs, components, logic, data structures, etc., that perform specific tasks or implement specific abstract data types. Computer device 50 can be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices linked through a communication network. In a distributed cloud computing environment, program modules can reside on local or remote computing system storage media, including storage devices.
[0095] Computer device 50 may include a processor 510 adapted to execute stored instructions and a memory 520 that provides temporary storage space for the operation of said instructions during operation. The processor 510 may be a single-core processor, a multi-core processor, a computing cluster, or any other configuration. The memory 520 may include random access memory (RAM), read-only memory, flash memory, or any other suitable storage system.
[0096] The processor 510 can also be linked via a system interconnect to a display interface suitable for connecting the computer device 50 to a display device. The display device may include a display screen that is a built-in component of the computer device 50. The display device may also include an external computer monitor, television, or projector connected to the computer device 50. Furthermore, a network interface controller (NIC) may be adapted to connect the computer device 50 to a network via a system interconnect. In some embodiments, the NIC may use any suitable interface or protocol (such as an Internet Minicomputer System Interface) to transmit data. The network may be a cellular network, a radio network, a wide area network (WAN), a local area network (LAN), or the Internet, etc. Remote devices can connect to the computing device via the network.
[0097] The flowchart provided in this embodiment is not intended to indicate that the operations of the method will be performed in any particular order, or that all operations of the method are included in every case. Furthermore, the method may include additional operations. Within the scope of the technical concept provided by the method in this embodiment, additional variations can be made to the above method.
[0098] Therefore, those skilled in the art should recognize that although numerous exemplary embodiments of the present invention have been shown and described in detail herein, many other variations or modifications conforming to the principles of the present invention can be directly determined or derived from the disclosure of the present invention without departing from the spirit and scope of the invention. Thus, the scope of the present invention should be understood and construed as covering all such other variations or modifications.
Claims
1. An automatic failover method for a database cluster, the database cluster comprising an arbitrator, a primary database, and multiple standby databases, wherein the arbitrator is used to observe the operating status of the primary database and the standby databases, and the automatic failover method comprises: Obtain the fault signal of the main database; Send a failover command to the target standby database among the multiple standby databases; Attempt to obtain feedback information sent by the target standby database, the feedback information including the execution result of the target standby database on the failover command; If the attempt fails, then try to connect to other backup databases among the multiple backup databases besides the target backup database; If an attempt to connect to the other backup database fails, the arbitrator's operation is stopped. The step following the attempt to obtain feedback information sent by the target backup database also includes: If the attempt is successful, the operating status of the database cluster is adjusted according to the feedback information. The step of adjusting the operating status of the database cluster based on the feedback information includes: Determine whether the feedback information indicates that the failover command has failed to execute; If so, then the synchronous backup database that is next in order to the target backup database among the multiple backup databases is selected as the new target backup database, and the failover command is sent to the new target backup database; wherein, The target backup database is determined by pre-setting priorities for the synchronous backup databases among the multiple backup databases, with the synchronous backup database having the highest priority being the target backup database.
2. The automatic failover method for a database cluster according to claim 1, wherein, After the step of determining whether the feedback information indicates a failure in the execution of the failover command, the method further includes: If not, then promote the target backup database to the primary database and update the configuration status of the arbitrator.
3. The automatic failover method for a database cluster according to claim 1, wherein, The step of attempting to connect to other backup databases among the plurality of backup databases besides the target backup database also includes: If the attempt is successful, obtain the response information from the other backup databases; Based on the response information, determine whether the target backup database has been successfully upgraded to the primary database; If so, update the configuration status of the arbitrator.
4. The automatic failover method for a database cluster according to claim 3, wherein, After the step of determining whether the target backup database has been successfully upgraded to the primary database based on the response information, the following is also included: If the target backup database fails to be upgraded to the primary database, then try to select the next-ranked synchronous backup database as the new target backup database. If the attempt is successful, a failover command is sent to the new target backup database.
5. The automatic failover method for a database cluster according to claim 4, wherein, The steps for attempting to select the next-ranked synchronous backup database as the new target backup database include: If the attempt fails, the next synchronous backup database in the order of the new target backup database is selected as the target backup database to be executed, until an executable target backup database is obtained, and a failover command is sent to the executable target backup database.
6. A machine-readable storage medium having a machine-executable program stored thereon, the machine-executable program, when executed by a processor, implementing the automatic failover method for a database cluster according to any one of claims 1 to 5.
7. A computer device comprising a memory, a processor, and a machine-executable program stored in the memory and running on the processor, wherein the processor, when executing the machine-executable program, implements the automatic failover method for a database cluster according to any one of claims 1 to 5.