Main and standby database switching method of cloud database, cloud database and computing equipment

Abstract

The embodiment of the invention provides a main and standby database switching method of a cloud database, the cloud database and computing equipment, the main and standby database switching method of the cloud database is applied to a high-availability module of the cloud database, and the cloud database further comprises a load balancing module, an old main database and an old standby database; the method comprises the steps that under the condition that the operation states of an old main library and an old standby library meet switching conditions, the connection emptying duration of a load balancing module is set; setting the writing permission of the old main library to stop writing; under the condition that data synchronization of the old standby library and the old main library is completed, the old standby library is switched into a new main library, and the connection emptying duration is triggered, so that the load balancing module suspends old data connection with the old main library within the connection emptying duration and distributes a new data request to the new main library; and reconnecting the old data connection to the new main library. According to the method, non-inductive switching of the main library and the standby library is completed, unavailable time generated by forced disconnection is eliminated, data consistency and service continuity are guaranteed synchronously, and usability is improved.

Description

Technical Field

[0001] The embodiments of this specification relate to the technical field of databases, and particularly to a method for switching between a primary database and a standby 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 formed the characteristics of elastic scalability, distributed architecture, high throughput and low latency, and are suitable for scenarios such as big data, Internet of Things, and artificial intelligence.

[0003] In scenarios such as cloud database version upgrade, data migration, and resource elastic scaling, switching between the primary database and the standby database can reduce the unavailable time of the cloud database and improve the availability of the cloud database.

[0004] However, in scenarios such as cloud database version upgrade, data migration, and resource elastic scaling, considering the guarantee of data consistency and transaction integrity, the existing old data connection between the cloud database and the client will be disconnected, and there is still a certain period of unavailable time for the database. It is necessary to further eliminate this unavailable time and further improve the availability of the database. Therefore, there is an urgent need for a method for switching between the primary database and the standby database of a cloud database with seamless switching and high availability. Summary of the Invention In view of this, the embodiments of this specification provide a method for switching between a primary database and a standby database of a cloud database. One or more embodiments of this specification also relate to another method for switching between a primary database and a standby database of a cloud database, a cloud database, a computing device, a computer-readable storage medium, and a computer program product to solve the technical defects existing in the prior art.

[0005] According to the first aspect of the embodiments of this specification, a method for switching between a primary database and a standby database of a cloud database is provided, which is applied to the high-availability module of the cloud database. The cloud database also includes a load balancing module, an old primary database, and an old standby database. The method includes: When the operating states of the old primary database and the old standby database meet the switching conditions, set the connection drain duration of the load balancing module; Set the write permission of the old primary database to stop writing; When the data synchronization between the old standby database and the old primary database is completed, switch the old standby database to the new primary database and trigger the connection drain duration, so that the load balancing module suspends the old data connection with the old primary database within the connection drain duration and distributes the new data requests to the new primary database; Reconnect the old data connection to the new primary database.

[0006] According to the second aspect of the embodiments of this specification, another method for switching between a primary database and a standby database of a cloud database is provided, which is applied to the load balancing module of the cloud database. The cloud database also includes a high-availability module, an old primary database, and an old standby database. The method includes: During the connection drainage duration, suspend the old data connection with the old master database and distribute the new data requests to the new master database, where the high-availability module executes the steps of the above method.

[0007] According to the third aspect of the embodiments 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; The high-availability module is used to set the connection drainage duration of the load balancing module when the running states of the old master database and the old standby database meet the switching conditions; set 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, switch the old standby database to the new master database and trigger the connection drainage duration; The load balancing module is used to suspend the old data connection with the old master database during the connection drainage duration and distribute the new data requests to the new master database; The high-availability module is used to reconnect the old data connection to the new master database.

[0008] According to the fourth aspect of the embodiments of this specification, a computing device is provided, including: A memory and a processor; 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 master-slave database switching method of the cloud database are implemented.

[0009] According to the fifth aspect of the embodiments of this specification, a computer-readable storage medium is provided, which stores computer programs / instructions. When the computer programs / instructions are executed by the processor, the steps of the above-mentioned master-slave database switching method of the cloud database are implemented.

[0010] According to the sixth aspect of the embodiments of this specification, a computer program product is provided, including computer programs / instructions. When the computer programs / instructions are executed by the processor, the steps of the above-mentioned master-slave database switching method of the cloud database are implemented.

[0011] In one embodiment of this specification, a method for switching the master-slave database of a cloud database is provided, which is applied to the high-availability module of the cloud database. The cloud database also includes a load balancing module, an old master database, and an old standby database. The method includes: when the running states of the old master database and the old standby database meet the switching conditions, set the connection drainage duration of the load balancing module; set 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, switch the old standby database to the new master database and trigger the connection drainage duration, so that the load balancing module suspends the old data connection with the old master database during the connection drainage duration and distributes the new data requests to the new master database; reconnect the old data connection to the new master database.

[0012] By setting the connection evacuation duration, a processing time window for the old primary database connection is reserved to avoid forced disconnection, which may directly cut off the old data connection. When promoting the old standby database to the new primary database after data synchronization is completed, the connection evacuation mechanism is triggered to keep the load balancing module suspend the old data connection. Meanwhile, new data requests are directed to the new primary database, ensuring both the real-time response of new requests during the switchover and the availability of the old data connection. On the premise of data consistency, the suspended old data connection is smoothly migrated to the new primary database through active redirection instead of passive disconnection and reconstruction. This process, through the dynamic coordination of the evacuation duration, the shunt control of the old and new connections, and the cooperation of redirection after synchronization, completes the seamless switchover of the primary and standby databases without interrupting the existing data services, eliminates the unavailable time caused by forced disconnection, realizes the synchronous guarantee of data consistency and service continuity, and further improves the availability. Description of the Drawings

[0013] Figure 1 is a flowchart of a method for switching between a primary and a standby database of a cloud database provided by an embodiment of this specification; Figure 2 is a flowchart of another method for switching between a primary and a standby database of a cloud database provided by an embodiment of this specification; Figure 3 is a schematic diagram of the architecture of a single virtual network address in a method for switching between a primary and a standby database of a cloud database provided by an embodiment of this specification; Figure 4 is a timing flowchart of a method for switching between a primary and a standby database of a cloud database provided by an embodiment of this specification; Figure 5 is a schematic diagram of the architecture of a dual virtual network address in a method for switching between a primary and a standby database of a cloud database provided by an embodiment of this specification; Figure 6 is a schematic diagram of the structure of a cloud database provided by an embodiment of this specification; Figure 7 is a block diagram of the structure of a computing device provided by an embodiment of this specification. Detailed Embodiments

[0014] Many specific details are set forth in the following description in order to provide a thorough understanding of this specification. However, this specification can be implemented in many other ways different from those described herein, and those skilled in the art can make similar generalizations without departing from the connotation of this specification. Therefore, this specification is not limited by the specific embodiments disclosed below.

[0015] 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 "said" used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly dictates otherwise. It should also be understood that the term "and / or" used in one or more embodiments of this specification refers to and encompasses any and all possible combinations of one or more of the associated listed items.

[0016] It should be understood that although the terms first, second, etc. may be used in one or more embodiments of this specification to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type 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 "when" or "while" or "in response to determining".

[0017] 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 for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data that have been authorized by the user or fully authorized by all parties, and the collection, use, and processing of relevant data need to comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation entrances are provided for users to select authorization or rejection.

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

[0019] Cloud database: Refers to a database service deployed on a cloud service provider.

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

[0021] Senseless: It means that during the primary and standby database switchover, the client connections to the cloud database will not receive exceptions such as connection disconnection and command execution failure.

[0022] Active switchover: The database is switched by database administrators or the database management system within the expected time, commonly seen in scenarios such as cloud database version upgrades, data migrations, and resource elastic scaling.

[0023] Primary database: The primary node that provides database services in a cloud database.

[0024] Backup database: A backup node in a cloud database that provides database services. When the primary database fails, the backup database will be replaced to continue providing database services.

[0025] Service Level Agreement (SLA): A contract between a cloud provider and a 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.

[0026] In this specification, a method for switching a primary and a backup database of a cloud database is provided. This specification also relates to a method for switching 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.

[0027] See also Figure 1 , Figure 1 A flowchart of a method for switching a primary and standby database of a cloud database provided by an embodiment of the present specification is shown, which is applied to a high-availability module of a cloud database, wherein the cloud database further includes a load balancing module, an old primary database and an old standby database; the method includes the following specific steps: Step 102: When the running status of the old master database and the old standby database meets the switching condition, the connection draining time of the load balancing module is set.

[0028] The embodiments of this specification are applied to cloud database version upgrades, data migration (computer room closure, machine risk warning, etc.), resource elastic scaling (large-scale resource scheduling to improve sales rate, etc.), and other cloud database master-slave database switching scenarios.

[0029] Cloud database is a database service system with elastic expansion capability, distributed architecture, high throughput and low latency. Cloud database integrates physical resources through virtualization technology, provides on-demand database instances, supports multi-tenant isolation and cross-availability zone disaster recovery. For example, in the IoT scenario, cloud database is deployed in the form of distributed clusters, dynamically expanding storage capacity to handle massive sensor data processing.

[0030] The High Availability Module (HA) is a core functional component in the cloud database used to monitor node status, coordinate fault switching, and ensure service continuity. It detects the operating indicators of the primary and standby databases (such as heartbeat delay and transaction synchronization rate) in real time and executes the preset switching strategy to maintain the service level agreement (SLA). For example, when it is detected that the central processing unit (CPU) of the primary database continues to exceed the threshold (such as >95% for 5 minutes), the high availability module triggers the standby database promotion process and works with the load balancing module to complete the seamless switching.

[0031] The load balancing module (Software Load Balancer, abbreviated as SLB) is a traffic control component in the cloud database responsible for distributing client requests, managing data connection requests, and optimizing resource scheduling. Optionally, the load balancing module supports layer 4 (TCP / UDP) and layer 7 (HTTP / Redis protocol) load balancing, and the load balancing module provides routing policies such as connection draining and least connections. For example, in the scenario of resource elastic scaling, the load balancing module distributes new data requests for online transaction processing (OLTP) to the standby database, while maintaining the old data connections for online analytical processing (OLAP) to the primary database.

[0032] The old primary database is the database primary node instance used for reading and writing data before the switch. The old primary database synchronizes data changes to the old standby database through logical logs, and its running state directly affects the switching conditions. For example, the old primary database is a running Redis instance that continuously receives the reading and writing of sensor data.

[0033] The old standby database is the database standby node instance used for synchronizing the primary database data before the switch. The old standby database completes the synchronization of data changes to the primary database through logical logs. For example, the old standby database is also a running Redis instance that continuously receives the synchronous writing of sensor data.

[0034] The running state is a health metric for the database node instance, including performance parameters, synchronization progress, and fault flags. Optionally, through comprehensive determination of heartbeat detection, transaction identifier comparison, and resource monitoring, it is marked as "switchable state" when the switching conditions are met. For example, the running state of the old primary database is: CPU load 82%, replication delay 0 bytes, no blocked transactions, and the running state of the old standby database is: 40% remaining memory, synchronization thread active.

[0035] The switching conditions are a set of preset logical judgment rules that trigger the primary-standby database switch. The switching conditions can include data consistency, resource thresholds, and manual intervention flags. For example, in the data migration scenario, when the synchronization progress of the old standby database reaches 100% and the administrator enters the switching instruction, the condition is met.

[0036] The connection draining duration of the load balancing module is the timeout window period during which the load balancing module stops distributing new data requests to the old primary database but maintains the survival of the old data connections. During the connection draining duration, the committed transactions are allowed to be completed. Optionally, the connection draining duration is dynamically calculated based on the average transaction processing time. For example, in the scenario of data center decommissioning, when decommissioning the data center, the draining duration is set to 45 seconds: the new data requests for online transaction processing (such as payment transactions) are immediately directed to the new primary database to ensure low latency. The old data connections for online analytical processing (such as report generation) continue to use the old primary database to complete the queries within 45 seconds to avoid interrupting complex aggregation calculations.

[0037] Optionally, before setting the connection draining duration of the load balancing module when the operating states of the old primary database and the old standby database meet the switching conditions, the following specific steps are further included: Send a heartbeat detection request to the old standby database to obtain the operating state of the old standby database, and send a heartbeat detection request to the old primary database to obtain the operating state of the old primary database.

[0038] Optionally, after sending a heartbeat detection request to the old standby database to obtain the operating state of the old standby database, the following specific steps are further included: If the operating state of the old standby database does not meet the switching conditions, exit the primary-standby database switching.

[0039] Optionally, after sending a heartbeat detection request to the old primary database to obtain the operating state of the old primary database, the following specific steps are further included: If the operating state of the old primary database does not meet the switching conditions, exit the primary-standby database switching.

[0040] Optionally, after step 102, the following is further included: If the setting fails, exit the primary-standby database switching.

[0041] Exemplarily, in the cloud database of the smart city traffic management system, which is used to store real-time traffic flow data and historical analysis reports, it includes a high availability module (HA), a load balancing module (SLB), an old primary database, and an old standby database. The old primary database has a corresponding virtual IP: 192.168.1.100, and continuously receives online transaction processing write requests from 3000 roadside sensors (5000 INSERT operations per second). The old standby database has a corresponding virtual IP: 192.168.1.200, and synchronizes the primary database data through logical logs, with a latency always lower than 50ms. Multiple clients have established 200 online transaction processing connections and 15 online analytical processing long connections with the old primary database through the virtual IP. In the scenario of upgrading the cloud database from v5.7 to v8.0, the high availability module performs the following operations: Send a heartbeat detection request to the old standby database to obtain the running status of the old standby database: CPU usage: 35%; replication latency: 0 bytes; synchronization thread status: active. And send a heartbeat detection request to the old master database to obtain the running status of the old master database: CPU usage: 78%; number of active transactions: 12; number of disk input / output operations per second: 15,000 times. The running status of the old master database and the old standby database meets the switching conditions (standby database synchronization latency ≤ 100 milliseconds and the master database has no blocked transactions), and configure the connection draining duration of the load balancing module to be 60 seconds.

[0042] In step 102, reserve a data connection processing time window for the old master database by setting the connection draining duration to avoid the old data connection being directly disconnected due to forced disconnection.

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

[0044] The write permission of the old master database is the permission status for the database node instance to be allowed to perform data modification operations. Data modification operations include INSERT, UPDATE, DELETE, etc. By dynamically adjusting the write permission, the data flow can be controlled to ensure data consistency between the master and standby databases during the switch. For example, if the write permission of the old master database is "allow writing", it continuously processes data write requests (such as 5,000 INSERT operations per second), and if the write permission of the old master database is "stop writing", it stops processing data write requests and can only perform data read requests.

[0045] One optional way to set the write permission of the old master database to stop writing is: through database instructions, set the write permission of the old master database to stop writing. For example, use the Redis command CONFIG SET to set readonly to prohibit the old master database from writing. Another optional way is: call the management interface of the cloud database to modify the write permission of the old master database to stop writing. For example, call the cloud database management API to modify the instance attribute to "read-only mode". Another optional way is: modify the write permission of the old master database to stop writing in the database configuration file, which is not limited here.

[0046] Exemplarily, set the write permission of the old master database (192.168.1.100) to stop writing.

[0047] In step 104, dynamically disable the write permission of the old master database to force subsequent data modification operations to switch to the new master database, avoiding data conflicts caused by dual-master writing during the switch and ensuring data consistency between the master and standby databases.

[0048] Step 106: When the data synchronization between the old standby database and the old master database is completed, switch the old standby database to the new master database and trigger the connection drain duration, so that the load balancing module suspends the old data connections with the old master database within the connection drain duration and distributes the new data requests to the new master database.

[0049] The new master database is the database master node instance used for reading and writing data after the switch. The new master database synchronizes data changes to the new standby database through logical logs, and its running status directly affects the switching conditions. For example, the old standby database (original IP: 192.168.1.200) is promoted to the new master database to receive all new write requests for online transaction processing.

[0050] The old data connection with the old master database is the persistent data link established between the client and the old master database before the switch, including short connections for online transaction processing and long connections for online analytical processing. During the switch, the old data connections need to be kept alive to complete uncommitted transactions or long queries. For example, 15 established long connections for online analytical processing.

[0051] The new data request is the data operation request initiated by the client after the switch and needs to be directly routed to the new master database for processing. The new data requests can include newly added read and write requests and retry requests, and it is necessary to avoid distributing them to the old master database to cause data conflicts. For example, during the cloud database version upgrade, newly added sensor data write requests (5000 INSERTs per second).

[0052] For the data synchronization between the old standby database and the old master database, one optional judgment method is: use the global transaction identifier to judge whether the old standby database and the old master database are data synchronized. Another optional judgment method is: judge whether the old standby database and the old master database are data synchronized through the log sequence number. Another optional judgment method is: judge whether the old standby database and the old master database are data synchronized through the data offset. It is not limited here.

[0053] To switch the old standby database to the new master database, one optional method is: use a database instruction to switch the old standby database to the new master database. For example, use the Redis command SLAVEOF NO ONE to allow the old standby database to write. Another optional method is: call the management interface of the cloud database to modify the write permission of the old standby database to allow writing. For example, call the cloud database management API to modify the instance attribute to "read-write mode". Another optional method is: modify the write permission of the old standby database to allow writing in the database configuration file. It is not limited here.

[0054] To trigger the connection drain duration, one optional method is: send a drain instruction to the load balancing module to start triggering the connection drain duration. Another optional method is: call the trigger interface of the load balancing module to clear the connection drain duration of the load balancing module.

[0055] Suspend the old data connection with the old master database. An optional method is as follows: The load balancing module marks the active connections of the old master database as the draining state to pause establishing new data connections, but allows old data connections. For example, when SLB detects 200 online transaction processing connections of the old master database (IP: 192.168.1.100), it sets their status to "DRAINING", only allowing the transactions of the unfinished old data connections to be committed and rejecting new data requests. Another optional method is as follows: Adjust the keep-alive parameter of TCP to extend the survival time of the old data connection. For example, the Keepalive time of the old master database connection is set to 60 seconds, which is not limited here.

[0056] Distribute new data requests to the new master database. An optional judgment method is as follows: The load balancing module updates the virtual network address binding, remapping the virtual network address of the old master database to the new master database to distribute new data requests to the new master database. For example, SLB calls the API to modify the VIP configuration. Another optional judgment method is as follows: Remap the domain name address of the old master database to the new master database through the domain name system to distribute new data requests to the new master database. For example, update the A record of XXXX.com from the old master database IP (192.168.1.100) to the new master database IP (192.168.1.200), which is not limited here.

[0057] Exemplarily, the high-availability module (HA) detects that the data synchronization between the old standby database and the old master database is completed, executes the command SLAVEOF 192.168.1.200 to promote it to the new master database (IP: 192.168.1.200), and sends a draining instruction StartDraining(60, "192.168.1.100") to the load balancing module (SLB) to start the trigger connection draining duration. The load balancing module sets 15 online analytical processing long connections of the old master database (192.168.1.100) to "DRAINING", allowing the unfinished report queries to continue to execute for 60 seconds. During this period, new queries are rejected. The load balancing module binds the virtual IP (192.168.1.100) to the new master database (192.168.1.200), and the new sensor data (such as 5000 INSERTs per second) is immediately routed to the new master database.

[0058] In step 106, when promoting the old standby database to the new master database after the data synchronization is completed, the connection draining mechanism is triggered to make the load balancing module maintain the suspension of the old data connection, and at the same time direct the new data requests 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.

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

[0060] Reconnect the old data connection to the new primary database. An optional method is to use session migration technology to reconnect the old data connection to the new primary database. For example, when executing the REDIRECT protocol and -REDIRECTNewHostNewPort is returned, the old connection needs to be disconnected, and a new connection needs to be established to NewHost and NewPort and the command retried. Another optional method is to call the application programming interface (Application Programming Interface, abbreviated as API) of the load balancing module to reconnect the old data connection to the new primary database. 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, which is not limited here.

[0061] It should be noted that under the existing switching process, the primary database is set to read-only status, so that when a request reaches the primary database, a read-only error is immediately returned and needs to be retried, resulting in the unavailability of the cloud database. By modifying the Tair kernel, the read-only status can be avoided. Instead, the old data connection rows of the client are suspended. When the old primary database becomes the new standby database, for the old data connection, the modified redirect protocol is returned to tell the client that it needs to access the new primary database. Correspondingly, the new redirect protocol is designed as follows: -REDIRECTNewHostNewPort.

[0062] Exemplarily, the high-availability module (HA) triggers the session migration process by sending the RedirectConnections("192.168.1.100", "192.168.1.200") instruction to the load balancing module (SLB). Based on the TCP-based MPTCP (Multi-Path TCP) protocol, the load balancing module synchronizes the session states (such as query context, temporary tables) of 15 online analytical processing long connections of the old primary database to the new primary database. The client connection automatically switches to the virtual IP (192.168.1.200) of the new primary database, and the reconnection is completed without perception. At the same time, 200 online transaction processing short connections have completed the drain period transactions and are re-established by the client driver according to the new primary database address.

[0063] In the embodiments of this specification, by setting the connection drainage duration to reserve a processing time window for the old primary database data connection, it is avoided that the old data connection is directly disconnected due to forced disconnection; when the old standby database is promoted to the new primary database after data synchronization is completed, the connection drainage mechanism is triggered to keep the load balancing module hanging the old data connection, and at the same time, direct the new data requests to the new primary database, which not only ensures the real-time response of new requests during the switchover, but also retains the availability of the old data connection; on the premise of data consistency, the suspended old data connection is smoothly migrated to the new primary database through active redirection instead of passive disconnection and reconstruction. This process, through the dynamic coordination of the drainage duration, the shunt control of the old and new connections, and the cooperation of redirection after synchronization, completes the seamless switchover of the primary and standby databases without interrupting the existing data service, eliminates the unavailable time caused by forced disconnection, realizes the synchronous guarantee of data consistency and service continuity, and further improves the availability.

[0064] In an alternative embodiment of this specification, step 108 includes the following specific steps: Send the virtual network address of the new primary database to the client, so that the client, based on the virtual network address, sends a reconnection request for the old data connection to the new primary database to complete the reconnection of the old data connection.

[0065] The virtual network address is a logical network identifier used in the cloud database to abstract the location of the database node, which can be a virtual IP (VIP) or a domain name. The virtual network address decouples the physical node from the database node instance. This address is dynamically bound to different physical nodes during the switchover to ensure that the client accesses without awareness. 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), and the client does not need to modify the connection configuration.

[0066] The client is a terminal application or middleware that accesses the cloud database service and establishes a persistent connection with the cloud database through a database protocol (such as Redis). The client usually implements fault tolerance mechanisms such as automatic retry and connection pooling to cope with network fluctuations.

[0067] The reconnection request for the old data connection is a connection reconstruction request initiated by the client to the new primary database. This request carries the identifier of the old data connection (such as thread ID, temporary table reference) to maintain transaction continuity. For example, when the online analytical processing client receives the -REDIRECT instruction, it automatically initiates a reconnection to the new primary database 192.168.1.200:3306 and attaches the original query ID "Q-20231125-0852" to resume the interrupted aggregation calculation.

[0068] Exemplarily, the High Availability (HA) module updates the virtual network address "iot-db.prod.vip" of the new primary database to all clients (2,000 device gateways) through a broadcast protocol. After the MQTT driver of the device gateway detects that the connection heartbeat times out, it automatically rebuilds the connection according to the cached redirect address "iot-db.prod.vip:1883" and resumes the original device status synchronization session.

[0069] In the embodiments of this specification, through the collaborative work of the transparent mapping of the virtual network address and the automatic reconnection mechanism of the client, lossless migration of the connection session is achieved during physical node switching. It avoids the hard-coded dependency of the client configuration and ensures the determinacy of the reconnection behavior through the redirect instruction, making the client unaware of the changes in the underlying database.

[0070] In an alternative embodiment of this specification, after sending the virtual network address of the new primary database to the client, the following specific steps are further included: In the case where the reconnection request for the old data connection fails, disconnect the old data connection.

[0071] For the reconnection request of the old data connection to fail, one alternative judgment method is that the reconnection request network for the old data connection times out. Another alternative judgment method is that the reconnection request protocol for the old data connection is incompatible. Another alternative judgment method is that the resources required for the reconnection request of the old data connection are insufficient. This is not limited here.

[0072] For disconnecting the old data connection, one alternative method is to call the forced disconnection interface of the load balancing module to disconnect the old data connection. Another alternative method is to adjust the timeout parameter to trigger the automatic disconnection of the old data connection. This is not limited here.

[0073] Exemplarily, after the client (such as the roadside sensor data acquisition service) receives the virtual network address (traffic-db.city.vip) of the new primary database, it attempts to reconnect to the new primary database (IP: 192.168.1.200). If the client does not enable the REDIRECT protocol support (such as some legacy systems still using a fixed IP connection), the reconnection request for the old data connection fails. At this time, the load balancing module (SLB) detects the reconnection failure and calls the forced disconnection interface ForceDisconnect("192.168.1.100", 3306) to send a TCP RST packet to the residual connection of the old primary database to forcibly release the resources.

[0074] In the embodiments of this specification, through the coordination of active disconnection and timeout policies, it ensures the deterministic release of residual connections, prevents resource leakage caused by zombie connections, and at the same time improves the request throughput of the new primary database through rapid recovery.

[0075] In an alternative embodiment of this specification, before step 106, the following specific steps are further included: Record the data offset of the old master database; Detect 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 master database, it is determined that the data synchronization between the old standby database and the old master database is completed.

[0076] The data offset of the old master database is the position identifier of the data that has been persistently changed in the old master database, and is used to quantify the data synchronization progress between the master 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 latest sensor data write transaction.

[0077] The data offset of the old standby database is the position identifier of the data that has been persistently changed 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.

[0078] One alternative way to record the data offset of the old master database is: by executing the master database status acquisition instruction (such as the command INFO replication, and extracting the master_repl_offset field from the output), record the data offset of the old master database. Another alternative way is: through the replication protocol of the master database, record the data offset of the old master database.

[0079] One alternative way to detect the data offset of the old standby database is: by executing the standby database status acquisition instruction (such as the command INFO replication, and extracting the slave_repl_offset field from the output), detect the data offset of the old standby database. Another alternative way is: through the replication protocol of the standby database, detect the data offset of the old standby database.

[0080] Exemplarily, in the scenario of cloud database version upgrade, the high-availability module (HA) records the current LSN of the old master database as 0 / 15D38F0 through the replication protocol of the master database. Detects the current LSN of the old standby database as 0 / 15D38F0 through the replication protocol of the database. After comparing that the two are consistent, it is determined that the data synchronization is completed, and the subsequent master-standby database switching process is triggered.

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

[0082] In an alternative embodiment of this specification, after step 104, the following specific steps are further included: In the case where the data synchronization duration between the old standby database and the old master database exceeds a preset duration threshold, set the write permission of the old master database to allow writing, so that the old data connection of the old master database maintains data writing.

[0083] The data synchronization duration between the old standby database and the old master database is the duration from the moment when the write permission of the old master database stops until the data offset between the old standby database and the old master database reaches a consistent state. This duration is used to quantify the data synchronization efficiency between the master and standby databases and is an important indicator for determining abnormal timeouts during the switching process. For example, after the old master 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 (such as 1 million INSERT records), and the data synchronization duration is 12 seconds.

[0084] The preset duration threshold is the maximum allowed data synchronization time window configured in advance. If this threshold is exceeded, it is determined that the synchronization is abnormal and a rollback operation is triggered. The preset duration threshold is dynamically adjusted according to project tolerance, network latency, and data volume. The preset duration threshold is set to 30 seconds. If the synchronization times out, the write permission of the old master database is automatically restored to avoid request blocking.

[0085] One alternative way to set the write permission of the old master database to allow writing is: through a database instruction, set the write permission of the old master database to stop writing. For example, allow the old master database to write through the Redis command SLAVEOF NO ONE. Another alternative way is: call the management interface of the cloud database to modify the write permission of the old master database to allow writing. For example, call the cloud database management API to modify the instance attribute to "read-write mode". Another alternative way is: modify the write permission of the old master database to allow writing in the database configuration file, which is not limited here.

[0086] Exemplarily, in the scenario of elastic scaling of cloud database resources, the old master database (vCPU: 16 cores) triggers a switching process due to high load. The high-availability module (HA) sets the preset duration threshold to 60 seconds, but it is detected that the data synchronization duration of the old standby database reaches 65 seconds (exceeding the threshold) due to network congestion. At this time, the high-availability module calls the management interface API SetWritePermission("192.168.1.100", "ENABLE") to restore the write permission of the old master database and sends an alarm notification to the administrator: "Synchronization timeout, switching aborted".

[0087] In the embodiments of this specification, through the timeout rollback mechanism of the preset duration threshold, the write permission of the old master database is automatically restored when the data synchronization is abnormal, avoiding long-term unavailability of the service caused by standby database synchronization delay.

[0088] In an alternative embodiment of this specification, triggering the connection draining duration in step 106 includes the following specific steps: Trigger the connection draining duration, and set the write permission of the old primary database to allow writing, so that the old data connection of the old primary database can maintain data writing.

[0089] Setting the write permission of the old primary database to allow writing. One alternative way is: through database instructions, set the write permission of the old primary database to stop writing. Another alternative way is: call the management interface of the cloud database to modify the write permission of the old primary database to allow writing. Another alternative way is: modify the write permission of the old primary database to allow writing in the database configuration file, which is not limited here.

[0090] Exemplarily, the high-availability module (HA) detects that the data synchronization between the old standby database (IP: 192.168.1.200) and the old primary database (IP: 192.168.1.100) is completed (LSN is consistent), and triggers the connection draining duration instruction StartDraining(45, "192.168.1.100"). At the same time, the high-availability module calls the management interface API SetWritePermission("192.168.1.100", "ENABLE") to restore the write permission of the old primary database and make it become the new standby database role.

[0091] In the embodiment of this specification, by synchronously triggering the draining duration and the write permission restoration operation, it is ensured that the old primary database can still briefly process the remaining transactions after the switch, and at the same time, new data write conflicts are avoided.

[0092] In an alternative embodiment of this specification, step 108 includes the following specific steps: Switch the old primary database to the 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 can maintain data writing; Reconnect the old data connection to the new primary database.

[0093] The new standby database is the database standby node instance used for reading and writing data after the switch. The new standby database continuously receives data changes from the new primary database through the logical log and maintains data consistency with the primary database. For example, the old primary database (original IP: 192.168.1.100) is demoted to the new standby database and is only used to synchronize the sensor data written by the new primary database (IP: 192.168.1.200).

[0094] To switch the old primary database to the new standby database, one optional way is: through database instructions, switch the old primary database to the new standby database. Another optional way is: use the management interface of the cloud database to modify the write permission of the old primary database to stop writing. Another optional way is: modify the write permission of the old primary database to stop writing in the database configuration file. This is not limited here.

[0095] To set the write permission of the new standby database to allow writing, one optional way is: through database instructions, set the write permission of the new standby database to stop writing. Another optional way is: call the management interface of the cloud database to modify the write permission of the new standby database to allow writing. Another optional way is: modify the write permission of the new standby database to allow writing in the database configuration file. This is not limited here.

[0096] To reconnect the old data connection to the new primary database, one optional way is: through session migration technology, reconnect the old data connection to the new primary database. Another optional way is: call the application programming interface of the load balancing module to reconnect the old data connection to the new primary database. Another optional way is: utilize the automatic retry mechanism of the cloud database driver layer to reconnect the old data connection to the new primary database. This is not limited here.

[0097] Optionally, after switching the old primary database to the new standby database, the following specific steps are further included: If the switch fails, exit the primary-standby database switch.

[0098] Optionally, after setting the write permission of the new standby database to allow writing, the following specific steps are further included: If the setting fails, exit the primary-standby database switch.

[0099] Exemplarily, the high-availability module (HA) calls the cloud database management interface API PromoteToStandby("192.168.1.100") to switch the old primary database (IP: 192.168.1.100) to the new standby database, and enables its synchronous write permission through the cloud database management interface API SetReplicationPermission("192.168.1.100", "ENABLE"). At this time, the new standby database starts to synchronize real-time traffic flow data from the new primary database (IP: 192.168.1.200), but rejects direct write requests from clients.

[0100] In the embodiments of this specification, by demoting the old primary database to the new standby database and restoring its write permission, a stable data synchronization link is established between the new primary database and the new standby database, avoiding synchronization interruption caused by completely disabling writing in the old primary database. At the same time, the new standby database only processes synchronization data and does not receive client requests, thus maintaining the high availability of the dual-node architecture while ensuring data consistency.

[0101] In an alternative embodiment of this specification, after step 108, the following specific steps are further included: Clear the connection draining duration of the load balancing module.

[0102] To clear the connection draining duration of the load balancing module, one alternative way is: send a draining instruction to the load balancing module to clear the connection draining duration of the load balancing module. Another alternative way is: call the clear interface of the load balancing module to clear the connection draining duration of the load balancing module.

[0103] Exemplarily, the original processing device of the old primary database (192.168.1.100) reported the status (10,000 UPDATEs per second), and the synchronization delay of the old standby database (192.168.1.200) was 0 milliseconds. The high-availability module (HA) called the clear interface ClearDraining of the load balancing module (SLB) to terminate the draining status of the old primary database and release its computing resources for other instances. After the old primary database was demoted to a new standby database, it was automatically added to the resource pool for elastic scaling scheduling.

[0104] In the embodiments of this specification, through the linkage of clearing the draining duration and resource recovery, not only is a seamless switch achieved, but also the resource allocation efficiency of the cloud database is optimized.

[0105] In an alternative embodiment of this specification, after step 106, the following specific steps are further included: In the case of exceeding the connection draining duration, disconnect the old data connection.

[0106] To disconnect the old data connection, one alternative way is: call the forced disconnection interface of the load balancing module to disconnect the old data connection. For example, call the forced disconnection interface ForceDisconnect("192.168.1.100", 3306) of the load balancing module to disconnect all the old data connections of the old primary database. Another alternative way is: adjust the timeout parameter to trigger the automatic disconnection of the old data connection. For example, modify the tcp_keepalive_time parameter of the old primary database to 0 seconds to trigger the automatic disconnection of the old data connection, which is not limited herein.

[0107] Exemplarily, if there are still 3 unfinished report queries among 15 online analytical processing long connections, call the forced disconnection interface of the load balancing module (SLB), call the load balancing module to send TCP FIN packets to terminate these connections, and record the disconnection log.

[0108] In the embodiments of this specification, by forcibly releasing residual connection resources, it is possible to avoid uneven load on the new primary database caused by long transaction blocking, and at the same time ensure the efficient recycling of system resources, improving the overall throughput capacity of the cloud database. Combining with the dynamic control of the evacuation duration, it not only guarantees the transaction integrity during the switchover but also realizes the deterministic recycling of resources.

[0109] See Figure 2 , Figure 2 shows a flowchart of another method for switching between the primary and standby databases of a cloud database provided in an embodiment of this specification, which is applied to the load balancing module of the cloud database. The cloud database also includes a high-availability module, an old primary database, and an old standby database. The method includes the following specific steps: Step 202: Suspend the old data connection with the old primary database within the connection evacuation duration, and distribute the new data requests to the new primary database, where the high-availability module executes the steps of the above method.

[0110] One optional way to suspend the old data connection with the old primary database is that the load balancing module marks the active connections of the old primary database as the evacuation state to pause the establishment of new data connections but allow the old data connections. For example, SLB detects 200 online transaction processing connections of the old primary database (IP: 192.168.1.100) and sets their status to "DRAINING", only allowing the transactions of the unfinished old data connections to be committed and rejecting new data requests. Another optional way is to adjust the keep-alive parameter of TCP to extend the survival time of the old data connection. For example, the Keepalive time of the old primary database connection is set to 60 seconds, which is not limited here.

[0111] One optional judgment method for distributing the new data requests to the new primary database is that the load balancing module updates the virtual network address binding, remaps the virtual network address of the old primary database to the new primary database to distribute the new data requests to the new primary database. For example, SLB calls the API to modify the VIP configuration. Another optional judgment method is to remap the domain name address of the old primary database to the new primary database through the domain name system to distribute the new data requests to the new primary database. For example, update the A record of XXXX.com from the old primary database IP (192.168.1.100) to the new primary database IP (192.168.1.200), which is not limited here.

[0112] Exemplarily, the load balancing module sets 15 online analytical processing long connections of the old primary database (192.168.1.100) to "DRAINING", allows the unfinished report queries to continue to execute for 60 seconds, and rejects new queries during this period. The load balancing module binds the virtual IP (192.168.1.100) to the new primary database (192.168.1.200), and the new sensor data (such as 5000 INSERTs per second) is immediately routed to the new primary database.

[0113] In the embodiments of this specification, by setting the connection evacuation duration, a time window for processing the data connection of the old primary database is reserved to avoid the direct disconnection of the old data connection caused by forced disconnection; when promoting the old standby database to the new primary database after data synchronization is completed, the connection evacuation mechanism is triggered to keep the load balancing module hanging the old data connection, and at the same time direct the new data requests to the new primary 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; on the premise of data consistency, the suspended old data connections are smoothly migrated to the new primary database through active redirection instead of passive disconnection and reconstruction. This process, through the dynamic coordination of the evacuation duration, the shunt control of the old and new connections, and the cooperation of redirection after synchronization, completes the seamless switch of the primary and standby databases without interrupting the existing data services, eliminates the unavailable time caused by forced disconnection, realizes the synchronous guarantee of data consistency and service continuity, and further improves the availability.

[0114] The above is a schematic solution of another method for switching the primary and standby databases of a cloud database in this embodiment. It should be noted that Figure 2 the technical solution of the method for switching the primary and standby databases of the cloud database Figure 1 belongs to the same concept as the technical solution of the method for switching the primary and standby databases of the cloud database Figure 2 For the details not described in the technical solution of the method for switching the primary and standby databases of the cloud database Figure 1 the description of the technical solution of the method for switching the primary and standby databases of the cloud database can be referred to.

[0115] Regarding the above Figure 1 and Figure 2 method for switching the primary and standby databases of the cloud database, it should be noted that the seamless switching technology utilizes the connection evacuation ability of the load balancing module to suspend the old data connections of the old primary database on a virtual IP, and correct responses can be obtained, so as to realize the subsequent seamless reconnection (forwarding) of the old data connections to the new standby database after switching.

[0116] Specifically, the architecture diagram of seamless switching is as Figure 3 shown, Figure 3 which shows the architecture diagram of a single virtual network address in the method for switching the primary and standby databases of a cloud database provided by an embodiment of this specification: The server of the cloud database exposes the same access entry through the domain name system and is actually bound to the current primary database (the old primary database before switching and the new primary database after switching).

[0117] The process of switching the primary and standby databases is as follows: 1. Set the old primary database to stop writing; 2. Wait for the data synchronization between the old primary database and the old standby database to be completed; 3. Promote the old standby database to the new primary database; 4. Set the connection evacuation duration to 60 seconds; 5. Demote the old primary database to the new standby database; 6. The new standby database resumes writing and returns connection redirection; 7. After 15 seconds, disconnect the old data connection to complete the connection reset response.

[0118] Figure 3 The architecture shown has the following advantages: 1. It has a fast switching speed during high-availability switching and does not rely on domain name system switching.

[0119] 2. It can provide a unique high-availability address to avoid changing the connection address during a failure. The technical effects that can be achieved are: 3. It greatly reduces the impact of the active switching process initiated by clients such as users or operation and maintenance.

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

[0121] Corresponding to Figure 3 the architecture diagram shown, Figure 4 the timing flowchart of a primary-standby database switching method for a cloud database provided by an embodiment of this specification is shown: 1. The high-availability module pings the old standby database and checks its running status; 2. Confirm that the running status of the old standby database meets the switching conditions; 3. The high-availability module pings the old primary database; 4. Confirm that the running status of the old primary database meets the switching conditions; 5. The high-availability module sets the connection evacuation duration to 60 seconds for the load balancing module; 6. The high-availability module sets the write permission of the old primary database to stop writing; 7. The setting is successful; 8. The high-availability module waits for the data synchronization between the old standby database and the old primary database to complete; 9. The data synchronization is completed; 10. The high-availability module switches the old standby database to the new primary database; 11. The high-availability module switches the backend load balancing node to trigger the connection evacuation duration; 12. The load balancing module triggers successfully; 13. The high-availability module reversely mounts the old primary database as the new standby database; 14. The high-availability module sets the write permission of the new standby database to allow writing and returns connection redirection.

[0122] 15. Success; 16. When the high-availability module exceeds the connection drain duration, it disconnects the old data connection; 17. Success; 18. The high-availability module clears the connection drain duration of the load balancing module.

[0123] The above Figure 3 and Figure 4 give a solution for a single virtual network address. There can also be a solution with a dual virtual network address, which does not use the connection drain duration technology for forwarding. Figure 5 FIG. shows a schematic diagram of the architecture of a dual virtual network address in a primary and standby database switching method for a cloud database provided by an embodiment of this specification: The server of the cloud database exposes two access entrances through the domain name system, which are respectively bound to the current primary database and standby database (the old primary database before switching and the new primary database after switching).

[0124] The process of primary and standby database switching is as follows: 1. Set the old primary database to stop writing; 2. Wait for the data synchronization between the old primary database and the old standby database to complete; 3. Promote the old standby database to be the new primary database; 4. Update the domain name; 5. Demote the old primary database to be the new standby database; 6. The new standby database resumes writing and returns connection redirection.

[0125] Compared with the solution of a single virtual network address, the dual virtual network address performs high-availability switching by switching the domain name. Due to the cache of the domain name system and the switching perception delay at the minute level, in the case of a failure scenario, it will bring additional unavailable time exceeding the service level agreement (SLA).

[0126] Corresponding to the above method embodiment, this specification also provides a cloud database embodiment. Figure 6 FIG. shows a schematic diagram of the structure of a cloud database provided by an embodiment of this specification. As Figure 6 shown, the cloud database 600 includes a high-availability module 610, a load balancing module 620, an old primary database 630, and an old standby database 640; The high-availability module 610 is used to set the connection drain duration of the load balancing module when the running states of the old primary database 630 and the old standby database 640 meet the switching conditions; set the writing permission of the old primary database 630 to stop writing; when the data synchronization between the old standby database 640 and the old primary database 630 is completed, switch the old standby database 640 to be the new primary database and trigger the connection drain duration; The load balancing module 620 is used to suspend the old data connection with the old primary database 630 within the connection drain duration and distribute the new data requests to the new primary database; The high-availability module 610 is used to reconnect the old data connection to the new primary database.

[0127] Optionally, the high-availability module 610 is specifically used to send the virtual network address of the new primary database to the client, so that the client sends a reconnection request for the old data connection to the new primary database based on the virtual network address, and completes the reconnection of the old data connection.

[0128] Optionally, the high-availability module 610 is also used to disconnect the old data connection in case the reconnection request for the old data connection fails.

[0129] Optionally, the high-availability module 610 is also used to record the data offset of the old primary database; detect the data offset of the old standby database; and determine that the data synchronization between the old standby database and the old primary database is completed when the data offsets of the old standby database and the old primary database are consistent.

[0130] Optionally, the high-availability module 610 is also used to set the write permission of the old primary database to allow writing when the data synchronization duration between the old standby database and the old primary database exceeds the preset duration threshold, so that the old data connection of the old primary database maintains data writing.

[0131] Optionally, the high-availability module 610 is specifically used to trigger the connection drain duration and set the write permission of the old primary database to allow writing, so that the old data connection of the old primary database maintains data writing.

[0132] Optionally, the high-availability module 610 is specifically used to switch the old primary database to the new standby database, 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.

[0133] Optionally, the high-availability module 610 is also used to clear the connection drain duration of the load balancing module.

[0134] Optionally, the high-availability module 610 is also used to disconnect the old data connection when the connection drain duration is exceeded.

[0135] In the embodiments of this specification, the high-availability module sets the connection evacuation duration to reserve a processing time window for the old primary database data connection, avoiding the direct disconnection of the old data connection caused by forced disconnection; when the high-availability module promotes the old standby database to a new primary database after data synchronization is completed, the load balancing module triggers the connection evacuation mechanism to keep the old data connection of the load balancing module suspended, and at the same time directs the new data requests to the new primary database, ensuring both the real-time response of new requests during the switchover and 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 primary database through active redirection instead of passive disconnection and reconstruction. This process, through the dynamic coordination of the evacuation duration, the shunt control of the old and new connections, and the cooperation of redirection after synchronization, completes the seamless switchover of the primary and standby databases without interrupting the existing data services, eliminates the unavailable time caused by forced disconnection, realizes the synchronous guarantee of data consistency and service continuity, and further improves the availability of the cloud database.

[0136] The above is a schematic solution of a cloud database in this embodiment. It should be noted that the technical solution of this cloud database and the technical solution of the primary and standby database switchover method of the above cloud database belong to the same concept. For the details not described in the technical solution of this cloud database, reference can be made to the description of the technical solution of the primary and standby database switchover method of the above cloud database.

[0137] Figure 7 The structural block diagram of a computing device provided by an embodiment of this specification is shown. The 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 through a bus 730, and a database 750 is used to store data.

[0138] The computing device 700 also includes an access device 740, which enables the computing device 700 to communicate via one or more networks 760. Examples of such networks include the Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or a combination of communication networks such as the Internet. The 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, a Near Field Communication (NFC) interface.

[0139] In one embodiment of the present specification, the above components of the computing device 700 and Figure 7 other components not shown therein may also be connected to each other, for example, via a bus. It should be understood that Figure 7 the block diagram of the computing device shown is for illustrative purposes only and is not a limitation on the scope of the present specification. Those skilled in the art can add or replace other components as needed.

[0140] The 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, a personal digital assistant, a laptop computer, a notebook computer, a netbook, 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 a Personal Computer (PC). The computing device 700 can also be a mobile or stationary server.

[0141] Wherein, the processor 720 is configured to execute the following computer program / instructions, and when the computer program / 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.

[0142] The above is a schematic solution of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the primary and standby database switching method of the above cloud database belong to the same concept. For the details not described in detail in the technical solution of the computing device, reference can be made to the description of the technical solution of the primary and standby database switching method of the above cloud database.

[0143] An embodiment of this specification also provides a computer-readable storage medium, which stores computer programs / instructions. When the computer programs / instructions are executed by a processor, the steps of the above primary and standby database switching method of the cloud database are implemented.

[0144] The above is a schematic solution of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the primary and standby database switching method of the above cloud database belong to the same concept. For the details not described in detail in the technical solution of the storage medium, reference can be made to the description of the technical solution of the primary and standby database switching method of the above cloud database.

[0145] An embodiment of this specification also provides a computer program product, including computer programs / instructions. When the computer programs / instructions are executed by a processor, the steps of the above primary and standby database switching method of the cloud database are implemented.

[0146] The above is a schematic solution of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the primary and standby database switching method of the above cloud database belong to the same concept. For the details not described in detail in the technical solution of the computer program product, reference can be made to the description of the technical solution of the primary and standby database switching method of the above cloud database.

[0147] The above describes specific embodiments of this specification. 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 a different order than in the embodiments and still achieve the desired result. Additionally, the processes depicted in the figures do not necessarily require the particular order or sequential order shown to achieve the desired result. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0148] The computer instructions include computer program code, which can be in the form of source code, object code, executable files, or some intermediate forms, etc. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, external hard drives, magnetic disks, optical discs, computer memories, read-only memories (ROM), random access memories (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately increased or decreased according to the requirements of patent practice. For example, in some regions, according to patent practice, the computer-readable medium does not include electrical carrier signals and telecommunication signals.

[0149] It should be noted that for the foregoing method embodiments, for the sake of simplicity of description, they are all expressed as a series of action combinations. However, those skilled in the art should know that the embodiments of this specification are not limited by the described action sequence, because according to the embodiments of this specification, some steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential for the embodiments of this specification.

[0150] In the above embodiments, the descriptions of each embodiment have their own emphases. For the parts not detailed in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0151] The preferred embodiments of this specification disclosed above are only used to help explain this specification. The alternative embodiments do not elaborate on all details and do not limit the invention to the specific embodiments described. Obviously, many modifications and changes can be made according to the content of the embodiments of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the embodiments of this specification, so that those skilled in the art can understand and utilize this specification well. This specification is only limited by the claims and their full scope and equivalents.

Claims

1. A method for switching between a primary database and a standby database of a cloud database, which is applied to the high-availability module of the cloud database, wherein, The cloud database further includes a load balancing module, an old primary database, and an old standby database; the method includes: When the operating states of the old primary database and the old standby database meet the switching conditions, set the connection draining duration of the load balancing module; Set the write permission of the old primary database to stop writing; When the data synchronization between the old standby database and the old primary database is completed, switch the old standby database to the new primary database and trigger the connection draining duration, so that the load balancing module suspends the old data connection with the old primary database within the connection draining duration and distributes the new data requests to the new primary database; Reconnect the old data connection to the new primary database.

2. The method according to claim 1, reconnecting the old data connection to the new primary database includes: Send the virtual network address of the new primary database to the client, so that the client sends a reconnect request for the old data connection to the new primary database based on the virtual network address to complete the reconnection of the old data connection.

3. The method according to claim 2, after sending the virtual network address of the new primary database to the client, further includes: When the reconnect request for the old data connection fails, disconnect the old data connection.

4. The method according to any one of claims 1-3, before switching the old standby database to the new primary database and triggering the connection draining duration when the data synchronization between the old standby database and the old primary database is completed, further includes: Record the data offset of the old primary database; Detect 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, determine 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-3, after setting the write permission of the old primary database to stop writing, further includes: When the data synchronization duration between the old standby database and the old primary database exceeds a preset duration threshold, set the write permission of the old primary database to allow writing, so that the old data connection of the old primary database maintains data writing.

6. The method according to any one of claims 1-3, triggering the connection draining duration includes: Trigger the connection draining duration and set the write permission of the old primary database to allow writing, so that the old data connection of the old primary database maintains data writing.

7. The method according to any one of claims 1-3, reconnecting the old data connection to the new primary database includes: Switch the old primary database to the 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; Reconnect the old data connection to the new primary database.

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

9. The method according to any one of claims 1-3, after triggering the connection draining duration, further includes: When the connection draining duration is exceeded, disconnect the old data connection.

10. A method for switching between a primary database and a standby database of a cloud database, which is applied to a load balancing module of the cloud database, where, The cloud database further includes a high availability module, an old master database, and an old standby database; the method includes: During the connection evacuation duration, suspend the old data connection with the old master database, and distribute the new data requests to the new master database, where the high availability module executes the steps of the method according to any one of claims 1 to 9.

11. A cloud database, including a high availability module, a load balancing module, an old master database, and an old standby database; The high-availability module is used to set the connection drainage duration of the load balancing module when the operating states of the old master database and the old standby database meet the switching conditions; Set 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, switch the old standby database to the new master database, and trigger the connection evacuation duration; The load balancing module is configured to, during the connection evacuation duration, suspend the old data connection with the old master database, and distribute the new data requests to the new master database; The high availability module is configured to reconnect the old data connection to the new master database.

12. A computing device, including: A memory and a processor; 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 method according to any one of claims 1 to 10 are implemented.

13. A computer-readable storage medium, which stores computer programs / instructions. When the computer programs / instructions are executed by a processor, the steps of the method according to any one of claims 1 to 10 are implemented.

14. A computer program product, including computer programs / instructions. When the computer programs / instructions are executed by a processor, the steps of the method according to any one of claims 1 to 10 are implemented.

Images