A user zero-awareness database master-slave switching method and device

Abstract

The embodiment of the application provides a user zero-awareness database master-slave switching method and device, the method comprises the following steps: when the database driver detects that the master database and the slave database are switched, it is judged whether the master database and the slave database have completed the master-slave switching and realized the session synchronization; if yes, the database driver sends the session request cached during the master-slave switching as the slave database of the current master database, so that the slave database processes the session request; the database driver receives the response returned by the slave database according to the session request and sends the response to the client to which the session request belongs. The above method solves the problem that the client connection is disconnected, the request is lost and the experience is poor in the prior art when the master-slave switching is performed.

Description

Technical Field

[0001] This invention relates to the field of database technology, and in particular to a database master-slave switching method, a database master-slave switching device, and an electronic device that allows users to switch databases without any awareness of the process. Background Technology

[0002] With the widespread use of databases in modern applications, the requirements for the availability and fault tolerance of database systems are becoming increasingly stringent. Among various database architectures, the master-slave database architecture is widely used to provide high data availability and disaster recovery capabilities. In a master-slave database, the master database is responsible for receiving and processing write operations, while the slave database provides read services by replicating data from the master database. Simultaneously, it enables failover and takeover of business operations should the master database fail.

[0003] While master-slave databases can provide overall system availability, a master-slave database architecture requires manual or automatic switching of client connections to the new master node even after the lower-level database completes the master-slave switch, should the master fail or be switched for maintenance. This master-slave switch process is usually perceptible to the application and clients, leading to connection drops and lost requests, resulting in a very poor user experience for the large number of clients at the upper level. Therefore, it is necessary to provide a solution for seamless master-slave switchover to improve system reliability and ease of switching. Summary of the Invention

[0004] This invention provides a database master-slave switching method and apparatus that allows users to switch without any awareness of the problem, thereby solving the issues of client connection loss, request loss, and poor user experience caused by master-slave switching in the prior art.

[0005] This invention discloses a database master-slave switching method with zero user awareness, comprising:

[0006] When the database driver detects a switch between the master and slave databases, it determines whether the master and slave databases have completed the master-slave switch and achieved session synchronization.

[0007] If so, the database driver will send the session requests cached during the master-slave switchover to the slave database, which is now the master database, so that the slave database can handle the session requests;

[0008] The database driver receives the response returned from the database based on the session request and sends the response to the client to which the session request belongs.

[0009] Optionally, before the database driver detects a switchover between the master and slave databases, the method further includes:

[0010] The database driver connects to the master database and slave databases based on the multi-data source configuration information, and determines whether the master database has switched through heartbeat detection and the status of the master database and slave databases;

[0011] If no switch occurs, the client's session request is sent to the master database;

[0012] If the database driver does not receive a response to the session request returned by the master database, it will determine the status of the master database and the slave database to determine whether a master-slave database switchover has occurred.

[0013] If so, then cache the client's session requests during the switchover period between the primary and secondary databases.

[0014] Optionally, determine whether the master and slave databases have completed master-slave failover and achieved session synchronization, including:

[0015] The database driver determines whether the master-slave switch is complete by checking the heartbeat and the status of the master and slave databases. If not, it waits, and if the cached session request times out during the waiting period, it sends a failure response to the client of the timed-out session request.

[0016] The connection list and session information in the master database are synchronized to the slave database so that the slave database can parse and load them, and the session continuity is achieved when a session request is received from the database driver.

[0017] Optionally, the database driver sends the session requests cached during the master-slave switchover to the slave database, which is now the master database, including:

[0018] The database driver retrieves all session requests cached by the current database driver from memory and sends the session requests to the slave database that is currently the master database.

[0019] This invention also provides a database master-slave switching method that allows users to switch without any awareness of the process, including:

[0020] When the master database receives a connection request from the data driver, it performs connection verification. If the verification passes, it connects to the data driver and synchronizes the connection information, context information, and log information to the slave database.

[0021] If the master database receives a response from the slave database indicating successful synchronization, it sends the information from both the master and slave databases to the data driver so that the data driver is stored in memory.

[0022] The master database receives the session request from the client sent by the data driver. After processing, the master database returns a response to the session request to the data driver, so that the data driver responds to the client that sent the session request.

[0023] Optionally, it also includes:

[0024] During master-slave failover, the hook function in the master database captures failure events and writes the session information in the master database to the specified WAL file, distinguishing it from the log WAL file. Then, the WAL file containing the session information and the log WAL file are sent to the slave database via streaming replication.

[0025] Optionally, it also includes:

[0026] After receiving the WAL file containing the logs from the new master database, the slave database obtains the connection list, reads the connection events, loads the session information into memory, and waits for the data driver to send a session request to ensure session continuity.

[0027] This invention also discloses a database master-slave switching system that allows users to switch without any awareness of the process, comprising:

[0028] The main database, slave databases, database drivers, and multiple clients;

[0029] When the database driver detects a switch between the master and slave databases, it determines whether the master and slave databases have completed the master-slave switch and achieved session synchronization.

[0030] If so, the database driver will send the session requests cached during the master-slave switchover to the slave database, which is now the master database, so that the slave database can handle the session requests;

[0031] The database driver receives the response returned from the database based on the session request and sends the response to the client to which the session request belongs.

[0032] This invention also discloses a database master-slave switching device that allows users to switch without noticing, comprising:

[0033] The detection unit is used to determine whether the master database and slave database have completed the master-slave switch and achieved session synchronization when a switch occurs between the master database and the slave database.

[0034] The switching unit is used to send the session requests cached during the master-slave switch to the slave database, which is now the master database, when the detection unit determines that the master-slave switch is complete, so that the slave database can process the session requests.

[0035] The receiving unit is used to receive the response returned from the database according to the session request, and send the response to the client to which the session request belongs.

[0036] This invention also discloses an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0037] The memory is used to store computer programs;

[0038] When the processor executes a program stored in the memory, it implements the method described in the embodiments of the present invention.

[0039] This invention also discloses one or more computer-readable media storing instructions that, when executed by one or more processors, cause the processors to perform the methods described in this invention.

[0040] The embodiments of the present invention have the following advantages:

[0041] The user-aware database master-slave switching method in this embodiment of the invention provides a safe and fast way to handle connection interruption and request loss during the master-slave switching process. Specifically, the data driver caches the client's session requests during the master-slave switching, and then sends the cached session requests to the new master database after the master-slave database switch is completed and the session information is synchronized, thereby improving the availability and stability of the entire master-slave switching system.

[0042] By synchronizing connection events and session information between the master and slave databases during master-slave failover, the data driver sends session requests to the new master database, ensuring session continuity and greatly improving the user experience in master-slave database failover scenarios. Users do not need to pay attention to the details of master-slave failover and can continuously access and operate the database, ultimately improving the performance and reliability of the application.

[0043] The method of this invention enables clients to experience a seamless master-slave switchover process, providing an innovative solution for database architecture in modern applications. Attached Figure Description

[0044] Figure 1 This is a structural block diagram of a database master-slave switching system with zero user awareness provided in an embodiment of the present invention;

[0045] Figure 2 This is a flowchart of the steps of a database master-slave switching method with zero user awareness provided in an embodiment of the present invention;

[0046] Figure 3 This is a flowchart of the steps of a database master-slave switching method with zero user awareness provided in an embodiment of the present invention;

[0047] Figure 4 This is a flowchart of the steps of a database master-slave switching method with zero user awareness provided in an embodiment of the present invention;

[0048] Figure 5 This is a flowchart of the steps of a database master-slave switching method with zero user awareness provided in an embodiment of the present invention;

[0049] Figure 6 This is a structural block diagram of a database master-slave switching device that provides zero-perception for users, as provided in an embodiment of the present invention.

[0050] Figure 7 This is a block diagram of an electronic device provided in an embodiment of the present invention;

[0051] Figure 8 This is a schematic diagram of a computer-readable medium provided in an embodiment of the present invention. Detailed Implementation

[0052] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0053] To address the issues of poor user experience and low reliability in existing technologies, this invention provides a PostgreSQL master-slave switching method that eliminates user awareness during the switching process. By using a customized database driver and WAL log-based replication capabilities, the client experiences a seamless master-slave switchover.

[0054] PostgreSQL is a feature-rich, free software object-relational database management system. It supports most of the SQL standard and offers many other modern features, such as complex queries, foreign keys, triggers, views, transaction integrity, and multi-version concurrency control. Similarly, PostgreSQL can be extended in many ways, such as by adding new data types, functions, operators, aggregate functions, indexing methods, and procedural languages. Furthermore, due to its flexible license, anyone can use, modify, and distribute PostgreSQL for any purpose.

[0055] The user-unnoticed database master-slave switching system of this invention mainly comprises two parts:

[0056] (1) Add a database driver that can perform customized processing, record all node IP information of the master and slave databases, monitor in real time whether the master and slave databases have switched over, and when a switch occurs, perceive the master-slave relationship, cache the SQL records during the switch, and send the request to the new master database to achieve automatic retransmission of database traffic.

[0057] (2) Both the master and slave databases have the ability to replicate WAL log files (i.e., WAL files), synchronously copying the connection information and session information of the master database to the slave database. The slave database parses the WAL log file and applies the connection information into memory, realizing automatic synchronization of connection information between the master and slave databases without manual intervention or reconnection.

[0058] The seamless master-slave failover system in this invention provides a secure and efficient way to handle connection interruptions and request loss during the master-slave failover process, thereby improving system availability and stability. Simultaneously, it significantly enhances the user experience in master-slave database failover scenarios, allowing users to continuously access and operate the database without needing to concern themselves with the details of the failover, ultimately improving application performance and reliability.

[0059] In this embodiment, "master database," "master device," and "slave database" all refer to the master database, while "slave database," "slave device," and "standby database" all refer to the slave database. Master-slave failover in this embodiment refers to switching from the current master database to the slave database.

[0060] WAL (Write Ahead Log) is a common technique in database systems used to ensure the atomicity and durability of data operations.

[0061] A session refers to a set of interactive communication activities, typically occurring between a client and a server. It can be used to store user authentication information, user session data, and other relevant information, thereby providing a persistent connection.

[0062] RTO (Recovery Time Objective): Data recovery time refers to the time period between the moment an IT system crashes, causing business interruption, and the moment the IT system is restored to support the operation of various departments and business resumes.

[0063] Reference Figure 1 The diagram illustrates a user-aware database master-slave switching system provided in an embodiment of the present invention, which may specifically include: multiple clients, a database driver, a master database, and a slave database.

[0064] In this embodiment, each client connects to the database driver and sends a session request to the database driver, which then forwards the session request to the current master database. Simultaneously, data synchronization is achieved between the master and slave databases unless a master-slave switch occurs.

[0065] Specifically, the database driver can be customized by the operator before initialization, configuring the data source configuration information of the master and slave databases, such as port information and specific connection information, so that the database driver can establish connection information with the master and slave databases.

[0066] The data driver in this embodiment is also used to connect to the client, receive the client's session requests and forward them to the master database, thereby recording the master-slave database relationship and all node IP information. In this embodiment, the database driver implements and verifies connections with the master and slave databases, while the client connects to the database driver, which then sends the client's session requests to the current master database.

[0067] By customizing the database driver, it supports master-slave multi-data source configuration and can record master-slave databases and all node IP information.

[0068] When the database driver connects to the master database, it automatically obtains the node IP information of the master and slave databases and stores it in the database driver's memory for connection during database switchover.

[0069] The database driver receives session requests sent by the client and forwards them to the master database. When a failure of the master database is detected, it determines whether the master and slave databases have completed the master-slave switchover and achieved session synchronization.

[0070] If so, the database driver will send the session requests cached during the master-slave switch to the slave database, which is now the master database, so that the slave database can handle the session requests.

[0071] The database driver receives the response returned from the database based on the session request and sends the response to the client to which the session request belongs.

[0072] The data driver implements master database anomaly detection and failover through heartbeat detection and anomaly assessment. The data driver periodically sends heartbeat signals to the master database to detect its status. If the data driver does not receive a heartbeat response from the master database, or receives a specific return during master-slave failover, it determines that the master database has encountered an anomaly.

[0073] The data driver periodically sends heartbeat signals to the master database. These heartbeat signals are essentially special messages or requests designed to verify that the master database is functioning correctly. The frequency of heartbeat signal transmission is a carefully designed parameter that strikes a balance between timely detection of the master database's status and avoiding excessive consumption of network resources. For example, it might be configured to send a heartbeat signal every few seconds (e.g., every 5 seconds).

[0074] After sending a heartbeat signal, the data driver waits for a response from the master database. It sets a reasonable timeout period, and if no heartbeat response is received from the master database within this timeout period, it initiates an exception handling process. This timeout period needs to take into account factors such as network latency and the master database's processing capacity, and is generally set to several times the heartbeat signal sending cycle (e.g., 3 times the heartbeat cycle, i.e., 15 seconds).

[0075] When the master database receives a heartbeat signal, it responds accordingly based on its operational status. Normally, the master database returns a heartbeat response indicating normal operation. This response also contains necessary information, such as the master database's current load (e.g., the number of transactions currently being processed) and the master database's timestamp. This information can be used by the data-driven program for further analysis and monitoring.

[0076] The data driver automatically switches to a new master node based on the saved master-slave connection information and reissues the SQL requests. This ensures that clients can seamlessly switch to an available master node when the master fails.

[0077] After a master-slave switchover occurs, the data driver determines that a switchover has occurred, caches the requests, and resends them to the new master database once the switchover is complete. Typically, a master-slave switchover takes some time. The data driver needs to determine that a switchover has occurred, cache the SQL requests in the time remaining before the switchover is complete, and then resend the previously incomplete SQL requests to the new master node once the switchover is deemed complete.

[0078] Both the master and slave databases implement connection information synchronization.

[0079] By setting hook functions in both the master and slave databases, the connection information from the master database can be synchronously copied to the slave database. This enables the replication of WAL log files, synchronously copying the connection information from the master database to the slave database.

[0080] The hook function writes the master database's connection information to the WAL log file and synchronously replicates it to the slave database. The slave database then reads this information and loads it synchronously during session loading. This ensures that the slave database has the same connection information as the master database, so that clients can connect to the correct master node during master-slave failover.

[0081] Information synchronization between the master and slave databases can be understood as data replication technology, used to improve system availability and reliability, and ensure data consistency. In this embodiment, session information synchronization mainly maintains the consistency of session information, so that the client is unaware of session termination and the need to re-establish a connection.

[0082] A hook function is a function that is called when a specific event or action occurs. It is a callback mechanism that allows programmers to insert custom code snippets into the execution flow of a program.

[0083] The hook functions mentioned above can monitor events and trigger the synchronization of data such as log files and session information after an event occurs. Once the replication is complete, the slave database (as the new master database) can notify the data driver program that parsing and preparation are complete.

[0084] The aforementioned master-slave switching system enables clients to experience a seamless switching process, resolving issues such as client connection interruption, request loss, and degraded user experience in traditional master-slave switching, thereby improving the availability of the database system and the user experience.

[0085] Figure 1 The database driver shown supports configuring multiple data sources (clients), master database status detection, and determining whether a master-slave switch has occurred and whether the switch is complete (i.e., the session request has been synchronized). It also supports SQL caching and retries. When a master-slave switch occurs, it waits for the switch to complete and resends the SQL to the new master database to retry the business.

[0086] The database status detection in this embodiment may include: checking the recent error log to see if any serious errors have occurred, or checking whether the main database service is running, or monitoring the usage of resources such as CPU, memory, and disk to determine whether thresholds have been reached, whether the database is in a locked state, and whether the read and write throughput is normal.

[0087] Corresponding database status checks may include: checking whether logs are being recorded correctly, whether database backups were completed successfully, and whether recovery is possible.

[0088] In practical applications, database status can be checked using the database's built-in command-line tools (such as psql for PostgreSQL) to obtain status information. Alternatively, professional database monitoring tools (such as Prometheus+Grafana, Zabbix, Nagios, etc.) can be used to monitor various metrics in real time, or custom scripts can be used to automate the checks.

[0089] PostgreSQL's psql provides a rich set of commands for querying database status information. These commands can help administrators view database version, connection status, system table information, database and table sizes, and more. For example, the \dt command can be used to view all tables in the current database, the \l command to list all databases, and the pg_stat_activity system view to view active sessions in the current database.

[0090] Prometheus is an open-source system monitoring and alerting toolkit. Grafana is a popular open-source visualization platform. Integrating Prometheus with Grafana allows you to display the database metrics collected by Prometheus in intuitive charts.

[0091] Zabbix is ​​a powerful enterprise-grade distributed monitoring system. For database monitoring, the first step is to configure monitoring items for the database on the Zabbix server. Database status information can be obtained through the Zabbix Agent (installed on the database server) or by using the database's native protocol (such as the libpq library for PostgreSQL).

[0092] Nagios is a popular open-source network and system monitoring tool. For database status monitoring, it primarily uses plugins and inspection scripts. For example, there are dedicated Nagios plugins for PostgreSQL database monitoring, which can check various database statuses, such as whether the database is running and whether database connections are normal.

[0093] Figure 1 The master database described herein writes session information to the WAL log file for persistent storage when the data driver establishes a connection. This information is then sent to the slave database via master-slave synchronous replication. Simultaneously, when a session changes, such as during an interruption or reconnection, the information is written to the WAL log file and synchronously sent to the slave database.

[0094] Figure 1 The slave database described herein can parse session information and load it into memory after receiving the WAL log file sent by the master database. This allows it to quickly execute SQL requests when a master-slave switch occurs, without having to re-establish a client connection.

[0095] like Figures 2 to 4 As shown, Figures 2 to 4 Each of these figures illustrates a flowchart of a database master-slave switching method that allows users to switch without being aware of the process, provided in an embodiment of the present invention.

[0096] Part 1: Database connection establishment process, such as Figure 3 As shown:

[0097] 101: Hook functions for the primary database, used to capture events of connection establishment or disconnection when the primary database connection changes.

[0098] 102: Capture database connection establishment events.

[0099] 103: Parse the specific client information for the connection establishment, including the client IP address, username, connection time, session validity period, etc.

[0100] 104: Writes session information in JSON format to a specified WAL file. To distinguish it from the native WAL log, it is written to a different file, such as WAL_SESSION.

[0101] 105: Send WAL log files to the slave database via streaming replication.

[0102] The slave database is responsible for receiving, parsing, and loading the session information synchronized from the master database. The specific process is as follows: Figure 4 As shown.

[0103] 201: Receives WAL log files sent by the master database from the database.

[0104] 202: Parse the WAL log file from the database to obtain a list of connection information and read the connection events, such as new session, session expiration, and session termination.

[0105] 203: The database application reads session information from the WAL log file into memory, ensuring session continuity. It can directly receive client SQL without having to re-establish a connection.

[0106] Part Two: Master-Slave Switchover Process

[0107] If an exception occurs in the SQL query initiated by the client, the data driver performs fault diagnosis and switching, so that the client is unaware of the underlying database switch. Figure 5 As shown.

[0108] 301: After receiving a session request, the data driver sends the session request to the configured primary database based on the configured multiple data sources (i.e., database information).

[0109] 302: The data driver determines the database status based on the database response. If it fails normally, it terminates directly. If there is no response or a 'failover' error is returned before a timeout, the automatic failover process begins.

[0110] 303: The data driver determines the status of the master database and whether a master-slave switch has occurred through heartbeat detection and master-slave status query interfaces.

[0111] 304: The automatic failover process has begun. The data driver caches subsequent SQL requests in an ordered queue, preparing to retry with the new master database.

[0112] 305: The data driver determines whether the new master database is ready to accept new connections by using heartbeat detection and master-slave status query interfaces. If not, it enters a loop and waits until a timeout returns a failure to the client, or the switchover is complete, at which point the SQL is re-initiated.

[0113] 306: The data driver will redeploy cached SQL requests during failover to the new primary database.

[0114] When the database driver determines that the primary database is failing, it caches the received client session requests and sends the cached session requests to the secondary database that is currently the primary database.

[0115] That is, the database driver receives session requests from all clients and sends the session requests to the current master database for processing.

[0116] The method in this embodiment parses and persists the connection information of the master database to the WAL log. Utilizing the master-slave synchronization capability of the WAL log, the connection information is sent to the slave database and then re-parsed and applied to the slave database, thereby achieving connection information synchronization capability.

[0117] In this embodiment, the data driver program automatically identifies fault switching, automatically caches SQL requests, and automatically determines fault recovery and resends requests in a fault switching scenario. This enables automatic switching of the database at the driver layer without requiring the user to manually establish a new database connection or resend SQL requests, ultimately achieving seamless fault switching for the user.

[0118] In one specific implementation, the user-aware database master-slave switching method of this embodiment includes:

[0119] When the database driver detects a switch between the master and slave databases, it determines whether the master and slave databases have completed the master-slave switch and achieved session synchronization.

[0120] If so, the database driver will send the session requests cached during the master-slave switchover to the slave database, which is now the master database, so that the slave database can handle the session requests;

[0121] The database driver receives the response returned from the database based on the session request and sends the response to the client to which the session request belongs.

[0122] Understandably, the data driver can detect a failure in the primary database or a master-slave switch in the following two ways:

[0123] The first method is: the database driver obtains information about the master database and the slave database, and determines whether the master database has failed and initiates a master-slave switch by checking the heartbeat and the status of the master database and the slave database;

[0124] The second method is: the database driver receives session requests from all clients and sends the session requests to the current master database for processing;

[0125] If the database driver does not receive a response to the session request from the current master database within a specified time, it determines that the current master database has failed and then determines whether a master-slave switchover has occurred by detecting the status of the master database and the slave database.

[0126] The database driver in this embodiment can cache client session information in memory during master-slave failover.

[0127] In this embodiment, after the master-slave switch is completed and the session is synchronized, the database driver sends the cached session requests from memory to the slave database that is currently the master database.

[0128] In the second specific implementation, the user-aware database master-slave switching method of this embodiment includes:

[0129] When the master database receives a connection request from the data driver, it performs connection verification. If the verification passes, it connects to the data driver and synchronizes the connection information, context information, and log information to the slave database.

[0130] If the master database receives a response from the slave database indicating successful synchronization, it sends the information from both the master and slave databases to the data driver so that the data driver is stored in memory.

[0131] The master database receives the session request from the client sent by the data driver. After processing, the master database returns a response to the session request to the data driver, so that the data driver responds to the client that sent the session request.

[0132] For example, when a failure occurs in the primary database, the hook function in the primary database captures the failure event, writes the session information in the primary database to the specified WAL file, distinguishes it from the WAL file for logging, and sends the WAL file for recording session information and the WAL file for recording log to the secondary database through streaming replication.

[0133] At this point, the slave database, acting as the new master database, receives the WAL file, parses it, obtains the connection list, reads the connection events, loads the session information into memory, and waits for the data driver to send a session request, thus ensuring session continuity.

[0134] This embodiment utilizes the WAL log synchronization capability of the database. Through customized development, it parses and persists the connection information of the master database to the WAL log. Using the master-slave synchronization capability of the WAL log, the connection information is sent to the slave database and re-parsed and applied to the slave database, thus realizing the connection information synchronization capability.

[0135] In addition, by developing a customized database driver, we can automatically identify failover scenarios, automatically cache SQL requests, automatically determine fault recovery, and resend requests. This enables automatic database failover at the driver layer, eliminating the need for users to manually establish new database connections or resend SQL requests, ultimately achieving seamless failover for users.

[0136] The method in this embodiment enables clients to experience a seamless master-slave switchover process, providing an innovative solution for database architecture in modern applications.

[0137] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0138] Reference Figure 6 The diagram illustrates a structural block diagram of a user-aware database master-slave switching device provided in an embodiment of the present invention, which may specifically include the following modules:

[0139] The detection unit is used to determine whether the master and slave databases have completed the master-slave switch and achieved session synchronization when a switch occurs between the master and slave databases. Here, session synchronization refers to synchronizing the connection list and session information in the master database to the slave database so that the slave database can parse and load it, and achieve session continuity when a session request is received from the database driver.

[0140] The switching unit is used to send the session requests cached during the master-slave switch to the slave database, which is now the master database, when the detection unit determines that the master-slave switch is complete, so that the slave database can process the session requests.

[0141] The receiving unit is used to receive the response returned from the database according to the session request, and send the response to the client to which the session request belongs.

[0142] For example, the detection unit can be specifically used to connect to the master database and slave database based on the configuration information of multiple data sources, and determine whether the master database has switched over by detecting heartbeats and the status of the master database and slave database.

[0143] The switching unit is specifically used to retrieve all session requests cached by the current database driver from memory and send the session requests to the slave database that is currently the master database.

[0144] The device in this embodiment is a newly added device in the master-slave switching system. It caches session requests when a master-slave switch is detected, and then sends the cached session requests to the new master database when the master-slave switch is completed and the session information is synchronized, thereby ensuring the continuity of the session.

[0145] At the same time, it greatly improves the user experience in master-slave database failover scenarios, allowing users to continuously access and operate the database without having to worry about the details of the master-slave switchover, ultimately improving the performance and reliability of the application.

[0146] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0147] In addition, embodiments of the present invention also provide an electronic device, such as... Figure 7 As shown, it includes a processor 1301, a communication interface 1302, a memory 1303, and a communication bus 1304. The processor 1301, the communication interface 1302, and the memory 1303 communicate with each other through the communication bus 1304.

[0148] Memory 1303 is used to store computer programs;

[0149] When processor 1301 executes a program stored in memory 1303, it performs the following steps:

[0150] When the database driver detects a switch between the master and slave databases, it determines whether the master and slave databases have completed the master-slave switch and achieved session synchronization.

[0151] If so, the database driver will send the session requests cached during the master-slave switchover to the slave database, which is now the master database, so that the slave database can handle the session requests;

[0152] The database driver receives the response returned from the database based on the session request and sends the response to the client to which the session request belongs.

[0153] Alternatively, perform the following steps:

[0154] When the master database receives a connection request from the data driver, it performs connection verification. If the verification passes, it connects to the data driver and synchronizes the connection information, context information, and log information to the slave database.

[0155] If the master database receives a response from the slave database indicating successful synchronization, it sends the information from both the master and slave databases to the data driver so that the data driver is stored in memory.

[0156] The master database receives the session request from the client sent by the data driver. After processing, the master database returns a response to the session request to the data driver, so that the data driver responds to the client that sent the session request.

[0157] The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0158] The communication interface is used for communication between the aforementioned terminal and other devices.

[0159] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0160] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0161] like Figure 8 As shown, in another embodiment of the present invention, a computer-readable storage medium 1401 is also provided, which stores instructions that, when run on a computer, cause the computer to execute the user-unobtrusive database master-slave switching method described in the above embodiments.

[0162] In another embodiment of the present invention, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute the user-unobtrusive database master-slave switching method described in the above embodiments.

[0163] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0164] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0165] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0166] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention are included within the scope of protection of the present invention.

Claims

1. A database master-slave switching method with zero user awareness, characterized in that, include: When the database driver detects a switch between the master and slave databases, it determines whether the master and slave databases have completed the master-slave switch and achieved session synchronization. If so, the database driver will send the session requests cached during the master-slave switchover to the slave database, which is now the master database, so that the slave database can handle the session requests; The database driver receives the response returned from the database based on the session request and sends the response to the client to which the session request belongs; The step of determining whether the master database and slave database have completed master-slave switchover and achieved session synchronization includes: The database driver determines whether the master-slave switch is complete by checking the heartbeat and the status of the master and slave databases. If not, it waits, and if the cached session request times out during the waiting period, it sends a failure response to the client of the timed-out session request. Before the database driver detects a switchover between the master and slave databases, the method further includes: The database driver connects to the master and slave databases based on multi-data source configuration information; If the database driver does not receive a response to the session request returned by the master database, it will determine the status of the master database and the slave database to determine whether a master-slave database switchover has occurred. If so, then cache the client's session requests during the switchover period between the primary and secondary databases.

2. The method according to claim 1, characterized in that, Before the database driver detects a switchover between the master and slave databases, the method further includes: The system uses heartbeat detection and the status of both the primary and secondary databases to determine whether a switch has occurred in the primary database. If no switch occurs, the client's session request is sent to the master database.

3. The method according to claim 1, characterized in that, Determining whether the master and slave databases have completed master-slave failover and achieved session synchronization also includes: The connection list and session information in the master database are synchronized to the slave database so that the slave database can parse and load them, and the session continuity is achieved when a session request is received from the database driver.

4. The method according to claim 1, characterized in that, The database driver sends cached session requests during master-slave failover to the slave database, which is now the master database, including: The database driver retrieves all session requests cached by the current database driver from memory and sends the session requests to the slave database that is currently the master database.

5. A database master-slave switching method with zero user awareness, characterized in that, include: When the master database receives a connection request from the database driver, it performs connection verification. If the verification passes, it connects to the database driver and synchronizes the connection information, context information, and log information to the slave database. If the master database receives a response from the slave database indicating successful synchronization, it sends the information from both the master and slave databases to the database driver so that the database driver is stored in memory. The master database receives the client's session request sent by the database driver. After processing, the master database returns a response to the session request to the database driver, so that the database driver responds to the client that sent the session request. During master-slave failover, the hook function in the master database captures failure events and writes the session information in the master database into the specified WAL file, distinguishing it from the log WAL file. Then, the WAL file containing the session information and the log WAL file are sent to the slave database via streaming replication. After receiving the WAL log file sent by the master database, the slave database parses the session information and loads it into memory.

6. The method according to claim 5, characterized in that, Also includes: After receiving the WAL file containing the logs from the new master database, the slave database parses it to obtain the connection list and reads the connection events. It then reads the session information into memory and waits for the database driver to send a session request to ensure session continuity.

7. A database master-slave switching system with zero user awareness, characterized in that, include: The main database, slave databases, database drivers, and multiple clients; When the database driver detects a switch between the master and slave databases, it determines whether the master and slave databases have completed the master-slave switch and achieved session synchronization. If so, the database driver will send the session requests cached during the master-slave switchover to the slave database, which is now the master database, so that the slave database can handle the session requests; The database driver receives the response returned from the database based on the session request and sends the response to the client to which the session request belongs; The step of determining whether the master database and slave database have completed master-slave switchover and achieved session synchronization includes: The database driver determines whether the master-slave switch is complete by checking the heartbeat and the status of the master and slave databases. If not, it waits, and if the cached session request times out during the waiting period, it sends a failure response to the client of the timed-out session request. Before the database driver detects a switchover between the master and slave databases, the system also includes: The database driver connects to the master and slave databases based on multi-data source configuration information; If the database driver does not receive a response to the session request returned by the master database, it will determine the status of the master database and the slave database to determine whether a master-slave database switchover has occurred. If so, then cache the client's session requests during the switchover period between the primary and secondary databases.

8. A database master-slave switching device that allows users to switch without noticing, characterized in that, include: The detection unit is used to determine whether the master database and slave database have completed the master-slave switch and achieved session synchronization when a switch occurs between the master database and the slave database. The switching unit is used to send the session requests cached during the master-slave switch to the slave database, which is now the master database, when the detection unit determines that the master-slave switch is complete, so that the slave database can process the session requests. A receiving unit is configured to receive the response returned from the database based on the session request and send the response to the client to which the session request belongs; The detection unit is further used for: The database driver determines whether the master-slave switch is complete by checking the heartbeat and the status of the master and slave databases. If not, it waits, and if a cached session request times out during the waiting period, it sends a failure response to the client of the timed-out session request. The device is also used for: The database driver connects to the master and slave databases based on multi-data source configuration information; If the database driver does not receive a response to the session request returned by the master database, it will determine the status of the master database and the slave database to determine whether a master-slave database switchover has occurred. If so, then cache the client's session requests during the switchover period between the primary and secondary databases.

9. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; The memory is used to store computer programs; When the processor executes a program stored in the memory, it implements the method as described in any one of claims 1-6.

Images