Cloud database master / slave database switching method, cloud database, and computing device

Abstract

The embodiments of this specification provide a method for switching between a master and a standby database of a cloud database, a cloud database, and a computing device, wherein the method for switching between a master and a standby database of a cloud database is applied to a high-availability module of a cloud database, wherein the cloud database further includes a load balancing module, an old master database, and an old standby database; the method includes: when the operating status of the old master database and the old standby database meet the switching conditions, setting the connection draining time of the load balancing module; setting the write permission of the old master database to stop writing; when the data synchronization between the old standby database and the old master database is completed, switching the old standby database to the new master database, and triggering the connection draining time, so that the load balancing module suspends the old data connection with the old master database within the connection draining time, and distributes the new data request to the new master database; and reconnecting the old data connection to the new master database. The seamless switching of the master and standby databases is completed, the unavailable time caused by forced disconnection is eliminated, data consistency and service continuity are synchronously guaranteed, and availability is improved.

Description

Technical Field

[0001] The embodiments of this specification relate to the technical field of databases, and more particularly to a method for switching between a primary and a secondary database of a cloud database, a cloud database, and a computing device. Background Art

[0002] With the development of database technology, cloud databases have gradually developed the characteristics of elastic scalability, distributed architecture, high throughput and low latency, and are suitable for scenarios such as big data, the Internet of Things, and artificial intelligence.

[0003] In scenarios such as cloud database version upgrades, data migration, and resource elastic scaling, switching between primary and secondary databases can reduce the unavailability time of the cloud database and improve its availability.

[0004] However, in scenarios like cloud database version upgrades, data migration, and resource elastic scaling, the connection between the cloud database and the client for existing data is disconnected to ensure data consistency and transaction integrity. This results in a period of database unavailability, which needs to be further reduced to improve database availability. Therefore, a seamless, high-availability method for switching between primary and standby databases in cloud databases is urgently needed. Summary of the Invention

[0005] In light of this, embodiments of this specification provide a method for switching between a primary and a backup database in a cloud database. One or more embodiments of this specification also relate to another method for switching between a primary and a backup database in a cloud database, a cloud database, a computing device, a computer-readable storage medium, and a computer program product to address technical deficiencies in the prior art.

[0006] According to a first aspect of an embodiment of this specification, a method for switching between a primary and a secondary database in a cloud database is provided, which is applied to a high-availability module of the cloud database, wherein the cloud database further includes a load balancing module, an old primary database, and an old secondary database; the method includes:

[0007] When the operating status of the old primary and backup databases meet the switchover conditions, set the connection draining time for the load balancing module.

[0008] Set the write permission of the old master database to stop writing;

[0009] After data synchronization between the old standby database and the old primary database is complete, the old standby database is switched to the new primary database, and the connection draining period is triggered. This allows the load balancing module to suspend the old data connection with the old primary database within the connection draining period and distribute new data requests to the new primary database.

[0010] Reconnect the old database to the new master database.

[0011] According to a second aspect of an embodiment of this specification, another method for switching between a primary and a secondary database in a cloud database is provided, which is applied to a load balancing module of the cloud database, wherein the cloud database further includes a high availability module, an old primary database, and an old secondary database; the method includes:

[0012] During the connection draining time, the old data connection with the old master database is suspended, and new data requests are distributed to the new master database, wherein the steps of the above method are executed in the high availability module.

[0013] According to a third aspect of an embodiment of this specification, a cloud database is provided, including a high availability module, a load balancing module, an old master database, and an old standby database;

[0014] The high availability module is used to set the connection draining time for the load balancing module when the operating status of the old primary and standby databases meet the switching conditions; set the write permission of the old primary database to stop writing; and after completing data synchronization between the old standby and old primary databases, switch the old standby database to the new primary database and trigger the connection draining time.

[0015] The load balancing module is used to suspend the old data connection with the old master database during the connection drain period and distribute new data requests to the new master database;

[0016] A high-availability module is used to reconnect old databases to the new master database.

[0017] According to a fourth aspect of the embodiments of this specification, a computing device is provided, including:

[0018] memory and processor;

[0019] The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions. When the computer programs / instructions are executed by the processor, the steps of the above-mentioned method for switching between the primary and standby databases of the cloud database are implemented.

[0020] According to a fifth aspect of the embodiments of this specification, a computer-readable storage medium is provided, which stores a computer program / instruction. When the computer program / instruction is executed by a processor, the steps of the above-mentioned method for switching between a primary and a secondary database of the cloud database are implemented.

[0021] According to a sixth aspect of the embodiments of this specification, a computer program product is provided, including a computer program / instruction, which, when executed by a processor, implements the steps of the above-mentioned method for switching between a primary and a secondary database of a cloud database.

[0022] In one embodiment of the present specification, a method for switching between a primary and a backup database of a cloud database is provided, which is applied to a high-availability module of the cloud database, wherein the cloud database further includes a load balancing module, an old primary database, and an old backup database; the method includes: when the operating status of the old primary database and the old backup database meets the switching conditions, setting the connection draining time of the load balancing module; setting the write permission of the old primary database to stop writing; when the data synchronization between the old backup database and the old primary database is completed, switching the old backup database to the new primary database, and triggering the connection draining time, so that the load balancing module suspends the old data connection with the old primary database within the connection draining time, and distributes the new data request to the new primary database; and reconnecting the old data connection to the new primary database.

[0023] By setting the connection draining time, a time window for processing the data connection of the old master database is reserved to avoid forced disconnection that causes the old data connection to be directly disconnected. When the old standby database is promoted to the new master database after data synchronization is completed, the connection draining mechanism is triggered to make the load balancing module keep the old data connection suspended, and at the same time, new data requests are directed to the new master database, which not only ensures the real-time response of new requests during the switch, but also retains the availability of the old data connection. Under the premise of data consistency, the suspended old data connection is smoothly migrated to the new master database through active redirection, rather than passive disconnection and reconstruction. This process completes the seamless switching of the master and standby databases without interrupting existing data services through dynamic coordination of the draining time, diversion control of the old and new connections, and coordination of redirection after synchronization, eliminating the unavailable time caused by forced disconnection, achieving the simultaneous guarantee of data consistency and service continuity, and further improving availability. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 This is a flowchart of a method for switching between a primary and a secondary database of a cloud database provided by one embodiment of this specification;

[0025] Figure 2 This is a flowchart of another method for switching between a primary and a secondary database of a cloud database provided by an embodiment of this specification;

[0026] Figure 3 This is a schematic diagram of the architecture of a single virtual network address in a method for switching between a primary and a secondary database of a cloud database provided by one embodiment of this specification;

[0027] Figure 4 This is a timing flow chart of a method for switching between a primary and a secondary database of a cloud database provided by one embodiment of this specification;

[0028] Figure 5 This is a schematic diagram of the architecture of dual virtual network addresses in a method for switching between a primary and a backup database of a cloud database provided by one embodiment of this specification;

[0029] Figure 6 This is a schematic diagram of the structure of a cloud database provided by an embodiment of this specification;

[0030] Figure 7 This is a structural block diagram of a computing device provided by one embodiment of this specification. DETAILED DESCRIPTION

[0031] The following description sets forth many specific details to facilitate a thorough understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar generalizations without violating the scope of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0032] The terms used in one or more embodiments of this specification are for the purpose of describing specific embodiments only and are not intended to limit one or more embodiments of this specification. The singular forms "a," "the," and "the" used in one or more embodiments of this specification and the appended claims are also intended to include plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0033] It should be understood that although the terms first, second, etc. may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, the first may also be referred to as the second, and similarly, the second may also be referred to as the first. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0034] In addition, 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, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0035] First, the terms involved in one or more embodiments of this specification are explained.

[0036] Cloud database: refers to the database service deployed on a cloud service provider.

[0037] Client: A program that accesses a cloud database, usually deployed on a system machine that needs to access the database.

[0038] No sense of touch: During the switchover between the primary and standby databases, clients connected to the cloud database will not receive any exceptions such as disconnection or command execution failure.

[0039] Active switching: The database administrator or database management system performs a switch operation on the database within an expected timeframe. This is commonly seen in scenarios such as cloud database version upgrades, data migration, and resource elastic scaling.

[0040] Master database: The master node that provides database services in the cloud database.

[0041] Backup database: A standby node in a cloud database that provides database services. When the primary database fails, it replaces the primary database and continues to provide database services.

[0042] Service Level Agreement (SLA): A contract between a cloud service provider and its customer that defines the services to be provided and the expected performance levels. The SLA also describes how performance will be measured and approved, and what happens if performance levels are not met.

[0043] In this specification, a method for switching between a primary and a backup database of a cloud database is provided. This specification also relates to a method for switching between a primary and a backup database of a cloud database, a cloud database, a computing device, a computer-readable storage medium, and a computer program product, which are described in detail one by one in the following embodiments.

[0044] See also Figure 1 , Figure 1 A flowchart of a method for switching between a primary and a backup database in a cloud database provided by one embodiment of this specification is shown. The method is applied to a high-availability module of the cloud database, wherein the cloud database also includes a load balancing module, an old primary database, and an old backup database. The method includes the following specific steps:

[0045] Step 102: When the operating status of the old master database and the old standby database meets the switching conditions, set the connection draining time of the load balancing module.

[0046] The embodiments of this specification are applicable to cloud database master-slave database switching scenarios such as version upgrades, data migration (data center closures, machine risk warnings, etc.), and resource elastic scaling (large-scale resource scheduling to increase sales rates, etc.).

[0047] Cloud databases are database service systems that feature elastic scalability, a distributed architecture, high throughput, and low latency. Using virtualization technology, cloud databases integrate physical resources, providing on-demand database instances, supporting multi-tenant isolation and cross-availability zone disaster recovery. For example, in IoT scenarios, cloud databases are deployed as distributed clusters, dynamically expanding storage capacity to handle massive amounts of sensor data.

[0048] The High Availability Module (HA) is a core component of the cloud database that monitors node status, coordinates failover, and ensures service continuity. It monitors operational metrics of the primary and standby databases (such as heartbeat latency and transaction synchronization rate) in real time and executes pre-defined failover strategies to maintain service-level agreements (SLAs). For example, if the primary database's Central Processing Unit (CPU) continuously exceeds a threshold (e.g., >95% for 5 minutes), the HA module triggers the standby database promotion process, working in conjunction with the load balancing module to seamlessly implement failover.

[0049] The Software Load Balancer (SLB) is a traffic control component in a cloud database responsible for distributing client requests, managing data connection requests, and optimizing resource scheduling. Optionally, the SLB supports both Layer 4 (TCP / UDP) and Layer 7 (HTTP / Redis protocol) load balancing. It also provides routing policies such as connection draining and minimum connections. For example, in resource elastic scaling scenarios, the SLB distributes new data requests for online transaction processing (OLTP) to the backup database while maintaining connections to the primary database for legacy data for online analytical processing (OLAP).

[0050] The old master database is the database master node instance used for reading and writing data before the switchover. The old master database synchronizes data changes to the old standby database through logical logs, and its operational status directly affects the switchover conditions. For example, the old master database might be a Redis instance that continuously receives and writes sensor data.

[0051] The old standby database is a standby database node instance used to synchronize data with the primary database before a switchover. The old standby database synchronizes data changes with the primary database using logical logs. For example, the old standby database also runs a Redis instance and continuously receives synchronized sensor data.

[0052] The operational status is an indicator of the health of the database node instance, including performance parameters, synchronization progress, and fault indicators. Optionally, through a comprehensive assessment of heartbeat detection, transaction identifier comparison, and resource monitoring, it is marked as "switchable" when the switchover conditions are met. For example, the operational status of the old primary database is: CPU load 82%, replication delay 0 bytes, no blocked transactions; the operational status of the old standby database is: 40% memory remaining, and active synchronization threads.

[0053] Switchover conditions are a set of pre-set logical rules that trigger a switchover between the primary and standby databases. These conditions can include data consistency, resource thresholds, and manual intervention flags. For example, in a data migration scenario, a switchover condition is satisfied when the synchronization progress of the old standby database reaches 100% and the administrator enters the switchover command.

[0054] The load balancing module's connection draining duration (connection draining) is the timeout window during which the load balancing module stops distributing new data requests to the old primary database but maintains the old data connection alive. During the connection draining duration, executed transactions are allowed to complete and commit. Optionally, the connection draining duration is dynamically calculated based on the average transaction processing time. For example, in a data center closure scenario, when the data center is closed, the draining duration is set to 45 seconds: new data requests for online transaction processing (such as payment transactions) are immediately directed to the new primary database to ensure low latency. Old data connections for online analytical processing (such as report generation) continue to use the old primary database to complete queries within 45 seconds, avoiding interruption of complex aggregate calculations.

[0055] Optionally, when the operating status of the old master database and the old standby database meets the switching conditions, before setting the connection draining time of the load balancing module, the following specific steps are further included:

[0056] Send a heartbeat detection request to the old standby database to obtain the running status of the old standby database, and send a heartbeat detection request to the old primary database to obtain the running status of the old primary database.

[0057] Optionally, after sending a heartbeat detection request to the old standby database and obtaining the running status of the old standby database, the following specific steps are also included:

[0058] If the running status of the old standby database does not meet the switchover conditions, exit the master-slave database switchover.

[0059] Optionally, after sending a heartbeat detection request to the old master database and obtaining the running status of the old master database, the following specific steps are also included:

[0060] If the running status of the old master database does not meet the switchover conditions, exit the master-slave database switchover.

[0061] Optionally, after step 102, the method further includes:

[0062] If the setting fails, exit the master-slave database switchover.

[0063] For example, in the cloud database of the smart city traffic management system, it is used to store real-time traffic flow data and historical analysis reports, including a high availability module (HA), a load balancing module (SLB), an old master database, and an old backup database. The old master database has a corresponding virtual IP: 192.168.1.100, which continuously receives online transaction processing write requests from 3,000 roadside sensors (5,000 INSERT operations per second). The old backup database has a corresponding virtual IP: 192.168.1.200, which synchronizes the master database data through logical logs, and the delay is always less than 50ms. Multiple clients have established 200 online transaction processing connections and 15 online analytical processing long connections with the old master database through the virtual IP. In the scenario where the cloud database is upgraded from v5.7 to v8.0, the high availability module performs the following operations:

[0064] A heartbeat check request was sent to the old standby database, revealing its operating status: CPU usage: 35%, replication delay: 0 bytes, and synchronization thread status: active. A heartbeat check request was also sent to the old primary database, revealing its operating status: CPU usage: 78%, number of active transactions: 12, and disk I / O operations per second: 15,000. The operating status of both the old primary and standby databases met the failover criteria (standby database synchronization delay ≤ 100 milliseconds and no blocking transactions on the primary database). The load balancing module's connection draining time was set to 60 seconds.

[0065] In step 102, a connection draining time is set to reserve a time window for processing the old master database data connection, thereby preventing forced disconnection from directly disconnecting the old data connection.

[0066] Step 104: Set the write permission of the old master database to stop writing.

[0067] The write permission for the old primary database defines the permission status of the database node instance that allows it to perform data modification operations, such as INSERT, UPDATE, and DELETE. Dynamically adjusting write permissions can control data flow and ensure data consistency between the primary and standby databases during a failover. For example, if the write permission for the old primary database is "Allow Write," it will continue to process data write requests (e.g., 5000 INSERT operations per second). If the write permission for the old primary database is "Stop Write," it will stop processing data write requests and only allow data read requests.

[0068] Set the write permission of the old master database to disable writes. One option is to use database instructions to disable writes on the old master database. For example, use the Redis command CONFIG SET to set the permission to readonly, thus disabling writes to the old master database. Another option is to call the cloud database management interface to modify the write permission of the old master database to disable writes. For example, call the cloud database management API to modify the instance attribute to "read-only mode." Another option is to modify the write permission of the old master database to disable writes in the database configuration file. This is not limited here.

[0069] For example, the write permission of the old master database (192.168.1.100) is set to stop writing.

[0070] In step 104 , the write permission of the old master database is dynamically disabled, forcing subsequent data modification operations to be transferred to the new master database. This avoids data conflicts caused by dual-master writes during the switch and ensures data consistency between the master and standby databases.

[0071] Step 106: After completing data synchronization between the old standby database and the old primary database, the old standby database is switched to the new primary database, and the connection draining time is triggered so that the load balancing module suspends the old data connection with the old primary database within the connection draining time and distributes new data requests to the new primary database.

[0072] The new primary database is the primary node instance of the database used for reading and writing data after the switchover. The new primary database synchronizes data changes to the new standby database through logical logs, and its operational status directly affects the switchover conditions. For example, the old standby database (original IP: 192.168.1.200) is promoted to the new primary database and receives all new write requests for online transaction processing.

[0073] The old data connection to the old primary database is the persistent data link established by the client with the old primary database before the switchover. This includes short connections for online transaction processing (OTA) and long connections for online analytical processing (OLAP). During the switchover, the old data connection must be kept alive to complete uncommitted transactions or long queries. For example, consider 15 established long connections for online analytical processing.

[0074] New data requests are data operation requests initiated by clients after the switch and must be directly routed to the new primary database for processing. These requests can include new read and write requests and retry requests. Distributing these requests to the old primary database should be avoided to prevent data conflicts. For example, during a cloud database version upgrade, new sensor data write requests (5,000 INSERTs per second) may occur.

[0075] Regarding data synchronization between the old standby database and the old primary database, one optional judgment method is to use the global transaction identifier to determine whether the old standby database and the old primary database are data synchronized. Another optional judgment method is to use the log sequence number to determine whether the old standby database and the old primary database are data synchronized. Another optional judgment method is to use the data offset to determine whether the old standby database and the old primary database are data synchronized. These are not limited here.

[0076] To switch the old standby database to the new primary database, one option is to use database commands to switch it to the new primary database. For example, using the Redis command SLAVEOF NO ONE to allow write access to the old standby database. Another option is to call the cloud database management interface to change the write permissions of the old standby database to allow writes. For example, calling the cloud database management API to change the instance attribute to "read-write mode." Another option is to change the write permissions of the old standby database to allow writes in the database configuration file. This is not limited here.

[0077] To trigger the connection draining time, one optional method is to send a draining instruction to the load balancing module to start triggering the connection draining time. Another optional method is to call the triggering interface of the load balancing module to clear the connection draining time of the load balancing module.

[0078] Suspend old data connections to the old primary. One option is for the load balancing module to mark the old primary's active connections as draining, halting new data connections while allowing old data connections. For example, if the SLB detects 200 online transaction processing connections to the old primary (IP: 192.168.1.100), it will set their state to "DRAINING," allowing only incomplete transactions on the old data connections to commit and rejecting new data requests. Another option is to adjust TCP keepalive parameters to extend the keepalive time of old data connections. For example, setting the keepalive time for the old primary connection to 60 seconds is not a limit here.

[0079] One option for distributing new data requests to the new primary database is for the load balancing module to update the virtual network address binding, remapping the virtual network address of the old primary database to the new primary database. This allows new data requests to be distributed to the new primary database. For example, the SLB module can call an API to modify the VIP configuration. Another option is to remap the domain name address of the old primary database to the new primary database through the domain name system. For example, the A record for XXXX.com can be updated from the old primary database's IP address (192.168.1.100) to the new primary database's IP address (192.168.1.200). This is not limited here.

[0080] For example, the High Availability (HA) module detects that data synchronization between the old standby database and the old primary database is complete. It then executes the command "SLAVEOF 192.168.1.200" to promote it to the new primary database (IP: 192.168.1.200). It then sends the drain command "StartDraining(60, "192.168.1.100")" to the Load Balancing (SLB) module, triggering the connection draining period. The Load Balancing module sets the 15 OLAP persistent connections of the old primary database (192.168.1.100) to "DRAINING," allowing unfinished report queries to continue for 60 seconds while rejecting new queries. The Load Balancing module then binds the virtual IP (192.168.1.100) to the new primary database (192.168.1.200), immediately routing new sensor data (e.g., 5,000 INSERTs per second) to the new primary database.

[0081] In step 106, when the old backup database is promoted to the new primary database after data synchronization is completed, the connection draining mechanism is triggered to enable the load balancing module to keep the old data connection suspended, while directing new data requests to the new primary database, thereby ensuring real-time response to new requests during switching and retaining the availability of the old data connection.

[0082] Step 108: Reconnect the old data connection to the new master database.

[0083] One option to reconnect the old data connection to the new primary database is to use session migration technology. For example, when executing the REDIRECT protocol and returning -REDIRECTNewHostNewPort, disconnect the old connection, reestablish a connection to NewHost and NewPort, and retry the command. Another option is to call the load balancing module's application programming interface (API) to reconnect the old data connection to the new primary database. Another option is to use the automatic retry mechanism of the cloud database driver layer to reconnect the old data connection to the new primary database.

[0084] It's important to note that under the existing switchover process, the primary database is set to read-only. Consequently, when a request reaches the primary database, it immediately returns a read-only error, requiring a retry and causing unavailability of the cloud database. By modifying the Tair kernel, this read-only state can be avoided. Instead, the client's old data connection is suspended. When the old primary database becomes the new standby database, the modified redirect protocol is returned to the old data connection, instructing the client to access the new primary database. Accordingly, the new redirect protocol is designed as follows: -REDIRECTNewHostNewPort.

[0085] For example, the High Availability (HA) module triggers the session migration process by sending a RedirectConnections("192.168.1.100", "192.168.1.200") command to the Load Balancing (SLB) module. Using the TCP-based MPTCP (Multipath TCP) protocol, the Load Balancing module synchronizes the session state (such as query context and temporary tables) of 15 persistent online analytical processing (OLAP) connections from the old primary to the new primary. Client connections are automatically switched to the new primary's virtual IP address (192.168.1.200), seamlessly completing the reconnection. Simultaneously, 200 short online transaction processing (OLTP) connections are reestablished using the new primary's address, driven by the client, as the draining period has completed.

[0086] In the embodiments of this specification, by setting the connection draining time, a time window for processing the data connection of the old master database is reserved to avoid forced disconnection that causes the old data connection to be directly disconnected; when the old backup database is promoted to the new master database after data synchronization is completed, the connection draining mechanism is triggered to make the load balancing module keep the old data connection suspended, and at the same time, new data requests are directed to the new master database, which not only ensures the real-time response of new requests during the switch, but also retains the availability of the old data connection; under the premise of data consistency, the suspended old data connection is smoothly migrated to the new master database through active redirection, rather than passive disconnection and reconstruction. This process completes the seamless switching of the master and backup databases without interrupting the existing data services through the dynamic coordination of the draining time, the diversion control of the old and new connections, and the coordination of redirection after synchronization, eliminating the unavailable time caused by forced disconnection, achieving the simultaneous guarantee of data consistency and service continuity, and further improving availability.

[0087] In an optional embodiment of this specification, step 108 includes the following specific steps:

[0088] The virtual network address of the new master database is sent to the client, so that the client can send a reconnection request for the old data connection to the new master database based on the virtual network address to complete the reconnection of the old data connection.

[0089] A virtual network address is a logical network identifier used in cloud databases to abstract the location of database nodes. It can be a virtual IP (VIP) or a domain name. Virtual network addresses decouple physical nodes from database node instances. These addresses are dynamically bound to different physical nodes during the switchover process, ensuring client-unaware access. For example, the virtual network address "db.citytraffic.vip" always points to the current primary database (192.168.1.100 before the switchover and 192.168.1.200 after the switchover), eliminating the need for clients to modify their connection configuration.

[0090] Clients are terminal applications or middleware that access cloud database services. They establish persistent connections to cloud databases using database protocols such as Redis. Clients typically implement fault-tolerance mechanisms such as automatic retries and connection pools to cope with network fluctuations.

[0091] A reconnection request for the old data connection is a request initiated by the client to reestablish the connection with the new primary database. This request carries the identifiers of the old data connection (such as the thread ID and temporary table references) to maintain transaction continuity. For example, when an OLAP client receives the -REDIRECT command, it automatically reconnects to the new primary database at 192.168.1.200:3306 and includes the original query ID "Q-20231125-0852" to resume the interrupted aggregation calculation.

[0092] For example, the High Availability (HA) module broadcasts the new master database's virtual network address, "iot-db.prod.vip," to all clients (2,000 device gateways). After the device gateway's MQTT driver detects a connection heartbeat timeout, it automatically reestablishes the connection using the cached redirect address, "iot-db.prod.vip:1883," and resumes the original device state synchronization session.

[0093] In the embodiments of this specification, transparent mapping of virtual network addresses works in conjunction with the client's automated reconnection mechanism to achieve lossless migration of connection sessions during physical node switching. This avoids hard-coded client configuration dependencies and ensures deterministic reconnection behavior through redirection instructions, making the client unaware of underlying database changes.

[0094] In an optional embodiment of the present specification, after sending the virtual network address of the new primary library to the client, the following specific steps are further included:

[0095] If the reconnection request for the old data connection fails, disconnect the old data connection.

[0096] The reconnection request for the old data connection fails. One optional judgment method is: the network of the reconnection request for the old data connection times out. Another optional judgment method is: the reconnection request protocol of the old data connection is incompatible. Another optional judgment method is: insufficient resources required for the reconnection request of the old data connection. These are not limited here.

[0097] One option for disconnecting the old data connection is to call the load balancing module's forced disconnect interface to disconnect the old data connection. Another option is to adjust the timeout parameter to trigger automatic disconnection of the old data connection, which is not limited here.

[0098] For example, after receiving the virtual network address (traffic-db.city.vip) of the new master database, a client (such as a roadside sensor data collection service) attempts to reconnect to the new master database (IP: 192.168.1.200). If the client does not have REDIRECT protocol support enabled (for example, some legacy systems still use fixed IP connections), the reconnection request to the old data connection fails. At this point, the load balancing module (SLB) detects the reconnection failure and calls the ForceDisconnect("192.168.1.100", 3306) interface, sending a TCP RST packet to the remaining connection to the old master database to forcibly release resources.

[0099] In the embodiments of this specification, by coordinating active disconnection with a timeout strategy, the deterministic release of residual connections is ensured, resource leakage caused by zombie connections is prevented, and the request throughput of the new primary database is improved through rapid recycling.

[0100] In an optional embodiment of the present specification, before step 106, the following specific steps are further included:

[0101] Record the data offset of the old master database;

[0102] Detect the data offset of the old standby database;

[0103] When the data offset of the old standby database is consistent with the data offset of the old primary database, data synchronization between the old standby database and the old primary database is determined to be complete.

[0104] The data offset of the old master database identifies the location of the data that has been persisted in the old master database and is used to quantify the progress of data synchronization between the primary and standby databases. For example, the data offset of the old master database (192.168.1.100) is LSN#183502, indicating that the 183502nd log record has been processed, corresponding to the most recent sensor data write transaction.

[0105] The data offset of the old standby database indicates the location of the data that has been persisted in the old standby database. For example, the data offset of the old standby database (192.168.1.200) is LSN#183502, which is consistent with the old master database, indicating that all sensor data has been synchronized.

[0106] Record the data offset of the old master. One option is to execute the master status acquisition instruction (such as the INFO replication command and extract the master_repl_offset field from the output) to record the data offset of the old master. Another option is to record the data offset of the old master through the master replication protocol.

[0107] To detect the data offset of the old standby database, one option is to execute the standby database status acquisition instruction (for example, the INFO replication command, extract the slave_repl_offset field from the output) to detect the data offset of the old standby database. Another option is to use the standby database's replication protocol to detect the data offset of the old standby database.

[0108] For example, in a cloud database version upgrade scenario, the High Availability (HA) module records the old master database's current LSN as 0 / 15D38F0 through the master database's replication protocol. The old backup database's current LSN is also detected through the replication protocol. If the two are consistent, data synchronization is determined to be complete, triggering the subsequent master-slave database switchover process.

[0109] In the embodiments of this specification, by real-time monitoring of the consistency of the data offsets of the primary and standby databases, it is ensured that the switch is only executed when the data is fully synchronized, thereby avoiding data loss or inconsistency caused by lagging data in the standby database.

[0110] In an optional embodiment of this specification, after step 104, the following specific steps are further included:

[0111] When the data synchronization time between the old standby database and the old primary database exceeds the preset time threshold, the write permission of the old primary database is set to allow writing, so that the old data connection of the old primary database can maintain data writing.

[0112] The data synchronization duration between the old standby database and the old primary database is the duration from the time the old primary database stops writing to the time the data offsets on the old standby database reach consistency with those on the old primary database. This duration quantifies the efficiency of data synchronization between the primary and standby databases and is an important indicator for determining abnormal timeouts during the switchover process. For example, after the old primary database (IP: 192.168.1.100) stops writing, the old standby database (IP: 192.168.1.200) needs to synchronize the last batch of sensor data (e.g., 1 million INSERT records). This data synchronization takes 12 seconds.

[0113] The preset duration threshold is the pre-configured maximum allowable data synchronization window. If this threshold is exceeded, synchronization is considered abnormal and a rollback is triggered. The preset duration threshold is dynamically adjusted based on project tolerance, network latency, and data volume. The preset duration threshold is set to 30 seconds. If the synchronization timeout exceeds this threshold, write permissions to the old master database are automatically restored to avoid request blocking.

[0114] Set the write permission of the old master database to allow writes. One option is to disable writes on the old master database using database commands, for example, by using the Redis command SLAVEOF NO ONE to allow writes on the old master database. Another option is to call the cloud database management interface to change the write permission of the old master database to allow writes, for example, by calling the cloud database management API to change the instance attribute to "read-write mode." Another option is to change the write permission of the old master database to allow writes in the database configuration file, which is not limited here.

[0115] For example, in a cloud database resource auto-scaling scenario, the old primary database (vCPU: 16 cores) triggered a failover due to excessive load. The High Availability (HA) module set a preset 60-second synchronization threshold, but detected that network congestion on the old standby database was causing data synchronization to take 65 seconds (exceeding the threshold). The HA module then called the management API SetWritePermission("192.168.1.100", "ENABLE") to restore write permissions to the old primary database and sent an alert to the administrator: "Synchronization timed out, failover aborted."

[0116] In the embodiment of this specification, a timeout rollback mechanism with a preset time threshold is used to automatically restore the write permission of the old master database when data synchronization is abnormal, thereby avoiding long-term service unavailability caused by synchronization delay of the backup database.

[0117] In an optional embodiment of the present specification, triggering the connection draining time in step 106 includes the following specific steps:

[0118] After the connection draining period is triggered, set the write permission of the old master database to allow writing so that the old data connection of the old master database can continue to write data.

[0119] Set the write permission of the old master database to allow writing. One optional method is: set the write permission of the old master database to stop writing through database instructions. Another optional method is: call the management interface of the cloud database to modify the write permission of the old master database to allow writing. Another optional method is: modify the write permission of the old master database to allow writing in the database configuration file. There is no limitation here.

[0120] For example, the high availability module (HA) detects that data synchronization between the old standby database (IP: 192.168.1.200) and the old primary database (IP: 192.168.1.100) is complete (LSNs are consistent), triggering the connection drain duration instruction StartDraining(45, "192.168.1.100"). Simultaneously, the HA module calls the management API SetWritePermission("192.168.1.100", "ENABLE") to restore write permissions to the old primary database, transitioning it to the new standby database role.

[0121] In the embodiment of this specification, by synchronously triggering the draining time and the write permission recovery operation, it is ensured that the old master database can still process the legacy transactions for a short time after the switch, while avoiding conflicts in writing new data.

[0122] In an optional embodiment of this specification, step 108 includes the following specific steps:

[0123] Switch the old primary database to the new standby database and set the write permission of the new standby database to allow writes so that the old data connection of the old primary database can maintain data writes.

[0124] Reconnect the old database to the new master database.

[0125] The new standby database is a standby database node instance used for reading and writing data after the switchover. The new standby database continuously receives data changes from the new primary database through logical logs and maintains data consistency with the primary database. For example, the old primary database (original IP: 192.168.1.100) is downgraded to a new standby database, used only to synchronize sensor data writes with the new primary database (IP: 192.168.1.200).

[0126] To switch the old master database to the new slave database, one optional method is to use database instructions to switch the old master database to the new slave database. Another optional method is to use the cloud database management interface to modify the write permission of the old master database to stop writing. Another optional method is to modify the write permission of the old master database to stop writing in the database configuration file. There is no limitation here.

[0127] Set the write permission of the new standby database to allow writing. One optional method is to set the write permission of the new standby database to stop writing through database instructions. Another optional method is to call the management interface of the cloud database to modify the write permission of the new standby database to allow writing. Another optional method is to modify the write permission of the new standby database to allow writing in the database configuration file. There is no limitation here.

[0128] To reconnect the old data connection to the new primary database, one optional method is to reconnect the old data connection to the new primary database through session migration technology, another optional method is to call the application programming interface of the load balancing module to reconnect the old data connection to the new primary database, and another optional method is to use the automatic retry mechanism of the cloud database driver layer to reconnect the old data connection to the new primary database. There is no limitation here.

[0129] Optionally, after switching the old master database to the new slave database, the following specific steps are also included:

[0130] If the switch fails, exit the master-slave database switchover.

[0131] Optionally, after setting the write permission of the new standby database to allow writing, the following specific steps are also included:

[0132] If the setting fails, exit the master-slave database switchover.

[0133] For example, the High Availability (HA) module calls the Cloud Database Management API "PromoteToStandby(192.168.1.100") to switch the old primary database (IP: 192.168.1.100) to the new standby database. It then uses the Cloud Database Management API "SetReplicationPermission(192.168.1.100," "ENABLE") to enable synchronization write permissions. The new standby database then begins synchronizing real-time traffic flow data from the new primary database (IP: 192.168.1.200) but rejects direct write requests from clients.

[0134] In this embodiment, by downgrading the old primary database to a new standby database and restoring its write permissions, a stable data synchronization link is established between the new primary and standby databases, preventing synchronization interruptions caused by completely disabling writes on the old primary database. Furthermore, the new standby database only processes synchronized data and does not accept client requests, thus maintaining the high availability of the dual-node architecture while ensuring data consistency.

[0135] In an optional embodiment of this specification, after step 108, the following specific steps are further included:

[0136] Clears the connection draining time of the load balancing module.

[0137] To clear the connection draining time of the load balancing module, one optional method is to send a draining instruction to the load balancing module to clear the connection draining time of the load balancing module. Another optional method is to call the clearing interface of the load balancing module to clear the connection draining time of the load balancing module.

[0138] For example, the old primary database (192.168.1.100) originally processed device status reports (10,000 updates per second), and the old backup database (192.168.1.200) had a synchronization delay of 0 milliseconds. The High Availability (HA) module called the ClearDraining interface of the Load Balancing (SLB) module to terminate the draining state of the old primary database, freeing up its computing resources for other instances. After being demoted to the new backup database, the old primary database was automatically added to the resource pool for elastic scaling scheduling.

[0139] In the embodiments of this specification, by linking the clearing drain time with resource recovery, not only is a seamless switching achieved, but the resource allocation efficiency of the cloud database is also optimized.

[0140] In an optional embodiment of the present specification, after step 106, the following specific steps are further included:

[0141] Disconnect the old data connection if the connection drain time is exceeded.

[0142] To disconnect old data connections, one option is to call the load balancing module's force disconnect interface. For example, you can call ForceDisconnect("192.168.1.100", 3306) to disconnect all old data connections on the old master database. Another option is to adjust timeout parameters to automatically disconnect old data connections. For example, you can modify the old master database's tcp_keepalive_time parameter to 0 seconds to trigger automatic disconnection of old data connections. This is not limited here.

[0143] For example, if there are still 3 unfinished report queries among 15 online analytical processing long connections, the forced disconnection interface of the load balancing module (SLB) is called, the load balancing module is called to send TCP FIN packets to terminate these connections, and the disconnection log is recorded.

[0144] In this embodiment, by forcibly releasing residual connection resources, we avoid uneven load on the new primary database caused by long transactions blocking it, while ensuring efficient recovery of system resources and improving the overall throughput of the cloud database. Combined with dynamic control of the draining duration, this approach not only ensures transaction integrity during the switchover, but also achieves deterministic resource recovery.

[0145] See also Figure 2 , Figure 2 A flowchart of another method for switching between a primary and a backup database in a cloud database provided by an embodiment of this specification is shown, which is applied to a load balancing module of the cloud database, wherein the cloud database also includes a high availability module, an old primary database, and an old backup database; the method includes the following specific steps:

[0146] Step 202: During the connection draining time, suspend the old data connection with the old master database, and distribute the new data request to the new master database, wherein the steps of the above method are executed in the high availability module.

[0147] Suspend old data connections to the old primary. One option is for the load balancing module to mark the old primary's active connections as draining, halting new data connections while allowing old data connections. For example, if the SLB detects 200 online transaction processing connections to the old primary (IP: 192.168.1.100), it will set their state to "DRAINING," allowing only incomplete transactions on the old data connections to commit and rejecting new data requests. Another option is to adjust TCP keepalive parameters to extend the keepalive time of old data connections. For example, setting the keepalive time for the old primary connection to 60 seconds is not a limit here.

[0148] One option for distributing new data requests to the new primary database is for the load balancing module to update the virtual network address binding, remapping the virtual network address of the old primary database to the new primary database. This allows new data requests to be distributed to the new primary database. For example, the SLB module can call an API to modify the VIP configuration. Another option is to remap the domain name address of the old primary database to the new primary database through the domain name system. For example, the A record for XXXX.com can be updated from the old primary database's IP address (192.168.1.100) to the new primary database's IP address (192.168.1.200). This is not limited here.

[0149] For example, the load balancing module sets the 15 online analytical processing persistent connections of the old primary database (192.168.1.100) to "DRAINING", allowing unfinished report queries to continue executing for 60 seconds, during which new queries are rejected. The load balancing module binds the virtual IP (192.168.1.100) to the new primary database (192.168.1.200), and new sensor data (such as 5,000 INSERTs per second) is immediately routed to the new primary database.

[0150] In the embodiments of this specification, by setting the connection draining time, a time window for processing the data connection of the old master database is reserved to avoid forced disconnection that causes the old data connection to be directly disconnected; when the old backup database is promoted to the new master database after data synchronization is completed, the connection draining mechanism is triggered to make the load balancing module keep the old data connection suspended, and at the same time, new data requests are directed to the new master database, which not only ensures the real-time response of new requests during the switch, but also retains the availability of the old data connection; under the premise of data consistency, the suspended old data connection is smoothly migrated to the new master database through active redirection, rather than passive disconnection and reconstruction. This process completes the seamless switching of the master and backup databases without interrupting the existing data services through the dynamic coordination of the draining time, the diversion control of the old and new connections, and the coordination of redirection after synchronization, eliminating the unavailable time caused by forced disconnection, achieving the simultaneous guarantee of data consistency and service continuity, and further improving availability.

[0151] The above is a schematic solution of another method for switching between the primary and secondary databases of a cloud database in this embodiment. Figure 2 Technical solution and method for switching between primary and secondary databases of cloud database Figure 1 The technical solution of the cloud database master-slave database switching method belongs to the same concept. Figure 2 For details not described in detail in the technical solution of the cloud database master-slave database switching method, please refer to Figure 1 Description of the technical solution for the master-slave database switching method of the cloud database.

[0152] Regarding the above Figure 1 and Figure 2 Regarding the master-slave database switching method of the cloud database, it should be noted that the seamless switching technology uses the connection draining capability of the load balancing module to suspend the old data connection of the old master database on a virtual IP, obtain the correct response, and thus implement the logic of seamlessly reconnecting (forwarding) the subsequent old data connection to the new slave database after the switch.

[0153] Specifically, the architecture diagram of the senseless switching is as follows: Figure 3 As shown, Figure 3 A schematic diagram of the architecture of a single virtual network address in a method for switching between a primary and a secondary database of a cloud database provided by one embodiment of this specification is shown:

[0154] The cloud database server exposes the same access entrance to the outside world through the domain name system, which is actually bound to the current primary database (the old primary database before the switch and the new primary database after the switch).

[0155] The master-slave database switchover process is as follows:

[0156] 1. Set the old master database to stop writing;

[0157] 2. Wait for data synchronization between the old primary database and the old backup database to be completed;

[0158] 3. Promote the old standby database to the new primary database;

[0159] 4. Set the connection drain time to 60 seconds;

[0160] 5. Demote the old master database to the new standby database;

[0161] 6. The new standby database resumes writing and returns a connection redirection;

[0162] 7. After 15 seconds, disconnect the old data connection to complete the connection reset response.

[0163] Figure 3 The architecture shown has the following advantages:

[0164] 1. High availability switching is fast and does not rely on domain name system switching.

[0165] 2. It can provide a unique high-availability address to avoid changing the connection address when a failure occurs. The technical effects that can be achieved are:

[0166] 3. Greatly reduce the impact of active switching processes initiated by users or operation and maintenance clients.

[0167] 4. It plays a key role in improving the smoothness of large-scale cloud computing resource scheduling.

[0168] and Figure 3 The architecture diagram shown corresponds to Figure 4 A timing flow chart of a method for switching between a primary and a secondary database of a cloud database provided by one embodiment of this specification is shown:

[0169] 1. The high availability module pings the old standby database and checks its operating status.

[0170] 2. Confirm that the operating status of the old standby database meets the switchover conditions;

[0171] 3. The high availability module pings the old master database;

[0172] 4. Confirm that the operating status of the old master database meets the switch conditions;

[0173] 5. The high availability module sets the connection draining time to 60 seconds for the load balancing module;

[0174] 6. The high availability module sets the write permission of the old master database to stop writing;

[0175] 7. The setting is successful;

[0176] 8. The high availability module waits for data synchronization between the old standby database and the old primary database to be completed;

[0177] 9. Data synchronization is completed;

[0178] 10. The high availability module switches the old standby database to the new primary database;

[0179] 11. The high availability module switches the backend load balancing node, triggering the connection draining time;

[0180] 12. The load balancing module is triggered successfully;

[0181] 13. The high availability module reversely mounts the old master database as the new standby database;

[0182] 14. The high availability module sets the write permission of the new standby database to allow writing and returns a connection redirect.

[0183] 15. Success;

[0184] 16. The high availability module disconnects the old data connection when the connection draining time is exceeded;

[0185] 17. Success;

[0186] 18. The high availability module clears the connection draining time of the load balancing module.

[0187] above Figure 3 and Figure 4 A single virtual network address solution is given. There is also a dual virtual network address solution that does not use the connection draining time technology for forwarding. Figure 5 A schematic diagram of the architecture of dual virtual network addresses in a method for switching between a primary and a secondary database of a cloud database provided by one embodiment of this specification is shown:

[0188] The cloud database server exposes two access portals through the domain name system, which are bound to the current primary database and the backup database respectively (the old primary database before the switch and the new primary database after the switch).

[0189] The master-slave database switchover process is as follows:

[0190] 1. Set the old master database to stop writing;

[0191] 2. Wait for data synchronization between the old primary database and the old backup database to be completed;

[0192] 3. Promote the old standby database to the new primary database;

[0193] 4. Update domain name;

[0194] 5. Demote the old master database to the new standby database;

[0195] 6. The new standby database resumes writing and returns the connection redirection.

[0196] Compared with the single virtual network address solution, the dual virtual network address achieves high-availability switching by switching the domain name. However, since the cache and switching perception delay of the domain name system is at the minute level, in a failure scenario, it will bring additional unavailability time exceeding the service level agreement (SLA).

[0197] Corresponding to the above method embodiment, this specification also provides a cloud database embodiment, Figure 6 FIG1 shows a schematic diagram of the structure of a cloud database provided by an embodiment of this specification. Figure 6 As shown, the cloud database 600 includes a high availability module 610, a load balancing module 620, an old master database 630 and an old backup database 640;

[0198] The high availability module 610 is configured to set the connection draining time of the load balancing module when the operating status of the old primary database 630 and the old standby database 640 meet the switching conditions; set the write permission of the old primary database 630 to stop writing; and switch the old standby database 640 to the new primary database after completing data synchronization between the old standby database 640 and the old primary database 630, and trigger the connection draining time.

[0199] The load balancing module 620 is used to suspend the old data connection with the old master database 630 within the connection draining time and distribute the new data request to the new master database;

[0200] The high availability module 610 is used to reconnect the old data to the new master database.

[0201] Optionally, the high availability module 610 is specifically configured to send the virtual network address of the new primary database to the client, so that the client sends a reconnection request of the old data connection to the new primary database based on the virtual network address to complete the reconnection of the old data connection.

[0202] Optionally, the high availability module 610 is further configured to disconnect the old data connection if a reconnection request for the old data connection fails.

[0203] Optionally, the high availability module 610 is further configured to record the data offset of the old primary database; detect the data offset of the old standby database; and determine that data synchronization between the old standby database and the old primary database is complete when the data offset of the old standby database is consistent with that of the old primary database.

[0204] Optionally, the high availability module 610 is further configured to set the write permission of the old master database to allow write when the data synchronization time between the old standby database and the old master database exceeds a preset time threshold, so that the old data connection of the old master database maintains data write.

[0205] Optionally, the high availability module 610 is specifically configured to trigger the connection draining time and set the write permission of the old master database to allow writing, so that the old data connection of the old master database can maintain data writing.

[0206] Optionally, the high availability module 610 is specifically used to switch the old primary database to a new standby database, and set the write permission of the new standby database to allow writing so that the old data connection of the old primary database maintains data writing; and reconnect the old data connection to the new primary database.

[0207] Optionally, the high availability module 610 is further configured to clear the connection draining time of the load balancing module.

[0208] Optionally, the high availability module 610 is further configured to disconnect the old data connection when the connection draining time is exceeded.

[0209] In the embodiments of this specification, the high availability module reserves a time window for processing the data connection of the old master database by setting the connection draining time, thereby avoiding forced disconnection that causes the old data connection to be directly disconnected; when the high availability module promotes the old backup database to the new master database after data synchronization is completed, the load balancing module triggers the connection draining mechanism to make the load balancing module maintain the old data connection suspended, while directing new data requests to the new master database, thereby ensuring real-time response to new requests during the switch and retaining the availability of the old data connection; under the premise of data consistency, the high availability module smoothly migrates the suspended old data connection to the new master database through active redirection, rather than passive disconnection and reconstruction. This process completes the seamless switching of the master and backup databases without interrupting the existing data services through the dynamic coordination of the draining time, the diversion control of the old and new connections, and the coordination of redirection after synchronization, eliminating the unavailable time caused by forced disconnection, achieving the simultaneous guarantee of data consistency and service continuity, and further improving the availability of the cloud database.

[0210] The above is a schematic diagram of a cloud database solution according to this embodiment. It should be noted that the technical solution of this cloud database shares the same concept as the technical solution of the primary / backup database switching method described above. For details not described in detail in the technical solution of the cloud database, please refer to the description of the technical solution of the primary / backup database switching method described above.

[0211] Figure 7 7 shows a block diagram of a computing device according to an embodiment of the present disclosure. Components of the computing device 700 include, but are not limited to, a memory 710 and a processor 720. The processor 720 is connected to the memory 710 via a bus 730, and a database 750 is used to store data.

[0212] Computing device 700 also includes an access device 740 that enables computing device 700 to communicate via one or more networks 760. Examples of such networks include a Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the Internet. Access device 740 may include one or more of any type of wired or wireless network interface (e.g., a Network Interface Controller (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Worldwide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, or a Near Field Communication (NFC) interface.

[0213] In one embodiment of the present specification, the above components of the computing device 700 and Figure 7 Other components not shown in the figure may also be connected to each other, for example, via a bus. Figure 7 The computing device structure block diagram shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art may add or replace other components as needed.

[0214] Computing device 700 can be any type of stationary or mobile computing device, including a mobile computer or mobile computing device (e.g., a tablet computer, personal digital assistant, laptop computer, notebook computer, netbook computer, etc.), a mobile phone (e.g., a smartphone), a wearable computing device (e.g., a smartwatch, smart glasses, etc.), or other types of mobile devices, or a stationary computing device such as a desktop computer or personal computer (PC). Computing device 700 can also be a mobile or stationary server.

[0215] The processor 720 is configured to execute the following computer program / instruction, which, when executed by the processor, implements the steps of the above-mentioned method for switching between a primary and a secondary database of a cloud database.

[0216] The above is a schematic diagram of a computing device according to this embodiment. It should be noted that the technical solution of this computing device is based on the same concept as the technical solution of the primary / backup database switching method described above for a cloud database. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the primary / backup database switching method for the cloud database described above.

[0217] An embodiment of the present specification further provides a computer-readable storage medium storing a computer program / instruction. When the computer program / instruction is executed by a processor, the steps of the above-mentioned method for switching between a primary and a secondary database of a cloud database are implemented.

[0218] The above is a schematic diagram of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium is based on the same concept as the technical solution of the primary / backup database switching method described above for a cloud database. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the primary / backup database switching method described above for a cloud database.

[0219] An embodiment of the present specification further provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the above-mentioned method for switching between a primary and a secondary database of a cloud database.

[0220] The above is a schematic diagram of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product is based on the same concept as the technical solution of the primary / backup database switching method described above for a cloud database. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the primary / backup database switching method described above for a cloud database.

[0221] The foregoing description of this specification describes specific embodiments. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0222] The computer instructions include computer program code, which may be in source code form, object code form, executable file, or some intermediate form. The computer-readable medium may include any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signals, telecommunication signals, and software distribution media. It should be noted that the content of the computer-readable medium may be appropriately increased or decreased based on the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media does not include electric carrier signals and telecommunication signals.

[0223] It should be noted that for the aforementioned method embodiments, for the sake of simplicity of description, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the embodiments of this specification are not limited by the order of the actions described, because according to the embodiments of this specification, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the embodiments of this specification.

[0224] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0225] The preferred embodiments disclosed above are intended only to help illustrate this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific embodiments described. Obviously, many modifications and variations can be made based on the content of the embodiments of this specification. This specification selects and specifically describes these embodiments in order to better explain the principles and practical applications of the embodiments of this specification, so that those skilled in the art can better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A method for switching between a primary and a secondary database of a cloud database, applied to a high availability module of a cloud database, wherein: The cloud database further includes a load balancing module, an old master database, and an old backup database; the method includes: When the operating status of the old primary database and the old standby database meets the switching conditions, the connection draining time of the load balancing module is set. The connection draining time of the load balancing module is the timeout window during which the load balancing module stops distributing new data requests to the old primary database and maintains the old data connection alive. Executed transactions are allowed to complete and commit within the connection draining time. Set the write permission of the old master library to stop writing; When data synchronization between the old standby database and the old primary database is completed, the old standby database is switched to the new primary database, and the connection draining time is triggered, so that the load balancing module suspends the old data connection with the old primary database within the connection draining time and distributes the new data request to the new primary database; Reconnect the old data connection to the new master database.

2. The method according to claim 1, reconnecting the old data connection to the new primary database, comprising: The virtual network address of the new master database is sent to the client, so that the client sends a reconnection request of the old data connection to the new master database based on the virtual network address, thereby completing the reconnection of the old data connection.

3. The method according to claim 2, further comprising, after sending the virtual network address of the new primary library to the client: If the reconnection request for the old data connection fails, disconnect the old data connection.

4. The method according to any one of claims 1 to 3, further comprising: after completing data synchronization between the old standby database and the old primary database, switching the old standby database to become the new primary database and triggering the connection draining time. Record the data offset of the old master database; Detecting the data offset of the old standby database; When the data offset of the old standby database is consistent with the data offset of the old primary database, it is determined that the data synchronization between the old standby database and the old primary database is completed.

5. The method according to any one of claims 1 to 3, further comprising, after setting the write permission of the old master library to stop writing: When the data synchronization time between the old standby database and the old master database exceeds a preset time threshold, the write permission of the old master database is set to allow writing, so that the old data connection of the old master database maintains data writing.

6. The method according to any one of claims 1 to 3, wherein triggering the connection draining duration comprises: The connection draining time is triggered, and the write permission of the old master database is set to allow writing, so that the old data connection of the old master database can maintain data writing.

7. The method according to any one of claims 1 to 3, wherein reconnecting the old data connection to the new primary database comprises: Switch the old master database to a new slave database, and set the write permission of the new slave database to allow writes, so that the old data connection of the old master database can maintain data writes; Reconnect the old data connection to the new master database.

8. The method according to any one of claims 1 to 3, further comprising, after reconnecting the old data connection to the new primary database: Clears the connection draining time of the load balancing module.

9. The method according to any one of claims 1 to 3, further comprising, after triggering the connection draining time, When the connection drain time is exceeded, the old data connection is disconnected.

10. A method for switching between a primary and a backup database of a cloud database, applied to a load balancing module of a cloud database, wherein: The cloud database further includes a high availability module, an old master database, and an old backup database; and the method includes: During the connection draining time, the old data connection with the old master database is suspended, and the new data request is distributed to the new master database, wherein the steps of the method according to any one of claims 1 to 9 are performed in the high availability module.

11. A cloud database comprising a high availability module, a load balancing module, an old master database, and an old backup database; The high availability module is used to set the connection draining time of the load balancing module when the operating status of the old master database and the old standby database meet the switching conditions, wherein: The connection draining duration of the load balancing module is the timeout window during which the load balancing module stops distributing new data requests to the old primary database and maintains the old data connection alive. Executed transactions are allowed to complete submission within the connection draining duration. The write permission of the old primary database is set to stop writing. When data synchronization between the old standby database and the old primary database is completed, the old standby database is switched to the new primary database, and the connection draining duration is triggered. The load balancing module is configured to suspend the old data connection with the old primary database within the connection draining time and distribute the new data request to the new primary database; The high availability module is used to reconnect the old data connection to the new master database.

12. A computing device comprising: memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions. When the computer program / instructions are executed by the processor, the steps of the method according to any one of claims 1 to 10 are implemented.

13. A computer-readable storage medium storing a computer program / instruction, wherein the computer program / instruction, when executed by a processor, implements the steps of the method according to any one of claims 1 to 10.

14. A computer program product comprising a computer program / instructions, which implement the steps of the method according to any one of claims 1 to 10 when executed by a processor.

Images