Database master-slave switching method and device, computer equipment and storage medium

Abstract

The invention relates to a database master-slave switching method and device, computer equipment and a storage medium. The method comprises the following steps: in response to a manual switching request for a current main node, configuring a target standby node and the current main node into a forced synchronization mode for indicating that the current main node starts from a first moment, and new data writing for the current main node needs to be synchronized to the target standby node, after the target standby node completes new data writing synchronization, the current main node confirms that new data writing is completed; obtaining a disk falling log position of the current main node at the first moment and a synchronous log position of the target standby node at the current moment; and when a comparison result of the synchronization log position and the disk falling log position shows that data before the first moment in the current main node is synchronized by the target standby node, cancelling a forced synchronization mode of the target standby node and the current main node, and switching the target standby node into a new main node for operation. The method can improve the accuracy of master-slave switching.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of database, and in particular to a database master-slave switching method and device, computer equipment, computer readable storage medium and computer program product. BACKGROUND

[0002] In today's digital era, the amount of data generated by various businesses is growing explosively, and the core system's requirements for service availability are also increasing. As a key component for storing and managing business data, the stability and data integrity of the database directly affect the normal operation of the business. Due to risks such as hardware failure, software crash, and natural disasters, a single database node is prone to service interruption, which may lead to data loss or long-term unavailability, seriously affecting business continuity.

[0003] To solve the risk problem of a single database node, the master-slave replication technology emerges as the times require, and a "one master and multiple slaves" high-availability architecture is constructed. Under this architecture, the master node is responsible for processing read and write operations of business data, and the slave node maintains data consistency with the master node by replicating the transaction log of the master node. However, in the actual operation and maintenance process of the database master-slave architecture, manual switching of master-slave nodes is a common means to deal with master node failures or planned maintenance.

[0004] Although manual switching can theoretically guarantee service continuity, in actual operation, the transaction data between the two nodes switched is often out of sync. SUMMARY

[0005] Therefore, it is necessary to provide a database master-slave switching method, device, computer equipment, computer readable storage medium and computer program product that can ensure the synchronization of transaction data between switched nodes to solve the above technical problems.

[0006] In a first aspect, the present application provides a database master-slave switching method, comprising:

[0007] In response to a manual switching request for a current master node, a target slave node and the current master node are configured in a forced synchronization mode, the forced synchronization mode being used to indicate that the current master node starts from a first time, and new data written to the current master node needs to be synchronized to the target slave node, and after the target slave node completes the new data write synchronization, the current master node confirms that the new data write is complete;

[0008] The disk logging position of the current master node at the first time is obtained, and the synchronization log position of the target slave node at the current time is obtained;

[0009] If the comparison result of the synchronization log position and the disk log position indicates that the data in the current master node before the first time has been synchronized by the target standby node, the forced synchronization mode of the target standby node and the current master node is canceled, and the target standby node is switched as a new master node.

[0010] In one of the embodiments, after the synchronization log position of the target standby node at the current time is obtained, the method further comprises:

[0011] If the comparison result of the synchronization log position and the disk log position indicates that the data in the current master node before the first time has not been synchronized by the target standby node, the step of obtaining the synchronization log position of the target standby node at the current time is executed until the comparison result of the synchronization log position and the disk log position indicates that the data in the current master node before the first time has been synchronized by the target standby node.

[0012] In one of the embodiments, after the synchronization log position of the target standby node at the current time is obtained, the method further comprises:

[0013] If the comparison result of the synchronization log position and the disk log position indicates that the data in the current master node before the first time has not been synchronized by the target standby node, the step of obtaining the synchronization log position of the target standby node at the current time is executed until the number of returns reaches a preset number threshold, and the forced synchronization mode of the current master node is canceled.

[0014] In one of the embodiments, the step of executing the step of obtaining the synchronization log position of the target standby node at the current time comprises:

[0015] After a delay of a preset time interval, the step of obtaining the synchronization log position of the target standby node at the current time is executed.

[0016] In one of the embodiments, the target standby node and the current master node are configured as a forced synchronization mode, comprising:

[0017] The configuration file of the current master node is adjusted, and the target standby node is set as a forced synchronization node of the current master node.

[0018] The forced synchronization mode of the current master node is canceled, comprising:

[0019] The configuration file of the current master node is restored to the setting before the adjustment to continue running.

[0020] In one embodiment, configuring the target backup node and the current master node into a forced synchronization mode includes:

[0021] Adjust the configuration file of the current master node and set the target backup node as the forced synchronization node of the current master node;

[0022] The step of canceling the forced synchronization mode between the target backup node and the current master node, and switching the target backup node to run as the new master node, includes:

[0023] Restore the configuration file of the current master node to the settings before the adjustment, and switch the target backup node to run as the new master node.

[0024] In one embodiment, the step of obtaining the target backup node includes:

[0025] Obtain target backup node information from the manual switch request, and determine the target backup node from the backup nodes of the current primary node based on the target backup node information.

[0026] Secondly, this application also provides a database master-slave switching device, comprising:

[0027] The forced synchronization module is used to respond to a manual switch request for the current master node, configure the target backup node and the current master node into a forced synchronization mode. The forced synchronization mode is used to instruct the current master node that, starting from the first moment, new data writes to the current master node need to be synchronized to the target backup node, and after the target backup node completes the new data write synchronization, the current master node confirms that the new data write is complete.

[0028] The log acquisition module is used to acquire the disk write log position of the current master node at the first moment, and to acquire the synchronization log position of the target backup node at the current moment.

[0029] The node switching module is used to cancel the forced synchronization mode between the target backup node and the current master node and switch the target backup node to run as the new master node when the comparison result between the synchronization log position and the disk log position shows that the data in the current master node before the first moment has been synchronized by the target backup node.

[0030] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described in the first aspect.

[0031] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in the first aspect.

[0032] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in the first aspect.

[0033] The aforementioned database master-slave switching method, apparatus, computer equipment, computer-readable storage medium, and computer program products, by configuring the target backup node and the current master node into a forced synchronization mode, fundamentally ensure that all newly written data during the master-slave switching process flows to the target backup node, eliminating the risk of new data loss and ensuring the consistency of node data before and after the switch. Based on the log position comparison at the critical moment when the forced synchronization mode is activated, the synchronization status of the target backup node and the current master node is accurately determined, avoiding the time difference misjudgment caused by real-time queries and the problem of inaccurate threshold settings in traditional technologies, thus improving the accuracy and reliability of master-slave switching. Attached Figure Description

[0034] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0035] Figure 1 This is an application environment diagram of a database master-slave switching method in one embodiment;

[0036] Figure 2 This is a flowchart illustrating a database master-slave switching method in one embodiment;

[0037] Figure 3 This is a flowchart illustrating the database master-slave switching method in another embodiment;

[0038] Figure 4 This is a flowchart illustrating the database master-slave switching method in yet another embodiment;

[0039] Figure 5 This is a structural block diagram of a database master-slave switching device in one embodiment;

[0040] Figure 6 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0041] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0042] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0043] The database master-slave switching method provided in this application embodiment can be applied to, for example... Figure 1 In the application environment shown, terminal 102 communicates with database server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104, or it can be located in the cloud or on another network server. Users can send a manual switch request for the current master node in the database to database server 104 via terminal 102. Server 104 can receive the manual switch request from terminal 102 and then trigger the corresponding operation task on the corresponding node in the database. In a scenario where the current master node in the database has multiple backup nodes, server 104 can determine the target backup node from among the multiple backup nodes. Then, it configures the target backup node and the current master node into a forced synchronization mode. Forced synchronization mode instructs the current master node that, starting from the first moment, any new data writes to the current master node must be synchronized to the target backup node. After the target backup node completes the new data write synchronization, the current master node confirms that the new data write is complete. The server 104 obtains the current master node's disk log position at the first moment and the target backup node's synchronization log position at the current moment. If the comparison between the synchronization log position and the disk log position indicates that data in the current master node prior to the first moment has been synchronized by the target backup node, the forced synchronization mode between the target backup node and the current master node is canceled, and the target backup node is switched to run as the new master node. Server 104 can also send the switch result to terminal 102 to inform the user corresponding to terminal 102 of the execution result of the manual switch request.

[0044] Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, and projection equipment. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted displays. Head-mounted displays can be virtual reality (VR) devices, augmented reality (AR) devices, and smart glasses. Server 104 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0045] In one exemplary embodiment, such as Figure 2 As shown, a database master-slave switching method is provided, which can be applied to... Figure 1 Taking the server in the example, the explanation includes the following steps S202 to S206. Wherein:

[0046] Step S202: In response to the manual switchover request for the current master node, configure the target backup node and the current master node into forced synchronization mode. Forced synchronization mode instructs the current master node that, starting from the first moment, any new data writes to the current master node must be synchronized to the target backup node, and the current master node confirms the completion of the new data write only after the target backup node has completed the new data write synchronization.

[0047] Manual failover requests can be commands triggered by operations personnel or monitoring systems to switch master-slave roles in response to master node failures, planned maintenance, or other high-availability requirements. This request may include target standby node information or be automatically selected by the system. The current master node can be a database in a distributed database architecture that currently handles data writing and transaction processing, synchronizing data to one or more standby nodes. For example, the current master node A may synchronize data to standby node B or standby node C. When data is potentially synchronized to either standby node B or standby node C, the current master node A may consider synchronization complete. Forced synchronization mode refers to a database configuration mode that requires the master node to ensure that data has been successfully synchronized to a specified standby node (i.e., the target standby node) before confirming that new data writing is complete. This mode can be implemented by modifying the master node configuration, such as setting the `synchronous_standby_names` parameter in PostgreSQL to specify the target standby node. Forced synchronization mode can eliminate the risk of data loss caused by asynchronous replication.

[0048] For example, after receiving a manual switchover request for the current primary node, the server determines the target standby node based on the relevant information in the request. For databases that support specifying a synchronization node, such as PostgreSQL, this can be done by adjusting the configuration file of the current primary node, for example, by setting the `synchronous_standby_names` parameter to explicitly point to the target standby node. For databases that do not support specifying a synchronization node, a fully synchronous mode can be set. This configures the target standby node and the current primary node in a forced synchronization mode, ensuring that new data writes are synchronized to the target standby node from the very first moment, and then confirming the write completion.

[0049] Step S204: Obtain the disk write log position of the current master node at the first moment, and obtain the synchronization log position of the target backup node at the current moment.

[0050] Here, "first moment" can refer to the starting time when the forced synchronization mode takes effect, marking the beginning of the synchronization of new data writes to the target standby node. The "first moment's disk log position" can refer to the location where the current primary node has persisted the transaction log to disk, representing the status of all committed data before the first moment. The "target standby node's synchronization log position at the current moment" can refer to the location where the target standby node has received and synchronized the logs from the current primary node, reflecting the synchronization progress of the target standby node with the current primary node's logs.

[0051] For example, at the initial moment of forced synchronization mode startup, for the current master node, if the master node is still running, the location of the logs written to disk can be obtained through database-specific query statements; for example, in PostgreSQL, the LSN can be obtained through a corresponding query. If the master node is not running or does not support queries, the node's log files in the file system can be read, the last log file can be found, and the synchronization location of the last log written to disk can be queried. For the target standby node, the synchronization log location can also be queried by linking to the target standby node through a query statement. If queries are not supported, the latest received log location can be obtained by reading its log files, similar to the method used when the current master node is not running.

[0052] Step S206: If the comparison results between the synchronization log position and the disk log position show that the data in the current master node before the first moment has been synchronized by the target backup node, cancel the forced synchronization mode between the target backup node and the current master node, and switch the target backup node to run as the new master node.

[0053] The comparison result can be determined by comparing the synchronization log position with the disk write log position to see if the target standby node has fully synchronized all data from the master node up to the first moment. For example, if the synchronization log position is greater than or equal to the disk write log position, synchronization is complete; otherwise, it is incomplete. Canceling the forced synchronization mode can be done by restoring the master node's original configuration to remove the forced synchronization requirement on the target standby node; for example, restoring the `synchronous_standby_names` parameter to its previous value. Switching to a new master node can be done by promoting the target standby node to the new master node, for example, by updating cluster metadata or redirecting client connections, so that the node can start handling write requests.

[0054] For example, the current synchronization log position of the target standby node is compared with the disk write log position of the current master node at the first moment. If the synchronization log position indicates that the target standby node has completed the synchronization of data with the current master node before the first moment, it means that the data has met the consistency requirements, and the forced synchronization mode is canceled. For databases that support specifying a synchronization node, the settings for the synchronization node in the current master node configuration file are restored to their previous state. Then, the target standby node is switched to run as the new master node, allowing it to take over the data processing and write tasks of the master node.

[0055] In the aforementioned database master-slave switchover method, by configuring the target backup node and the current master node into forced synchronization mode, all newly written data during the master-slave switchover process is guaranteed to flow to the target backup node, eliminating the risk of new data loss and ensuring the consistency of node data before and after the switchover. Based on the log position comparison at the critical moment when forced synchronization mode is enabled, the synchronization status of the target backup node and the current master node is accurately determined, avoiding the time difference misjudgment caused by real-time query and the problem of inaccurate threshold setting in traditional technologies, thus improving the accuracy and reliability of master-slave switchover.

[0056] In an exemplary embodiment, after obtaining the synchronization log position of the target backup node at the current moment, the method further includes: if the comparison result between the synchronization log position and the disk log position shows that the data in the current master node before the first moment has not been synchronized by the target backup node, returning to the step of obtaining the synchronization log position of the target backup node at the current moment, until the comparison result between the synchronization log position and the disk log position shows that the data in the current master node before the first moment has been synchronized by the target backup node.

[0057] Here, "returning to execution" can refer to repeatedly executing the process of obtaining and comparing the synchronization log position, forming a loop detection mechanism. "Not being synchronized by the target backup node" can mean that the synchronization log position is smaller than the disk write log position, indicating that the target backup node has not yet caught up with the data from the current master node before the first moment.

[0058] For example, after comparing the current synchronization log position with the disk write log position at the first moment, if the server finds that data in the current primary node prior to the first moment has not yet been synchronized by the target backup node, it returns to the step of obtaining the synchronization log position of the target backup node at the current moment. It should be understood that each time this step is executed, the current moment will be the latest moment. After obtaining the new synchronization log position, it is compared again with the disk write log position of the current primary node at the first moment, until the comparison result shows that the target backup node has completed synchronization. This process continuously monitors the synchronization progress of the target backup node to ensure that the data reaches a consistent state before the switchover.

[0059] In this embodiment, if the comparison results between the synchronization log position and the disk log position indicate that the data in the current master node prior to the first moment has not been synchronized by the target backup node, a retry mechanism is implemented to return to the step of obtaining the synchronization log position of the target backup node at the current moment. This ensures that before master-slave switchover, it is necessary to wait for the target backup node to complete data synchronization, avoid misjudgment of temporary asynchrony caused by network latency or target backup node load, ensure the consistency of data between the target backup node and the current master node, and improve the success rate of switchover operation and data reliability.

[0060] In an exemplary embodiment, after obtaining the synchronization log position of the target backup node at the current moment, the method further includes: if the comparison result between the synchronization log position and the disk log position shows that the data in the current master node before the first moment has not been synchronized by the target backup node, returning to the step of obtaining the synchronization log position of the target backup node at the current moment, until the number of returns reaches a preset number threshold, and canceling the forced synchronization mode of the current master node.

[0061] The preset retry threshold can be the maximum number of retries configured by the user, used to limit the number of loop monitoring attempts and prevent wireless waiting. Canceling the forced synchronization mode allows the master node to be restored to its original configuration after a retry failure, thus releasing forced synchronization.

[0062] For example, after comparing the current synchronization log position with the disk write log position at the first moment, if the server finds that data in the current master node prior to the first moment has not yet been synchronized by the target standby node, it starts repeatedly obtaining the current synchronization log position of the target standby node and comparing it with the disk write log position of the current master node at the first moment. Each repetition counts once. When the number of returns reaches a preset threshold, it indicates that the target standby node has still not completed synchronization after multiple attempts, and at this point, the forced synchronization mode of the current master node is canceled. For databases that support specifying a synchronization node, the configuration file of the current master node is restored to its previous settings to maintain the original operating mode of the current master node and avoid business operations being affected due to long waiting times for synchronization and failure to switch successfully.

[0063] In this embodiment, by setting a preset threshold number of attempts, infinite retries caused by prolonged synchronization failures are avoided, preventing excessive consumption of system resources and long-term business blockage. This balances data reliability and business continuity while ensuring data synchronization. When the preset threshold number of attempts is reached and synchronization is still not complete, the original configuration of the master node is promptly restored to ensure continued business operation and minimize business impact.

[0064] In an exemplary embodiment, the step of returning to the execution of obtaining the synchronization log position of the target backup node at the current time includes: after delaying a preset time interval, returning to the execution of obtaining the synchronization log position of the target backup node at the current time.

[0065] The preset time interval can be the time interval between each return to retrieve the synchronization log position of the target backup node. It can be preset by the user, allowing the target backup node sufficient time to process synchronization. By reasonably setting the preset time interval, it is possible to avoid retrieving the synchronization log position too frequently, reducing resource consumption, while ensuring effective monitoring of the synchronization status of the target backup node.

[0066] For example, when the server discovers that the target backup node has not completed synchronization and needs to retry, it does not immediately retrieve the synchronization log position of the target backup node again. Instead, it waits for a preset time interval. For instance, if the preset time interval is set to 1 second, then after the comparison result shows that synchronization is not complete, the server waits for 1 second before retrieving the current synchronization log position of the target backup node. This avoids excessive pressure on system resources from frequent queries in a short period of time, while ensuring continuous monitoring of the synchronization status of the target backup node within an appropriate time interval.

[0067] In this embodiment, the cyclic retry process is optimized by setting a preset time interval, reducing unnecessary consumption of system resources. This avoids the negative impact on database performance caused by excessively frequent acquisition of log position information, while also enabling timely tracking of the synchronization progress of the target backup node. Continuously monitoring the synchronization status while ensuring system performance helps achieve a balance between data consistency and system performance.

[0068] In one exemplary embodiment, configuring the target backup node and the current master node into forced synchronization mode includes: adjusting the configuration file of the current master node to set the target backup node as the forced synchronization node of the current master node. Canceling the forced synchronization mode of the current master node includes: restoring the configuration file of the current master node to its previous settings to continue operation.

[0069] The configuration file for the current master node can be a persistent settings file for the current master node in the database, which can be used to control the replication behavior of the current master node. Adjusting previous settings can refer to the original configuration parameters before forced synchronization mode was enabled.

[0070] For example, for databases that support specifying a synchronization node, the server locates the configuration file of the current master node and modifies the parameters related to the synchronization node. For instance, in PostgreSQL, the server can adjust the `synchronous_standby_names` parameter, setting its value to the identifier of the target standby node. This sets the target standby node as the mandatory synchronization node for the current master node, ensuring that new data writes are always synchronized to the target standby node. When monitoring the synchronization status of the target standby node, if the number of monitoring cycles reaches a preset threshold and the synchronization status of the target standby node has not yet caught up with the current master node before the initial setting, the mandatory synchronization mode needs to be canceled. The server then locates the configuration file of the current master node again and restores the previously adjusted parameters related to the synchronization node to their original values. For example, in PostgreSQL, the server can restore the `synchronous_standby_names` parameter to its original value, restoring the current master node to its operating state before the mandatory synchronization mode setting was implemented, continuing to maintain the original data synchronization and processing methods.

[0071] In this embodiment, the forced synchronization mode is configured by modifying the configuration file, and the forced synchronization mode is canceled by restoring the previous settings, thus achieving precise control over the database synchronization mode. This control method has high operability and standardization, making it easy to implement and manage in actual operation and maintenance. It ensures that while maintaining data consistency, the database's operating mode can be flexibly adjusted to adapt to different business needs and synchronization situations.

[0072] In an exemplary embodiment, configuring the target backup node and the current master node into a forced synchronization mode includes: adjusting the configuration file of the current master node and setting the target backup node as the forced synchronization node of the current master node; canceling the forced synchronization mode between the target backup node and the current master node and switching the target backup node to run as the new master node includes: restoring the configuration file of the current master node to the settings before adjustment and switching the target backup node to run as the new master node.

[0073] The configuration file for the current master node can be a persistent settings file for the current master node in the database, which can be used to control the replication behavior of the current master node. Adjusting previous settings can refer to the original configuration parameters before forced synchronization mode was enabled.

[0074] For example, for databases that support specifying a synchronization node, the server locates the configuration file of the current master node and modifies the parameters related to the synchronization node. For instance, in PostgreSQL, the server can adjust the `synchronous_standby_names` parameter, setting its value to the identifier of the target standby node. This sets the target standby node as the mandatory synchronization node for the current master node, ensuring that new data writes are always synchronized to the target standby node. If the server detects that data in the current master node prior to the first moment has already been synchronized by the target standby node, it needs to cancel the mandatory synchronization mode. The server then locates the configuration file of the current master node again and restores the previously adjusted parameters related to the synchronization node to their original values. For example, in PostgreSQL, the server can restore the `synchronous_standby_names` parameter to its original value, returning the current master node to its state before the mandatory synchronization mode setting. A switchover operation is then performed, promoting the target standby node to the new master node. In practical applications, if the server detects that data in the current master node prior to the first moment has been synchronized by the target backup node, the server can first perform a switchover operation, promoting the target backup node to the new master node. Then, the server retrieves the current master node's configuration file and restores the previously adjusted parameters related to the synchronization node to their original values. In this embodiment, after the target backup node becomes the new master node, the current master node needs to restore its configuration to its previous settings to ensure that the current master node, no longer the master node, will not remain in forced synchronization mode.

[0075] In this embodiment, the configuration of the original master node (i.e., the current master node) is restored before the switch, ensuring that the forced synchronization settings are not retained after the original master node is no longer the master node, so that the database is restored to the original operating mode after the switch, thus ensuring the consistency of the cluster configuration.

[0076] In an exemplary embodiment, the step of obtaining the target backup node includes: obtaining target backup node information from a manual switch request, and determining the target backup node from the backup nodes of the current primary node based on the target backup node information.

[0077] The target backup node information can refer to the identifier of the backup node specified in the manual switch request. The backup nodes of the current master node can refer to all slave nodes that have a replication relationship with the current master node.

[0078] For example, the server receives a manual switch request, parses the target backup node information in the request, and then finds a matching node from the backup node list of the current primary node as the target backup node.

[0079] In this embodiment, by obtaining the target backup node information from the manual switch request, and then determining the target backup node from the backup nodes of the current master node based on the target backup node information, users can explicitly specify the target backup node for switching, improving the flexibility of database master-slave switching. Especially in scenarios with multiple backup nodes, users can select a suitable backup node for switching.

[0080] In some examples, the configuration file of the current master node is restored to its previous settings, and the target standby node is switched to run as the new master node. This includes: using the configuration file of the current master node before the adjustment as the configuration file of the target standby node; if there are other databases that need to be modified on both the master and standby nodes, then both the current master node and the new master node need to be modified.

[0081] In one exemplary embodiment, such as Figure 3 As shown, database master-slave switching methods may include:

[0082] Step S301: In response to the manual switchover request for the current master node, configure the target backup node and the current master node into forced synchronization mode. Forced synchronization mode instructs the current master node that, starting from the first moment, any new data writes to the current master node must be synchronized to the target backup node, and the current master node confirms the completion of the new data write only after the target backup node has completed the new data write synchronization.

[0083] Step S302: Obtain the disk write log position of the current master node at the first moment, and obtain the synchronization log position of the target backup node at the current moment.

[0084] Step S303: If the comparison results between the synchronization log position and the disk log position show that the data in the current master node before the first moment has been synchronized by the target backup node, cancel the forced synchronization mode between the target backup node and the current master node, and switch the target backup node to run as the new master node.

[0085] Step S304: If the comparison result between the synchronization log position and the disk log position shows that the data in the current master node before the first moment has not been synchronized by the target backup node, return to the step of obtaining the synchronization log position of the target backup node at the current moment, until the comparison result between the synchronization log position and the disk log position shows that the data in the current master node before the first moment has been synchronized by the target backup node.

[0086] Step S305: If the comparison result between the synchronization log position and the disk log position shows that the data in the current master node before the first moment has not been synchronized by the target backup node, return to the step of obtaining the synchronization log position of the target backup node at the current moment, until the number of returns reaches the preset number threshold, and cancel the forced synchronization mode of the current master node.

[0087] The solution provided in this embodiment is similar to the solution described in the above method. Therefore, its specific limitations can be found in the limitations of the database master-slave switching method described above, and will not be repeated here.

[0088] This application also provides an application scenario in which the above-described database master-slave switching method is applied. Specifically, the application of the database master-slave switching method in this scenario is as follows:

[0089] The following explains the terminology used in this application scenario:

[0090] Master-Slave Replication: By synchronizing the transaction logs of the master node (such as PostgreSQL's WAL or MySQL's Binlog) to the slave node in real time, the slave node maintains data consistency with the master node.

[0091] LSN (Log Sequence Number): A unique identifier in a database used to identify the location and order of transaction logs (such as the WAL log in PostgreSQL and the transaction log in SQL Server). It is a core identifier for ensuring data consistency, master-slave synchronization, and crash recovery.

[0092] Write-Ahead Logging (WAL) is a core technology in the database field for ensuring data consistency, reliability, and performance, and is widely used by mainstream databases such as PostgreSQL, MySQL (InnoDB), and MongoDB. Its core idea is that all modifications to data must first be recorded in a log. Only after the log is persisted are the data modifications applied to the actual data files. This "log-first" mechanism fundamentally solves the key problems of database crash recovery, data consistency assurance, and performance optimization.

[0093] GTID (Global Transaction Identifier) ​​is a global numbering mechanism used to uniquely identify transactions in database master-slave replication. Introduced in MySQL 5.6 and later, it aims to solve the synchronization complexity caused by relying on log positions (such as Binlog filenames + offsets) in traditional replication. GTID assigns a globally unique ID to each transaction, enabling automation, visualization, and rapid fault recovery in master-slave replication by tracking transaction IDs rather than physical log positions.

[0094] This application scenario involves a database master-slave architecture, which primarily utilizes master-slave replication technology to form a "one master, multiple slaves" high-availability architecture. However, in the operational practice of database master-slave architectures, manual failover, as a crucial means of handling master node failures or planned maintenance, should ensure service continuity by switching business traffic to the slave node. But in practice, manual failover faces the potential risk of data loss: due to objective phenomena such as WAL log transmission delays and slave node replay lags during master-slave replication, it is difficult for operations personnel to accurately determine in real time whether the slave node has fully synchronized with the latest data of the master node (especially WAL logs that were not fully sent before the master node failure). Forcibly performing a failover before the slave node has caught up with the master node's data will result in the loss of unsynchronized transaction data; conversely, waiting too long due to excessive caution will prolong business interruption. This contradiction between "difficulty in confirming synchronization status" and "timely failover requirements" makes manual failover, in the absence of standardized verification procedures, a weak link in data consistency.

[0095] The applicant found that current technologies for master-slave synchronization have many shortcomings, further exacerbating the data risks associated with manual failover. Regarding time lag, traditional methods involve querying the synchronization status of master and slave nodes each time. In scenarios with large-scale data imports, even if the master and slave data show consistency at the time of the query, it doesn't guarantee that they will remain consistent during the actual failover. Even a brief query interval can introduce new synchronization gaps due to continuous writing from the master node. Regarding accuracy, some methods determine synchronization by reading the master node's log file and then querying the corresponding file status on the slave node. However, in high-frequency write scenarios such as data imports, log files change extremely rapidly, and this lagging comparison method cannot guarantee the accuracy of the verification results. Regarding security, traditional technologies are mostly applicable when the old master node has stopped writing. However, even in scenarios without new data writing, master and slave nodes typically maintain the connection via empty packets, and log positions may still change slightly. In such cases, a synchronization threshold needs to be set to determine whether a failover is possible, but the determination of this threshold lacks scientific basis, and setting a threshold cannot completely eliminate the risk of data loss, resulting in low applicability.

[0096] Based on this, the database master-slave switching method provided in this application aims to provide a new solution for monitoring the synchronization of master and slave logs. It mainly addresses how to avoid data loss caused by forcibly performing the switch before the slave node has caught up with the master node's data during manual switching. It also avoids the drawback of excessively cautiously waiting for master-slave synchronization to take too long, which prolongs business interruption time, and ensures data consistency before and after the switch.

[0097] The database master-slave switchover method provided in this application ensures that the master and slave logs are probed in advance without affecting the normal operation of the database, and that the switchover occurs only after the data is fully synchronized. The specific implementation steps are as follows:

[0098] like Figure 4 The diagram shown is a flowchart of a method for monitoring the synchronization of master and slave logs:

[0099] Step S41: Configure a forced synchronization node. During database node operation, the standby node is made a synchronous standby node by adjusting the primary node's configuration file. For example, in PostgreSQL, the `synchronous_standby_names` parameter can be adjusted to ensure that new data is received on the new primary node before it is considered written. Note that in this setting, the new primary node must be a guaranteed synchronous standby node. If `synchronous_standby_names=Any1` (new primary node A, standby node B), the logs might be synchronized to B and considered synchronization complete, which is not suitable for this step. If the database does not support specifying a synchronous standby node, the same effect can be achieved by setting a full synchronization mode.

[0100] Step S42: Obtain the master node baseline log position. To obtain the current master node synchronization log position, if the master node is still running, a query can be performed to establish a link. If querying is not supported or the master node is not running, the last log file in the file system can be read to find the last log synchronization position written to disk, such as the LSN in PostgreSQL or the GTID event in MySQL, recorded as master_location.

[0101] Step S43: Obtain the synchronization log position of the slave node. To obtain the synchronization log position of the node that will become the new master node, you can use a query statement to link to the new master node for querying. If querying is not supported, you can do so similarly to step S42 by reading the node's log file in the file system to query the latest received log position, which is recorded as `slave_location`.

[0102] Step S44, Log position verification. By comparing master_location and slave_location, determine whether the slave node has synchronized to the latest position queried at time T1. If it is not greater than the current position, repeat step S43. Optionally, the number of retries and the interval can be configured separately, allowing the user to decide the waiting time.

[0103] As can be seen, in step S41, the primary and backup nodes have been adjusted to synchronous mode. In this case, the writing of new data must be synchronized to the backup node, which is the new primary node. By simply recording the primary node's log position at time T1 and determining whether the backup node has caught up with its log position at time T1, it can be determined whether the backup node's log synchronization is normal. Data writing after time T1 will be guaranteed to be synchronized without loss through the database kernel's native synchronization configuration. By comparing the log synchronization status at a specific moment, inaccurate data caused by timely queries is avoided, and there is no threshold setting to guarantee that log synchronization will be completed. The synchronization mode set in step S41 also ensures that even with continuous reading and writing, data will not be lost once it is written. This method will not affect data reading and writing if the nodes are always in synchronous mode.

[0104] Step S45: Handling synchronization failure, restoring the original configuration of the master node, and terminating the failover process (failure to perform failover). If step S44 fails to detect the backup node logs being synchronized to master_location after a certain number of attempts, the probe is considered to have failed, and the original configuration of the master node is restored.

[0105] Before the formal switchover process begins, the database operation will only remain in the write phase, waiting for the new master node to synchronize. This is unavoidable when manually switching to ensure no data loss. However, the read and write functionality affected by the database node stopping during general probing has been optimized.

[0106] Step S46: Perform a primary / standby switchover to complete the node role change; restore the original configuration file of the primary node. If step S44 detects that the standby node logs are synchronized to master_location, then execute the specific switchover steps to switch the standby node to the new primary node. After the switchover is complete, modify the old primary node's configuration file back to the original configuration file from step S41.

[0107] To address the problems of inaccurate synchronization status judgment, easy data loss, and low applicability in traditional manual master-slave failover techniques, the database master-slave failover method provided in this application can guarantee data consistency. Specifically:

[0108] The database master-slave switching method provided in this application eliminates the risk of newly written data loss by configuring a mandatory synchronization node to lock the data synchronization target. Specifically, during the switchover preparation phase, the target standby node (new master node) is set as the mandatory synchronization node by adjusting the master node configuration. For databases that support specifying a synchronization node (such as PostgreSQL), the `synchronous_standby_names` parameter is explicitly configured to point to the target standby node, avoiding synchronization uncertainties caused by ambiguous configurations such as "Any1(node ​​A, node B)". For databases that do not support specifying a synchronization node, a full synchronization mode is enabled to ensure that new data must be synchronized to the target standby node before write confirmation is completed. Advantages compared to traditional technologies: Existing master-slave synchronization often uses "confirmation upon completion of synchronization on any node" or does not explicitly lock the synchronization target, which may result in new data only being synchronized to non-target standby nodes, leading to data loss during switchover due to the target standby node not being synchronized. This application, through the configuration of "mandatory specification of synchronization node", fundamentally ensures that all newly written data during the switchover process must flow to the target standby node, completely eliminating the risk of new data loss.

[0109] The database master-slave switching method provided in this application achieves accurate synchronization status determination by comparing log positions at key time points. Specifically, at the moment synchronization mode is enabled (T1), the master node's disk-written log position (master_location, such as PostgreSQL's LSN or MySQL's GTID) is obtained; simultaneously, the latest received log position of the target slave node (slave_location) is continuously obtained. By comparing whether the two are consistent, it is determined whether the slave node has synchronized all data before time T1. The log position can be obtained through database query or reading log files, adapting to scenarios where the master node is running or offline. Advantages compared to traditional technologies: Traditional technologies rely on real-time querying of synchronization status. In scenarios with large amounts of data import, the consistency at the query time cannot represent the consistency at the switching time, leading to misjudgments due to time differences; or they use thresholds to determine synchronization, but these thresholds are difficult to accurately determine and still carry the risk of data loss. This application replaces "real-time querying" with a "fixed time point benchmark," using the log position at time T1 as a reference. It only needs to determine whether the slave node has caught up with this fixed position, avoiding time difference issues and eliminating the need to set thresholds, thus ensuring the accuracy of synchronization status determination.

[0110] The database master-slave failover method provided in this application balances synchronization reliability and business continuity through adaptive retry and configuration recovery mechanisms. Specifically, if the initial comparison reveals that the slave node has not completed synchronization, the log position acquisition and comparison are repeated according to the user-configured number of retries and intervals. If synchronization is still not completed after reaching the maximum number of retries, the original configuration of the master node is automatically restored to avoid long-term blocking of business writes. If synchronization is completed, the original configuration of the master node is restored after the failover, ensuring that the database operating mode is consistent before and after the failover. Advantages compared to traditional technologies: Traditional technologies, when synchronization is incomplete, either force a failover leading to data loss or indefinitely wait, prolonging business interruption, lacking flexible retry strategies and safe exit mechanisms. This application, through a configurable retry mechanism, reduces unnecessary waiting while ensuring data synchronization; simultaneously, through automatic configuration recovery, it avoids the impact of long-term synchronization mode on business write performance, thus balancing data reliability and business continuity.

[0111] The database master-slave switching method provided in this application improves the versatility of the solution through a unified logic compatible with different databases. Specifically, it adopts a unified logical framework of "log position acquisition-comparison-synchronization judgment" to adapt to the logging mechanisms of different databases. Whether it is PostgreSQL based on LSN, MySQL based on GTID, or other databases that support master-slave replication, key position information can be obtained through query statements or log files, without the need for customized development for specific databases. Advantages compared to traditional technologies: Traditional technologies often design synchronization judgment logic for specific databases, resulting in poor adaptability to databases with different logging mechanisms and requiring repeated development of adaptation code. This application, by abstracting the universal core indicator of "log position," forms a unified judgment logic across databases, significantly reducing the adaptation cost of different database systems and improving the versatility and scalability of the technical solution.

[0112] Due to its advanced nature, this technical solution has wide application value in areas such as database disaster recovery, master-slave failover, and data consistency assurance. Through four key technical elements—forced synchronization node locking, critical time point comparison, adaptive retry recovery, and cross-database compatibility—it completely solves the problems of data loss, inaccurate judgment, and low applicability in existing manual failover methods. It has significant practical implications and market prospects in industries with extremely high data consistency requirements, such as finance and e-commerce.

[0113] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0114] Based on the same inventive concept, this application also provides a database master-slave switching device for implementing the database master-slave switching method described above. The solution provided by this device is similar to the solution described in the above method; therefore, the specific limitations of the one or more database master-slave switching device embodiments provided below can be found in the limitations of the database master-slave switching method described above, and will not be repeated here.

[0115] In one exemplary embodiment, such as Figure 5 As shown, a database master-slave switching device 900 is provided, including: a forced synchronization module 901, a log acquisition module 902, and a node switching module 903, wherein:

[0116] The forced synchronization module 901 is used to respond to a manual switch request for the current master node, configure the target backup node and the current master node in forced synchronization mode. The forced synchronization mode is used to instruct the current master node that new data writes to the current master node need to be synchronized to the target backup node from the first moment, and the current master node confirms that the new data write is complete after the target backup node completes the new data write synchronization.

[0117] The log acquisition module 902 is used to obtain the disk write log position of the current master node at the first moment, and to obtain the synchronization log position of the target backup node at the current moment.

[0118] The node switching module 903 is used to cancel the forced synchronization mode between the target backup node and the current master node and switch the target backup node to run as the new master node when the comparison result between the synchronization log position and the disk log position shows that the data in the current master node before the first moment has been synchronized by the target backup node.

[0119] In an exemplary embodiment, the database master-slave switching device further includes a loop module, which is used to return to the step of obtaining the synchronization log position of the target backup node at the current moment if the comparison result between the synchronization log position and the disk log position shows that the data in the current master node before the first moment has not been synchronized by the target backup node, until the comparison result between the synchronization log position and the disk log position shows that the data in the current master node before the first moment has been synchronized by the target backup node.

[0120] In an exemplary embodiment, the above-mentioned loop module is further configured to, if the comparison result between the synchronization log position and the disk log position shows that the data in the current master node before the first moment has not been synchronized by the target backup node, return to the step of obtaining the synchronization log position of the target backup node at the current moment, until the number of returns reaches a preset number threshold, and cancel the forced synchronization mode of the current master node.

[0121] In an exemplary embodiment, the above-mentioned loop module is further configured to return to the step of obtaining the synchronization log position of the target backup node at the current time after a preset time interval is delayed.

[0122] In an exemplary embodiment, the forced synchronization module 901 is further configured to adjust the configuration file of the current master node and set the target backup node as the forced synchronization node of the current master node; the loop module is further configured to restore the configuration file of the current master node to the settings before the adjustment so as to continue running.

[0123] In an exemplary embodiment, the forced synchronization module 901 is further configured to adjust the configuration file of the current master node and set the target backup node as the forced synchronization node of the current master node; the loop module is further configured to restore the configuration file of the current master node to the settings before adjustment and switch the target backup node to run as the new master node.

[0124] In an exemplary embodiment, the database master-slave switching device further includes a target backup node determination module, which is used to obtain target backup node information from the manual switching request and determine the target backup node from the backup nodes of the current master node based on the target backup node information.

[0125] The modules in the aforementioned database master-slave switching device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0126] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows:Figure 6 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media to run. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a database master-slave switching method.

[0127] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0128] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0129] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0130] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0131] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0132] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0133] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0134] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A database master-slave switching method, characterized in that, The method includes: In response to a manual switch request for the current master node, the target backup node and the current master node are configured to be in forced synchronization mode. The forced synchronization mode is used to instruct the current master node that new data writes to the current master node need to be synchronized to the target backup node from the first moment, and the current master node confirms that the new data write is complete after the target backup node completes the new data write synchronization. Obtain the disk write log position of the current master node at the first moment, and obtain the synchronization log position of the target backup node at the current moment; If the comparison result between the synchronization log position and the disk log position indicates that the data in the current master node prior to the first moment has been synchronized by the target backup node, then the forced synchronization mode between the target backup node and the current master node is canceled, and the target backup node is switched to run as the new master node.

2. The method according to claim 1, characterized in that, After obtaining the synchronization log position of the target backup node at the current moment, the method further includes: If the comparison result between the synchronization log position and the disk log position indicates that the data in the current master node prior to the first moment has not been synchronized by the target backup node, the process returns to the step of obtaining the synchronization log position of the target backup node at the current moment, until the comparison result between the synchronization log position and the disk log position indicates that the data in the current master node prior to the first moment has been synchronized by the target backup node.

3. The method according to claim 1, characterized in that, After obtaining the synchronization log position of the target backup node at the current moment, the method further includes: If the comparison result between the synchronization log position and the disk log position indicates that the data in the current master node prior to the first moment has not been synchronized by the target backup node, the process returns to the step of obtaining the synchronization log position of the target backup node at the current moment, until the number of returns reaches a preset threshold, and then the forced synchronization mode of the current master node is canceled.

4. The method according to claim 2 or 3, characterized in that, The step of returning to execute and obtaining the synchronization log position of the target backup node at the current time includes: After a preset time interval, return to the step of obtaining the synchronization log position of the target backup node at the current moment.

5. The method according to claim 3, characterized in that, The step of configuring the target backup node and the current master node into a forced synchronization mode includes: Adjust the configuration file of the current master node and set the target backup node as the forced synchronization node of the current master node; The cancellation of the forced synchronization mode of the current master node includes: Restore the current master node's configuration file to its previous settings to continue operation.

6. The method according to claim 1, characterized in that, The step of configuring the target backup node and the current master node into a forced synchronization mode includes: Adjust the configuration file of the current master node and set the target backup node as the forced synchronization node of the current master node; The step of canceling the forced synchronization mode between the target backup node and the current master node, and switching the target backup node to run as the new master node, includes: Restore the configuration file of the current master node to the settings before the adjustment, and switch the target backup node to run as the new master node.

7. The method according to claim 1, characterized in that, The steps for obtaining the target backup node include: Obtain target backup node information from the manual switch request, and determine the target backup node from the backup nodes of the current primary node based on the target backup node information.

8. A database master-slave switching device, characterized in that, The device includes: The forced synchronization module is used to respond to a manual switch request for the current master node, configure the target backup node and the current master node into a forced synchronization mode. The forced synchronization mode is used to instruct the current master node that, starting from the first moment, new data writes to the current master node need to be synchronized to the target backup node, and after the target backup node completes the new data write synchronization, the current master node confirms that the new data write is complete. The log acquisition module is used to acquire the disk write log position of the current master node at the first moment, and to acquire the synchronization log position of the target backup node at the current moment. The node switching module is used to cancel the forced synchronization mode between the target backup node and the current master node and switch the target backup node to run as the new master node when the comparison result between the synchronization log position and the disk log position shows that the data in the current master node before the first moment has been synchronized by the target backup node.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images