Method, device and equipment for upgrading distributed database and medium

Abstract

The application discloses an upgrading method and device of a distributed database, equipment and a medium, and belongs to the field of data processing. The method comprises the following steps: starting a new agent process, loading process parameters, and the application port number of the new agent process being the same as that of the original agent process; in the case that the transaction state of the session of the original agent process indicates that the transaction is completed, transmitting the session information and the connection handle of the original agent process to the new agent process; receiving a database operation request corresponding to the connection handle by the new agent process, wherein the database operation request comprises a database operation statement; and sending the database operation statement to the target data node indicated by the database operation statement through a target backend connection based on the database operation statement and a preset connection pool of the new agent process. According to the embodiment of the application, the execution failure rate of the business in the upgrading process can be reduced.

Description

Technical Field

[0001] The present application relates to the field of data processing, and in particular to a method, apparatus, device and medium for upgrading a distributed database. Background Art

[0002] A distributed database consists of a proxy layer and data nodes. The proxy layer establishes a front-end connection with the client and a back-end connection with the data nodes. The proxy layer receives database operation commands from the client through the front-end connection, routes the commands to the corresponding data nodes, and then transmits the data node's response back to the client. With the continuous advancement of database technology, upgrades are needed to improve the performance of distributed databases.

[0003] At present, a rolling upgrade method is adopted for distributed databases. During the rolling upgrade process, the original proxy process is shut down and a new proxy process is started. During the restart of the new proxy process, the proxy layer and the client will be disconnected, causing the execution of database operation statements to be terminated or the business to roll back, which increases the business execution failure rate. Summary of the Invention

[0004] The embodiments of the present application provide a method, apparatus, device, and medium for upgrading a distributed database, which can reduce the failure rate of business execution during the upgrade process.

[0005] In a first aspect, an embodiment of the present application provides a method for upgrading a distributed database, including: starting a new proxy process, completing the loading of process parameters, and the application port number of the new proxy process is the same as the application port number of the original proxy process; when the transaction status of the session of the original proxy process indicates that the transaction is ended, the session information and connection handle of the original proxy process are transferred to the new proxy process; receiving a database operation request corresponding to the connection handle through the new proxy process, the database operation request including a database operation statement; based on the database operation statement and the connection pool preset by the new proxy process, sending the database operation statement to the target data node indicated by the database operation statement through the target backend connection.

[0006] In the second aspect, an embodiment of the present application provides an upgrade device for a distributed database, including: a preparation module, used to start a new proxy process and complete the loading of process parameters, the application port number of the new proxy process is the same as the application port number of the original proxy process; a session switching module, used to transfer the session information and connection handle of the original proxy process to the new proxy process when the transaction status of the session of the original proxy process indicates that the transaction is ended; a receiving module, used to receive a database operation request corresponding to the connection handle through the new proxy process, the database operation request including a database operation statement; a sending module, used to send the database operation statement to the target data node indicated by the database operation statement through the target backend connection based on the database operation statement and the connection pool preset by the new proxy process.

[0007] In a third aspect, an embodiment of the present application provides an upgrade device for a distributed database, comprising: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, the upgrade method for the distributed database of the first aspect is implemented.

[0008] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium having computer program instructions stored thereon. When the computer program instructions are executed by a processor, the distributed database upgrade method of the first aspect is implemented.

[0009] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program, which implements the distributed database upgrade method of the first aspect when the computer program is executed by a processor.

[0010] The embodiments of the present application provide a method, apparatus, device and medium for upgrading a distributed database, which starts a new proxy process with the same application port number as the original proxy process and completes the preparation work of the new proxy process. When the transaction of the session of the original proxy process ends, the session information and connection handle of the original proxy process are transmitted to the new proxy process to switch the session of the original proxy process to the new proxy process. Subsequently, when there is a database operation request sent by the client, the new proxy process can receive the database operation request corresponding to the connection handle and send the database operation statement to the corresponding data node through the back-end connection. The upgrade process is imperceptible to the client. In the process of upgrading the original proxy process to the new proxy process, the client will no longer experience a disconnection phenomenon, thereby reducing the failure rate of business execution during the upgrade process. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0012] Figure 1 A schematic diagram of an example architecture of a distributed database provided in an embodiment of the present application;

[0013] Figure 2 A flowchart of a distributed database upgrade method provided in one embodiment of the present application;

[0014] Figure 3 A schematic diagram of an example of data transmission between an original proxy process and a new proxy process provided in an embodiment of the present application;

[0015] Figure 4A flowchart of an example of transmitting a database operation statement through a target backend connection provided in an embodiment of the present application;

[0016] Figure 5 A schematic diagram of the structure of a distributed database upgrade device provided in one embodiment of the present application;

[0017] Figure 6 A schematic diagram of the structure of a distributed database upgrade device provided in one embodiment of the present application. DETAILED DESCRIPTION

[0018] The features and exemplary embodiments of various aspects of the present application will be described in detail below. In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain the present application, rather than to limit the present application. For those skilled in the art, the present application can be implemented without the need for some of these specific details. The following description of the embodiments is merely to provide a better understanding of the present application by illustrating examples of the present application. It should be noted that the acquisition, storage, use, processing, etc. of information and data in the embodiments of the present application are authorized by the user or relevant agencies and comply with the relevant provisions of national laws and regulations.

[0019] A distributed database may include a proxy layer and data nodes. The proxy layer establishes a front-end connection with the client and a back-end connection with the data node. The proxy layer receives database operation statements sent by the client through the front-end connection, routes the statements to the corresponding data node, and then feeds the data node's response back to the client. With the continuous development of database technology, upgrades are necessary to improve the performance of distributed databases. Currently, distributed databases use a rolling upgrade method. During a rolling upgrade, the original proxy process is shut down and a new proxy process is launched. During the restart of the new proxy process, the proxy layer and the client may become disconnected, resulting in the termination of database operation statement execution or business rollback, which increases the business execution failure rate.

[0020] The present application provides a distributed database upgrade method, apparatus, device, and medium capable of identifying the transaction status of a session. Upon completion of a transaction, the method transmits the connection information of the original proxy process to a new proxy process. After receiving the connection information, the new proxy process can receive requests for the session corresponding to the original proxy process based on the connection information and route them to the corresponding data node to perform database operations. The upgrade process from the original proxy process to the new proxy process prevents disconnection with the client application, rendering the client application unaware of the proxy process upgrade process and reducing the failure rate of business execution.

[0021] To facilitate understanding, here we first briefly introduce the application architecture of the distributed database upgrade method, device, equipment and medium provided by this application. Figure 1 The following is a schematic diagram of an example of a distributed database provided in an embodiment of the present application. Figure 1 As shown, the client 11 can establish a front-end connection with the proxy layer 12 , and the proxy layer 12 can establish a back-end connection with the data node 13 .

[0022] The client 11 may establish a front-end connection with the proxy layer 12 through, but not limited to, JAVA Database Connectivity (JDBC), Common Application Programming Interface (CAPI), and the like.

[0023] The number of proxy processes (i.e., proxy processes) in the proxy layer 12 can be one or more. Generally, the proxy layer 12 is an active-active structure, i.e., the proxy layer 12 includes multiple proxy processes 121. Each proxy process 121 may be provided with a front-end connection function module 1211, which can be used to establish a front-end connection with the client 11. The proxy process 121 may also be provided with a connection pool 1212, which can store idle back-end connections. The proxy process 121 can use these idle back-end connections to transmit database operation statements to the data node 13 when needed.

[0024] The data nodes 13 may have a distributed data node architecture, where each data node 13 may be considered a database or a component of a database. The proxy process 121 may obtain idle backend connections from the connection pool 1212 and use these idle backend connections to transmit database operation statements received from the client 11 to the corresponding data node 13. In embodiments of the present application, the data nodes 13 may have a multi-replica node structure. For example, the data nodes 13 may include a master data node, a backup data node, and a slave data node to improve data security and reliability.

[0025] The following describes the distributed database upgrade method, device, equipment and medium provided in this application.

[0026] The present application provides a distributed database upgrade method, which can be applied to scenarios where the proxy layer of the distributed database, i.e., the proxy process, needs to be updated. The distributed database upgrade method can be executed by the distributed database upgrade device, equipment, etc., and is not limited here. Figure 2 This is a flow chart of a distributed database upgrade method provided in one embodiment of the present application, such as Figure 2As shown, the distributed database upgrade method may include steps S201 to S204.

[0027] In step S201, a new agent process is started and the loading of process parameters is completed.

[0028] The new proxy process is the upgraded proxy process, and the original proxy process is the pre-upgrade proxy process. The proxy process is also called a proxy process. The application port number of the new proxy process is the same as the application port number of the original proxy process. This allows clients to interact with the new proxy process through the same application port number without changing any configuration.

[0029] Process parameters can be preconfigured in the storage area. These parameters include, but are not limited to, operational parameters and topology parameters. These parameters can be stored in files, which the new agent process can read and load. It's important to note that topology parameters should not be modified during an upgrade. For example, the loading of process parameters may involve conf files and topo files; conf files are mainly used to store various operating parameters, and conf files may include basedir files and log files. The new agent process and the original agent process have their own basedir files and log files. The basedir files and log files of the new agent process are stored in different storage areas from those of the original agent process, that is, the storage addresses of the basedir files and log files of the new agent process are different from those of the original agent process to avoid file conflicts; topo files are mainly used to store the architecture information and user information of data nodes; user information should be avoided from being changed during the upgrade process. If the architecture of the data node changes, that is, the topology of the data node changes, such as the master-slave switching of the data node, the new agent process needs to synchronize the architecture information of the data node in its topo file with the architecture information of the data node after the topology changes, that is, the topo file needs to be synchronized to the new topo file version.

[0030] Step S201 can complete the preparation of the new agent process.

[0031] In step S202, when the transaction status of the session of the original proxy process indicates that the transaction is completed, the session information and connection handle of the original proxy process are transferred to the new proxy process.

[0032] The original proxy process can identify the transaction status of each of its own sessions, confirm whether the transaction has ended, and start executing the session switch when it recognizes that the transaction status indicates that the transaction has ended. The end of the transaction due to commit, the end of the transaction due to rollback, or the end of the transaction due to an exception are all within the protection scope of the embodiments of the present application. The transaction here refers to a database transaction, which may specifically include database features that can ensure that a series of database operations can all succeed or all fail. The original proxy process can transmit its own session information and connection handle to the new proxy process through the data transmission channel between the original proxy process and the new proxy process.

[0033] The session information may include session private information, which may include but is not limited to system variables, user variables, schema information, stmt information, last_insert_id, capability identifier, setting attributes, etc. The connection handle may be used to identify the connection, which may include but is not limited to a file descriptor (fd).

[0034] By transmitting the session information and the connection handle, the front-end connection between the original proxy process and the client can be migrated to the new proxy process and the client, thus realizing the session migration between the original proxy process and the new proxy process.

[0035] In step S203, a database operation request corresponding to the connection handle is received through the new proxy process.

[0036] The original proxy process no longer receives database operation requests corresponding to the connection handle, such as SQL operation requests. The session is migrated to the new proxy process, which can then receive database operation requests corresponding to the connection handle and perform subsequent operations corresponding to the database operation request.

[0037] The database operation request includes a database operation statement, which can be used to operate data in a data node.

[0038] In step S204, based on the database operation statement and the connection pool preset by the new proxy process, the database operation statement is sent to the target data node indicated by the database operation statement through the target backend connection.

[0039] The new proxy process is configured with a connection pool. The connection pool stores idle backend connections, which are idle backend connections. It should be noted that when a session is switched from the original proxy process to the new proxy process, the connection pool is empty. The target data node can be determined based on the database operation statement. The target data node is the data node indicated by the database operation statement. Specifically, the database operation statement can be parsed to obtain a database partitioning result, thereby determining the target data node. The target backend connection can be obtained by determining whether the new proxy process's connection pool has idle backend connections. Alternatively, the target backend connection can be obtained by combining the transaction status of the new proxy process's session with the availability of idle backend connections. The target backend connection is the backend connection used by the new proxy process to transmit the database operation statement to the corresponding data node. The target data node can execute the corresponding database operation based on the database operation statement and feedback the operation results to the new proxy process via the target backend connection. The new proxy process then feedbacks the operation results to the client.

[0040] In an embodiment of the present application, a new proxy process with the same application port number as the original proxy process is started and the preparation work of the new proxy process is completed. When the transaction of the session of the original proxy process ends, the session information and connection handle of the original proxy process are transferred to the new proxy process to switch the session of the original proxy process to the new proxy process. Subsequently, if there is a database operation request sent by the client, the new proxy process can receive the database operation request corresponding to the connection handle and send the database operation statement to the corresponding data node through the back-end connection. The upgrade process is imperceptible to the client. In the process of upgrading the original proxy process to the new proxy process, the client will no longer experience a disconnection phenomenon, thereby reducing the failure rate of business execution during the upgrade process.

[0041] In some embodiments, the connection information may be transmitted by establishing a data transmission channel between the original agent process and the new agent process. Figure 3 This is a flowchart of a distributed database upgrade method provided by another embodiment of the present application. Figure 3 and Figure 2 The difference is that Figure 2 Step S202 in the above example can be specifically broken down into Figure 3 Steps S2021 to S2023 in .

[0042] In step S2021, when the transaction status of the session of the original proxy process indicates that the transaction is completed, the original proxy process is stopped from receiving database operation requests corresponding to the connection handle of the session.

[0043] The transaction of the original proxy process's session ends, and the original proxy process no longer receives database operation requests corresponding to the connection handle of the session, so as to avoid business failure caused by transaction interruption of the session.

[0044] In step S2022, a data transmission channel is established between the original agent process and the new agent process.

[0045] Based on the performance requirements for session switching between the original and new proxy processes, one or more data transmission channels can be established. In some examples, the data transmission channels can include Unix domain sockets (UDS) channels. The time required to transfer data between the original and new proxy processes via the data transmission channels is very short, at the millisecond level, and session switching between the original and new proxy processes does not affect the client.

[0046] In step S2023, the session information and connection handle of the original proxy process are transmitted to the new proxy process through the data transmission channel.

[0047] After receiving the session information and connection handle transmitted by the original proxy process through the data transmission channel, the new proxy process can initialize the session corresponding to the session information and connection handle to prepare the environment for receiving database operation requests through the connection handle.

[0048] For example, Figure 3 A schematic diagram of an example of data transmission between the original proxy process and the new proxy process provided in an embodiment of the present application, as shown in FIG. Figure 3 As shown, a UDS channel is established between the original proxy process and the new proxy process. Session information, such as the original proxy process's session environment information (i.e., session env information), and connection handles, such as listening sockets, are sequentially transferred to the new proxy process via the UDS channel. After the session information and connection handle are transferred from the original proxy process to the new proxy process, the client's front-end connection with the original proxy process is migrated from the source proxy process to the new proxy process. The connection between the client and the original proxy process is a dotted line, indicating that the connection has been migrated; the connection between the client and the new proxy process is a realized connection, indicating that the connection has been migrated.

[0049] In some embodiments, the proxy process may include multiple threads, that is, the original proxy process and the new proxy process each include multiple threads. The transaction states corresponding to the multiple threads may be different. In order to speed up the data transmission speed between the original proxy process and the new proxy process and improve the upgrade speed, the transaction state of the session of each thread of the original proxy process can be identified; when the transaction state of the session of any thread of the original proxy process indicates that the transaction is completed, the session information and connection handle of the session of any thread are transmitted to the new proxy process; if the transaction state of the session of a thread of the original proxy process indicates that the transaction is not completed, wait until the transaction state of the session of this thread indicates that the transaction is completed, and then transmit the session information and connection handle of the session of this thread to the new proxy process. The transmission of the session information and connection handle corresponding to the multiple threads in the original proxy process can not interfere with each other, thereby improving the upgrade efficiency.

[0050] For example, the original proxy process includes thread A1, thread A2, and thread A3, and can respectively identify the transaction status corresponding to thread A1, the transaction status corresponding to thread A2, and the transaction status corresponding to thread A3. If the transaction status corresponding to thread A1 indicates that the transaction has not ended, the transaction status corresponding to thread A2 indicates that the transaction has ended, and the transaction status corresponding to thread A3 indicates that the transaction has ended, the session information and connection handle of the session of thread A2 and the session information and connection handle of the session of thread A3 can be first transmitted to the new proxy process through the data transmission channel, and then the transaction status corresponding to thread A1 can be continued to be monitored. When the transaction status corresponding to thread A1 indicates that the transaction has ended, the session information and connection handle of the session of thread A1 can be transmitted to the new proxy process.

[0051] In some embodiments, after the new proxy process obtains the session information and connection handle sent by the original proxy process, it can obtain a session structure corresponding to the connection handle transmitted to the new proxy process based on a preset association relationship, and the session structure is generated based on the session information corresponding to the connection handle; the session structure is assigned to the connection handle transmitted to the new proxy process; and the database operation request corresponding to the connection handle is received through the new proxy process.

[0052] The association relationship includes a correspondence between the connection handle and the session information. Based on the association relationship, the original proxy process can transmit the connection handle and session information in a predetermined format to the new proxy process, allowing the new proxy process to understand the relationship between the session information and the connection handle in the received information. The new proxy process can generate a session structure based on the session information corresponding to the connection handle and assign the session structure to the corresponding connection handle. After receiving a database operation request corresponding to the connection handle, the new proxy process can process the database operation request based on the session structure corresponding to the connection handle.

[0053] In an embodiment of the present application, the front-end connection and the back-end connection are decoupled, and the migration of the session is mainly for the front-end connection. The back-end connection between the proxy process and the data node does not need to be migrated. In the case that the new proxy process receives a database operation request corresponding to the connection handle, the new proxy process can obtain a back-end connection for transmitting the database operation statement to the data node based on the connection pool configured by itself. Specifically, the database operation statement can be parsed to determine the target data node; in the case that there is a bound back-end connection that is bound to the front-end connection of the database operation statement and points to the target data node, the bound back-end connection is used as the target back-end connection to send the database operation statement to the target data node; in the case that the connection pool has a first back-end connection for transmitting the database operation statement, the first back-end connection is used as the target back-end connection to send the database operation statement to the target data node; in the case that the connection pool does not have a first back-end connection for transmitting the database operation statement, a new second back-end connection is created, and the second back-end connection is used as the target back-end connection to send the database operation statement to the target data node.

[0054] During database operations, there may be backend connections not bound to a frontend connection, i.e., idle backend connections, as well as backend connections bound to a frontend connection. If there is a backend connection bound to the frontend request currently transmitting the database operation request, the backend connections bound to the frontend request are checked to see if there is a backend connection pointing to the target data node. If there is a backend connection pointing to the target data node, the backend connection pointing to the target data node, i.e., the bound backend connection, is used as the target backend connection. In some cases, if a database operation statement indicates multiple target data nodes, it is necessary to determine whether the backend connection bound to the frontend connection covers all target data nodes. If so, the backend connection is determined as the target backend connection. If not, it is necessary to check whether there are any idle backend connections in the connection pool. The first backend connection is an idle backend connection in the connection pool that can serve as the target backend connection. If there are available idle backend connections in the connection pool, one of the idle backend connections in the connection pool can be determined as the first backend connection, and the database operation statement is sent to the target data node using the first backend connection as the target backend connection. The second backend connection is a newly created backend connection. If there is no idle connection in the connection pool, a second backend connection needs to be created and the second backend connection is used as the target backend connection to send the database operation statement to the target data node.

[0055] Furthermore, the target backend connection can also be obtained in combination with whether the frontend connection transmitting the database operation statement has a transaction enabled. Specifically, if the frontend connection transmitting the database operation statement has not a transaction enabled, if there is an idle backend connection in the connection pool, the idle backend connection is determined as the first backend connection; if the frontend connection transmitting the database operation statement has a transaction enabled, if the backend connection bound to the frontend connection of the database operation statement points to the target data node, the bound backend connection pointing to the target data node is determined as the bound backend connection; if the frontend connection transmitting the database operation statement has a transaction enabled, if the backend connection bound to the frontend connection of the database operation statement does not point to the target data node, an idle backend connection is selected from the connection pool as the first backend connection.

[0056] In some examples, after obtaining a first backend connection, liveness detection and attribute synchronization need to be performed on the first backend connection. After establishing a second backend connection, attribute synchronization needs to be performed on the second backend connection.

[0057] The liveness detection can detect the activity of the first backend connection to determine whether the first backend connection is valid. If the liveness detection passes, the first backend connection can be determined to be valid, that is, the first backend connection can be used as the target backend connection. If the liveness detection fails, the first backend connection can be determined to be invalid, that is, the first backend connection cannot be used as the target backend connection. The idle backend connections in the connection pool are in a maintained state. During the period when the idle backend connections are in the maintained state, the idle backend connections may undergo changes in the cluster topology. If the cluster topology changes, the idle backend connection is inactive and fails the liveness detection. Changes in the cluster topology may include, but are not limited to, replica switching of the data node associated with the idle backend connection and / or disconnection of the idle backend connection. Replica switching of data nodes may include, but are not limited to switching between primary data nodes, backup data nodes, and slave data nodes. If the first backend connection fails the liveness detection, the first backend connection may be released.

[0058] Attribute synchronization for the first backend connection is used to synchronize the setting variables of the first backend connection with the setting variables of the frontend connection for database operation statements. Attribute synchronization for the second backend connection is used to synchronize the setting variables of the second backend connection with the setting variables of the frontend connection for database operation statements. Setting variables can be used to set the database environment. If the setting variables of the first backend connection, the setting variables of the second backend connection, and the setting variables of the frontend connection are inconsistent, the database operation statement cannot be transmitted to the data node via the frontend connection and the first backend connection, or cannot be transmitted to the data node via the frontend connection and the second backend connection. Attribute synchronization can ensure that the database environment of the first backend connection, the database environment of the second backend connection, and the database environment of the frontend connection are consistent, thus avoiding errors.

[0059] In some embodiments, after the target data node executes a database operation statement, the target backend connection after transmitting the database operation statement can be processed based on whether the database operation statement starts a transaction. Specifically, after the target data node executes the database operation statement, if the database operation statement does not start a transaction or has closed a transaction, the target backend connection is placed in the connection pool as an idle backend connection; after the target data node executes the database operation statement, if the database operation statement has started a transaction, the target backend connection remains bound to the frontend connection that transmitted the database operation statement.

[0060] In some embodiments, an upper limit on the number of idle backends in the connection pool, i.e., a preset upper limit, can be set in advance. After the target data node executes a database operation statement, if the database operation statement does not open a transaction or has closed a transaction, and the number of idle backend connections in the connection pool reaches the preset upper limit, the target backend connection is discarded, thereby controlling the number of idle backend connections in the connection pool to be within the performance requirement range, thereby ensuring the performance of the distributed database.

[0061] For ease of understanding, the following example illustrates the process of transmitting database operation statements through the target backend connection in an embodiment of the present application. Figure 4 The flowchart of an example of transmitting a database operation statement through a target backend connection provided in an embodiment of the present application is as follows: Figure 4 As shown, the process of transmitting the database operation statement through the target backend connection may include steps a1 to a13.

[0062] In step a1, the database operation statement is parsed to determine the target data node.

[0063] In step a2, determine whether the database operation statement opens a transaction. If so, proceed to step a3; if not, proceed to step a6.

[0064] In step a3, it is determined whether there is a backend connection bound to the frontend connection. If there is a backend connection bound to the frontend connection, step a4 is executed; if there is no backend connection bound to the frontend connection, step a6 is executed.

[0065] In step a4, it is determined whether the data node indicated by the bound backend connection covers the target data node; if so, step a5 is executed; if not, step a6 is executed.

[0066] In step a5, the bound backend connection is used as the target backend connection to send a database operation statement to the target data node.

[0067] In step a6, the connection pool is checked for idle backend connections. If so, step a7 is executed; if not, step a9 is executed.

[0068] In step a7, a liveness check and attribute synchronization are performed on the idle backend connection. It should be noted that if the liveness check passes, step a8 is executed; if the liveness check fails, the idle backend connection is discarded.

[0069] In step a8, the idle backend connection is used as the target backend connection to send a database operation statement to the target data node.

[0070] In step a9, a new backend connection is created as the target backend connection to send a database operation statement to the target data node. It should be noted that after the new backend connection is created, the attributes of the backend connection need to be synchronized.

[0071] In step a10, the operation result of the data node executing the database operation statement is returned to the client.

[0072] In step a11, it is determined whether the current database operation statement opens a transaction. If so, step a12 is executed; if not, or the transaction is closed, step a13 is executed.

[0073] In step a12, the binding state of the target backend connection and the frontend connection is maintained. In this step, the target backend connection is not put back into the connection pool.

[0074] In step a13, the target backend connection is put back into the connection pool.

[0075] The specific contents of the above steps a1 to a13 can be found in the relevant descriptions in the above embodiments, which will not be repeated here.

[0076] In some embodiments, a periodic check can be performed to determine whether the upgrade is complete. Specifically, the process can detect whether the session information and connection handle of the original proxy process have all been transferred to the new proxy process. If all the session information and connection handle of the original proxy process have all been transferred to the new proxy process, the original proxy process can be terminated, and the upgrade is complete. If all the session information and connection handle of the original proxy process have all been transferred to the new proxy process, indicating that all sessions of the original proxy process have been switched to the new proxy process, the original proxy process can be terminated, and the upgrade process is complete.

[0077] The present application provides a distributed database upgrade device. Figure 5 This is a structural diagram of a distributed database upgrade device provided in one embodiment of the present application, as shown in FIG. Figure 5 As shown, the distributed database upgrade device 300 may include a preparation module 301 , a session switching module 302 , a receiving module 303 and a sending module 304 .

[0078] The preparation module 301 can be used to start a new proxy process and complete the loading of process parameters. The application port number of the new proxy process is the same as the application port number of the original proxy process.

[0079] The session switching module 302 may be configured to transfer the session information and connection handle of the original proxy process to the new proxy process when the transaction status of the session of the original proxy process indicates that the transaction is completed.

[0080] The receiving module 303 can be used to receive a database operation request corresponding to the connection handle through the new proxy process. The database operation request includes a database operation statement.

[0081] The sending module 304 may be configured to send the database operation statement to the target data node indicated by the database operation statement through the target backend connection based on the database operation statement and the connection pool preset by the new proxy process.

[0082] In some embodiments, the session switching module 302 can be specifically used to: stop the original proxy process from receiving database operation requests corresponding to the connection handle of the session when the transaction status of the session of the original proxy process indicates that the transaction has ended; establish a data transmission channel between the original proxy process and the new proxy process; and transmit the session information and connection handle of the original proxy process to the new proxy process through the data transmission channel.

[0083] In some embodiments, the original proxy process includes multiple threads. The session switching module 302 may be specifically configured to: transfer the session information and connection handle of any thread's session to the new proxy process if the transaction status of any thread's session in the original proxy process indicates that the transaction is completed; and if the transaction status of a thread's session in the original proxy process indicates that the transaction is not completed, wait until the transaction status of the thread's session indicates that the transaction is completed, and then transfer the session information and connection handle of the thread's session to the new proxy process.

[0084] In some embodiments, the distributed database upgrading apparatus 300 may further include an assignment module.

[0085] The assignment module can be used to: obtain a session structure corresponding to the connection handle transmitted to the new proxy process according to a preset association relationship, the session structure is generated based on the session information corresponding to the connection handle, and the association relationship includes the correspondence between the connection handle and the session information; assign the session structure to the connection handle transmitted to the new proxy process.

[0086] Correspondingly, the receiving module 303 may be configured to receive a database operation request corresponding to the connection handle through the new proxy process.

[0087] In some embodiments, the sending module 304 can be specifically used to: parse database operation statements and determine the target data node; in a case where there is a bound backend connection that is bound to the frontend connection of the database operation statement and points to the target data node, use the bound backend connection as the target backend connection to send the database operation statement to the target data node; in a case where there is a first backend connection for transmitting database operation statements in the connection pool, use the first backend connection as the target backend connection to send the database operation statement to the target data node; in a case where there is no first backend connection for transmitting database operation statements in the connection pool, create a new second backend connection, and use the second backend connection as the target backend connection to send the database operation statement to the target data node.

[0088] In some examples, the sending module 304 can also be used to: when the front-end connection for transmitting the database operation statement has not opened a transaction, if there is an idle back-end connection in the connection pool, the idle back-end connection is determined as the first back-end connection; when the front-end connection for transmitting the database operation statement has opened a transaction, if the back-end connection bound to the front-end connection of the database operation statement points to the target data node, the bound back-end connection pointing to the target data node is determined as the bound back-end connection; when the front-end connection for transmitting the database operation statement has opened a transaction, if the back-end connection bound to the front-end connection of the database operation statement does not point to the target data node, an idle back-end connection is selected from the connection pool as the first back-end connection.

[0089] In some examples, the distributed database upgrade apparatus 300 further includes a detection processing module. The detection processing module can be configured to perform liveness detection and attribute synchronization on the first backend connection. If the liveness detection passes, the first backend connection is considered valid. Attribute synchronization is configured to synchronize the configuration variables of the first backend connection with the configuration variables of the frontend connection in the database operation statement.

[0090] In some embodiments, the distributed database upgrade apparatus 300 may further include a connection pool management module.

[0091] The connection pool management module can be used to: after the target data node executes a database operation statement, if the database operation statement does not open a transaction or has closed the transaction, put the target backend connection into the connection pool as an idle backend connection; after the target data node executes a database operation statement, if the database operation statement has opened a transaction, keep the target backend connection bound to the front-end connection that transmits the database operation statement.

[0092] In some embodiments, the connection pool management module is also used to: after the target data node executes a database operation statement, if the database operation statement does not open a transaction or has closed a transaction, and the number of idle backend connections in the connection pool reaches a preset upper limit, discard the target backend connection.

[0093] In some embodiments, the distributed database upgrade apparatus 300 may further include an upgrade detection module. The upgrade detection module may be configured to detect whether the session information and connection handle of the original proxy process have been fully transferred to the new proxy process; if so, terminate the original proxy process, completing the upgrade.

[0094] It should be noted that the distributed database upgrade device 300 is a device corresponding to the above-mentioned distributed database upgrade method. All implementation methods in the above-mentioned method embodiments are applicable to the embodiments of the device and can achieve the same technical effects.

[0095] The present application also provides a distributed database upgrade device. Figure 6 A schematic diagram of the structure of a distributed database upgrade device provided in one embodiment of the present application is shown in FIG. Figure 6 As shown, the distributed database upgrade device 400 includes a memory 401 , a processor 402 , and a computer program stored in the memory 401 and executable on the processor 402 .

[0096] In some examples, the processor 402 may include a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or may be configured to implement one or more integrated circuits of the embodiments of the present application.

[0097] The memory 401 may include a read-only memory (ROM), a random access memory (RAM), a magnetic disk storage medium device, an optical storage medium device, a flash memory device, an electrical, optical or other physical / tangible memory storage device. Therefore, generally, the memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., a memory device) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method for upgrading a distributed database according to an embodiment of the present application.

[0098] The processor 402 reads the executable program code stored in the memory 401 to run a computer program corresponding to the executable program code, so as to implement the distributed database upgrade method in the above embodiment.

[0099] In some examples, the distributed database upgrade device 400 may further include a communication interface 403 and a bus 404. Figure 6As shown, the memory 401 , the processor 402 , and the communication interface 403 are connected via a bus 404 and communicate with each other.

[0100] The communication interface 403 is mainly used to implement communication between the modules, devices, units and / or equipment in the embodiment of the present application. Input devices and / or output devices can also be connected through the communication interface 403.

[0101] The bus 404 includes hardware, software, or both, and couples the components of the distributed database upgrade device 400 to each other. By way of example and not limitation, the bus 404 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an InfiniBand interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-E) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local Bus (VLB) bus, or other suitable buses, or a combination of two or more of these. Where appropriate, the bus 404 may include one or more buses. Although embodiments herein describe and illustrate a particular bus, this application contemplates any suitable bus or interconnect.

[0102] The present application also provides a computer-readable storage medium having computer program instructions stored thereon. When the computer program instructions are executed by a processor, the distributed database upgrade method in the above-mentioned embodiment can be implemented, and the same technical effect can be achieved. To avoid repetition, the above-mentioned computer-readable storage medium may include a non-transitory computer-readable storage medium, such as a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc., which is not limited here.

[0103] The present application also provides a computer program product, which includes a computer program. When the computer program is executed by a processor, it implements the distributed database upgrade method in the above embodiment and can achieve the same technical effect. To avoid repetition, it will not be repeated here.

[0104] It should be understood that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. For device embodiments, equipment embodiments, and computer-readable storage medium embodiments, the relevant parts can be referred to the description part of the method embodiment. This application is not limited to the specific steps and structures described above and shown in the figures. Those skilled in the art can make various changes, modifications and additions, or change the order between the steps after understanding the spirit of this application. In addition, for the sake of brevity, a detailed description of known method technologies is omitted here.

[0105] Aspects of the present application have been described above with reference to the flowcharts and / or block diagrams of the methods, devices (systems) and computer program products according to the embodiments of the present application. It should be understood that each box in the flowchart and / or block diagram and the combination of each box in the flowchart and / or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer or other programmable data processing device to produce a machine so that these instructions executed via the processor of the computer or other programmable data processing device enable the implementation of the function / action specified in one or more boxes of the flowchart and / or block diagram. This processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor or a field programmable logic circuit. It is also understood that each box in the block diagram and / or the flowchart and the combination of the boxes in the block diagram and / or the flowchart can also be implemented by the dedicated hardware that performs the specified function or action, or can be implemented by the combination of dedicated hardware and computer instructions.

[0106] Those skilled in the art should understand that the above embodiments are illustrative rather than restrictive. Different technical features appearing in different embodiments can be combined to achieve beneficial effects. Based on a study of the drawings, the specification and the claims, those skilled in the art should be able to understand and implement other variations of the disclosed embodiments. In the claims, the term "comprising" does not exclude other devices or steps; the quantifier "one" does not exclude a plurality; the terms "first" and "second" are used to identify names rather than to indicate any specific order. Any figure marks in the claims should not be understood as limiting the scope of protection. The functions of multiple parts appearing in the claims can be implemented by a separate hardware or software module. The fact that certain technical features appear in different dependent claims does not mean that these technical features cannot be combined to achieve beneficial effects.

Claims

1. A method for upgrading a distributed database, characterized in that: include: Start a new proxy process and complete the loading of process parameters, wherein the application port number of the new proxy process is the same as the application port number of the original proxy process; When the transaction status of the session of the original proxy process indicates that the transaction is completed, the session information and the connection handle of the original proxy process are transmitted to the new proxy process; receiving, through the new proxy process, a database operation request corresponding to the connection handle, the database operation request including a database operation statement; Based on the database operation statement and the connection pool preset by the new proxy process, the database operation statement is sent to the target data node indicated by the database operation statement through the target backend connection.

2. The method according to claim 1, characterized in that The method of transmitting the session information and the connection handle of the original proxy process to the new proxy process when the transaction status of the session of the original proxy process indicates that the transaction is ended includes: When the transaction status of the session of the original proxy process indicates that the transaction is ended, stopping the original proxy process from receiving database operation requests corresponding to the connection handle of the session; Establishing a data transmission channel between the original proxy process and the new proxy process; The session information and connection handle of the original proxy process are transmitted to the new proxy process through the data transmission channel.

3. The method according to claim 1, characterized in that The original proxy process includes multiple threads; The method of transmitting the session information and the connection handle of the original proxy process to the new proxy process when the transaction status of the session of the original proxy process indicates that the transaction is ended includes: When the transaction status of the session of any one thread of the original proxy process indicates that the transaction is completed, the session information and the connection handle of the session of any one thread are transmitted to the new proxy process; The method further comprises: If the transaction status of the session of one thread of the original proxy process indicates that the transaction is not completed, wait until the transaction status of the session of the one thread indicates that the transaction is completed, and transfer the session information and connection handle of the session of the one thread to the new proxy process.

4. The method according to claim 1, wherein The receiving, through the new proxy process, a database operation request corresponding to the connection handle includes: Obtaining, according to a preset association relationship, a session structure corresponding to the connection handle transmitted to the new proxy process, wherein the session structure is generated based on the session information corresponding to the connection handle, and the association relationship includes a correspondence between the connection handle and the session information; Assigning the session structure to the connection handle transmitted to the new proxy process; A database operation request corresponding to the connection handle is received through the new proxy process.

5. The method according to claim 1, wherein The step of sending the database operation statement to the target data node indicated by the database operation statement through the target backend connection based on the database operation statement and the connection pool preset by the new proxy process includes: Parsing the database operation statement to determine the target data node; In a case where there is a bound backend connection bound to the frontend connection of the database operation statement and pointing to the target data node, sending the database operation statement to the target data node using the bound backend connection as the target backend connection; In a case where the connection pool has a first backend connection for transmitting the database operation statement, sending the database operation statement to the target data node using the first backend connection as the target backend connection; If the connection pool does not have a first backend connection for transmitting the database operation statement, a second backend connection is created, and the database operation statement is sent to the target data node using the second backend connection as the target backend connection.

6. The method according to claim 5, characterized in that Also includes: In a case where a transaction is not opened on the front-end connection for transmitting the database operation statement, if there is an idle back-end connection in the connection pool, determining the idle back-end connection as the first back-end connection; In a case where a transaction has been opened on the front-end connection for transmitting the database operation statement, if the back-end connection bound to the front-end connection of the database operation statement points to the target data node, determining the bound back-end connection pointing to the target data node as the bound back-end connection; In the case where the front-end connection for transmitting the database operation statement has opened a transaction, if the back-end connection bound to the front-end connection for transmitting the database operation statement does not point to the target data node, an idle back-end connection is selected from the connection pool as the first back-end connection.

7. The method according to claim 6, characterized in that Also includes: Performing liveness detection and attribute synchronization on the first backend connection; If the liveness detection is passed, the first backend connection is valid; Attribute synchronization is used to synchronize the setting variables of the first backend connection with the setting variables of the frontend connection of the database operation statement.

8. The method according to claim 1, characterized in that Also includes: After the target data node executes the database operation statement, If the database operation statement does not open a transaction or has closed a transaction, the target backend connection is placed in the connection pool as an idle backend connection; If the database operation statement has opened a transaction, the binding state of the target backend connection and the frontend connection that transmits the database operation statement is maintained.

9. The method according to claim 1, characterized in that Also includes: After the target data node executes the database operation statement, if the database operation statement does not open a transaction or has closed a transaction, and the number of idle backend connections in the connection pool reaches a preset upper limit, the target backend connection is discarded.

10. The method according to claim 1, characterized in that Also includes: Detecting whether the session information and connection handle of the original proxy process are all transferred to the new proxy process; When all the session information and connection handle of the original proxy process are transferred to the new proxy process, the original proxy process is terminated and the upgrade is completed.

11. A distributed database upgrade device, characterized in that: include: A preparation module is used to start a new proxy process and complete the loading of process parameters, wherein the application port number of the new proxy process is the same as the application port number of the original proxy process; A session switching module, configured to transfer the session information and connection handle of the original proxy process to the new proxy process when the transaction status of the session of the original proxy process indicates that the transaction is completed; A receiving module, configured to receive, through the new proxy process, a database operation request corresponding to the connection handle, the database operation request including a database operation statement; The sending module is used to send the database operation statement to the target data node indicated by the database operation statement through the target backend connection based on the database operation statement and the connection pool preset by the new proxy process.

12. A distributed database upgrade device, characterized in that: include: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, the distributed database upgrade method according to any one of claims 1 to 10 is implemented.

13. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer program instructions, and when the computer program instructions are executed by a processor, the distributed database upgrade method according to any one of claims 1 to 10 is implemented.

14. A computer program product, characterized in that The invention comprises a computer program, which implements the distributed database upgrade method according to any one of claims 1 to 10 when executed by a processor.

Images