CN116820688A

CN116820688A - Transaction detection method and related device

Info

Publication number: CN116820688A
Application number: CN202210282996.4A
Authority: CN
Inventors: 熊刚; 牟洪锋
Original assignee: Huawei Cloud Computing Technologies Co Ltd
Current assignee: Huawei Cloud Computing Technologies Co Ltd
Priority date: 2022-03-22
Filing date: 2022-03-22
Publication date: 2023-09-29

Abstract

The application provides a transaction detection method, which comprises the following steps: acquiring an identifier of a first session to which a transaction to be detected belongs, inquiring a registration record according to the identifier of the first session to which the transaction to be detected belongs to acquire an inquiry result, storing at least one identifier of a second session to which the transaction which does not reach an execution site belongs in the registration record, and acquiring a transaction detection result used for representing whether the transaction to be detected is drained according to the inquiry result. In the method, the transaction detection is carried out by sinking middleware such as proxy to a source database node, and the source database node inquires the registration record based on a session registration mechanism, so that whether the transaction is drained or not is quickly determined, complex and time-consuming SQL statement monitoring and execution state judgment are not needed by the middleware such as proxy, a large amount of resource occupation is avoided, and the service performance is ensured.

Description

Transaction detection method and related device

Technical Field

The present application relates to the field of data processing technologies, and in particular, to a transaction detection method, a transaction detection device, a database node, a computer readable storage medium, and a computer program product.

Background

Some Applications (APP) will typically connect database nodes (DB nodes) at runtime and create session objects at the database nodes. During data manipulation, the application maintains an operational context, such as system variables User defined variables, user-defined variables transaction status, transaction status transaction status, user temporary tables, etc., in the session object.

With changes in the size of the user, or upgrades to the application version, it is often necessary to switch the database nodes to which the application is connected. In the process of switching the database node connected by the application from the source database node to the destination database node, since there may be a running transaction in the session of the source database node, the transaction is in a pending (pending) state (specifically, a state between the start and the end of the transaction), the transaction is generally drained (drain transaction), and then session cloning (session clone) is performed, so as to implement application lossless transparent (application lossless transparent, ALT) switching, and meet the requirement of high availability (high Availability).

Draining transactions refers to monitoring running transactions, and blocking operations on corresponding sessions when a certain execution site is reached, so as to lay a foundation for subsequent ALT switching. Currently, the related art employs a middleware connection hold enhancement technique to detect whether a transaction is drained. The middleware may be software located between the application and the database node, which may be, for example, proxy. In particular, proxy maintains a front-end connection (proxy's connection to the application), monitors the execution of the transaction, intercepts structured query commands (Structured Query Language command, SQL command) for a period of time that characterize the final commit of the transaction in the session, and detects whether the transaction is drained.

However, middleware such as proxy intercepts all SQL sentences and judges whether the transaction is actually submitted or not by monitoring each SQL sentence, so that a large amount of resources are required to be consumed, and the performance of the service is affected.

Disclosure of Invention

The application provides a transaction detection method, which sinks transaction detection from middleware such as proxy to a source database node, and the source database node queries a registration record based on a session registration mechanism, so that whether the transaction is drained or not is quickly determined, complex and time-consuming SQL statement monitoring and execution state judgment are not required by the middleware such as proxy, a large amount of resource occupation is avoided, and the service performance is ensured. The application also provides a corresponding apparatus, database node, computer readable storage medium and computer program product.

In a first aspect, the present application provides a transaction detection method. The method may be performed by a source database node. When the application performs ALT switching, the source database node can drain the transaction first. Draining transactions refers to monitoring running transactions, and blocking operations on corresponding sessions when a certain execution site is reached, so as to lay a foundation for subsequent ALT switching. To this end, the source database node may detect whether the transaction is drained, thereby performing subsequent operations to implement the ALT switch if the transaction is drained.

Specifically, the source database node may obtain an identifier of a first session to which the transaction to be detected belongs, and then query a registration record according to the identifier of the first session to which the transaction to be detected belongs to obtain a query result, where the registration record stores an identifier of at least one second session to which the transaction that does not reach the execution site belongs, and then the source database node obtains a transaction detection result for indicating whether the transaction to be detected is drained according to the query result.

In the method, the operation of detecting whether the transaction is drained is sunk to a source database node from middleware such as proxy, for example, a database engine DB Kernel in the source database node, and the source database node inquires the registration record based on a session registration mechanism, so that the method can quickly determine whether the transaction is drained, and does not need the middleware such as proxy to carry out complex and time-consuming SQL statement monitoring and execution state judgment, thereby avoiding a large amount of resource occupation and guaranteeing the service performance. Accordingly, proxy and the like middleware can be lightweight.

In some possible implementations, the source database node may detect whether a transaction is drained by: when the query result characterizes that the identification of the first session is matched with the identification of the second session, determining that the transaction detection result is that the transaction to be detected is not drained; and when the query result characterizes that the identification of the first session is not matched with the identification of the second session, determining that the transaction detection result is the transaction to be detected is drained.

In the method, the source database node is used for rapidly judging whether the transaction is drained by performing simple identification matching operation, so that the efficiency of transaction detection is improved.

In some possible implementations, before the obtaining the identifier of the first session to which the transaction to be detected belongs, the source database node may further store the identifier of a third session to the registration record before the structured query SQL command included in the transaction starts to be executed, where the third session includes the at least one second session.

According to the method, before the session starts to execute the SQL command, the identification of the session is tried to be stored in the registration record, so that the session registration is realized, and the detection of the transaction in some sessions can be avoided from being missed in the transaction detection process.

In some possible implementations, the source database node may also remove from the log an identification of a fourth session to which the transaction arriving at the execution site belongs. According to the method, all the sessions to which the transactions which do not reach the execution site belong are registered, and then the identification of the session to which the transactions which reach the execution site belong is removed, so that the identification of the session to which the transactions which do not reach the execution site belong is stored in the registration record, and further the accuracy of obtaining the transaction detection result by inquiring the registration record is guaranteed.

In some possible implementations, the execution sites include any one or more of:

transaction boundaries, SQL command boundaries, and minimum sub-transaction boundaries.

In the method, the source database node can provide multi-level transaction draining capability by setting different execution sites, so that the requirements of quick draining of short transactions and long transactions can be met.

In some possible implementations, the source database node may receive a maximum drain time period set by the user. Correspondingly, the source database node can query the registration record to obtain a query result according to the identifier of the first session to which the transaction to be detected belongs in the time period corresponding to the maximum draining duration.

The method provides the configuration function of parameters such as the maximum draining duration and the like, so that the user can select the blocking time which can be tolerated by the user under the condition of bearing the draining transaction.

In some possible implementations, the source database node receives a user-set transaction-draining priority to facilitate draining transactions sequentially according to the transaction-draining priority. Therefore, the transaction can be drained according to the service requirement, and the personalized requirement is met.

In some possible implementations, the source database node may also recover the transaction to be detected when the transaction to be detected is drained. In particular, the source database node may trigger a recovery operation for the destination database node to recover the transaction to be detected. It should be noted that when the transaction reaches the transaction boundary, the destination database node does not need to perform cross-node recovery on the transaction, and when the transaction reaches the SQL command boundary or the minimum sub-transaction boundary, the destination database node may perform cross-node recovery on the transaction.

The method realizes the switching of the session at different database nodes by recovering the transaction to be detected, thereby laying a foundation for ALT switching.

In a second aspect, the present application provides a transaction detection device. The device comprises:

the communication module is used for acquiring the identification of the first session to which the transaction to be detected belongs;

the inquiry module is used for inquiring a registration record according to the identification of the first session to which the transaction to be detected belongs to obtain an inquiry result, wherein the identification of the second session to which the transaction does not reach the execution site belongs is stored in the registration record;

and the detection module is used for obtaining a transaction detection result according to the query result, wherein the transaction detection result is used for representing whether the transaction to be detected is drained or not.

In some possible implementations, the detection module is specifically configured to:

when the query result characterizes that the identification of the first session is matched with the identification of the second session, determining that the transaction detection result is that the transaction to be detected is not drained;

and when the query result characterizes that the identification of the first session is not matched with the identification of the second session, determining that the transaction detection result is the transaction to be detected is drained.

In some possible implementations, the apparatus further includes:

the registration management module is configured to store, before the obtaining an identifier of a first session to which a transaction to be detected belongs, an identifier of a third session, before a structured query SQL command included in the transaction starts to be executed, to the registration record, where the third session includes the at least one second session.

In some possible implementations, the registration management module is further configured to:

the identity of the fourth session to which the transaction arriving at the execution site belongs is removed from the registration record.

In some possible implementations, the communication module is further configured to:

receiving the maximum draining duration set by a user;

the query module is specifically configured to:

and inquiring the registration record to obtain an inquiry result according to the identification of the first session to which the transaction to be detected belongs in the time period corresponding to the maximum draining duration.

And receiving transaction draining priorities set by a user so as to drain transactions sequentially according to the transaction draining priorities.

In some possible implementations, the apparatus further includes:

and the recovery module is used for recovering the transaction to be detected when the transaction to be detected is drained.

In a third aspect, the present application provides a database node. The database node includes at least one processor and at least one memory. The at least one processor and the at least one memory are in communication with each other. The at least one memory has stored therein computer readable instructions, the at least one processor being configured to execute the computer readable instructions stored in the at least one memory to cause the database node to perform the transaction detection method as in the first aspect or any implementation of the first aspect.

In a fourth aspect, the present application provides a computer readable storage medium having stored therein instructions for instructing a database node to execute the transaction detection method according to the first aspect or any implementation manner of the first aspect.

In a fifth aspect, the present application provides a computer program product comprising instructions which, when run on a database node, cause the database node to perform the transaction detection method of the first aspect or any implementation of the first aspect.

Further combinations of the present application may be made to provide further implementations based on the implementations provided in the above aspects.

Drawings

In order to more clearly illustrate the technical method of the embodiments of the present application, the drawings used in the embodiments will be briefly described below.

FIG. 1 is a system architecture diagram of a transaction detection method according to an embodiment of the present application;

FIG. 2 is a schematic diagram of transaction detection according to an embodiment of the present application;

FIG. 3 is a flowchart of a transaction detection method according to an embodiment of the present application;

FIG. 4 is a schematic diagram of registration session mapping provided by an embodiment of the present application;

FIG. 5 is a schematic diagram of transaction detection according to an embodiment of the present application;

fig. 6 is a schematic structural diagram of a transaction detection device according to an embodiment of the present application;

fig. 7 is a schematic structural diagram of a source database node according to an embodiment of the present application.

Detailed Description

The terms "first", "second" in embodiments of the application are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defining "a first" or "a second" may explicitly or implicitly include one or more such feature.

Some technical terms related to the embodiments of the present application will be described first.

Application (APP), which is an abbreviation for application program (application program), specifically refers to a program written for some special application purpose for the user. For example, applications may include applications for different functions of a text processor, a form processor, a browser, a media player, an aviation flight simulator, a command line game, an image editor, an online store, a book management system, and so forth.

Some of these applications are database-based, such as online stores, book management systems, etc., applications typically connect database nodes (DB nodes) when running. Database nodes refer to nodes for deploying databases, and it should be noted that the databases may be deployed in a node, or in a cluster formed by a plurality of nodes. In the present application, a node may be a computing device such as a server or a terminal.

The database node can be connected with a plurality of clients of the application simultaneously to provide services for a plurality of users. For ease of management, session objects, i.e., sessions, may be created separately for each user on a database node. The session is used to save the communication information of an application (e.g., a client of the application) with a database node (also called a server), thereby enabling the database node to provide better services to the user based on the communication information.

In many scenarios, a switch is required for the database node to which the application is connected. For example, when the user scale is changed, for example, from 1000 users to 10 ten thousand users, the specifications of the database management system (Database Management Systems, DBMS) engine (which may also be simply referred to as a data engine) are also changed accordingly, and therefore, it is necessary to switch the database nodes to which the applications are connected. For another example, when an application makes a version change (e.g., a version upgrade), it is often necessary to switch the database node to which the application is connected to switch the application from the current version to the new version. In some cases, the application is further configured with a master-slave node to ensure high availability of the service (high availability, HA), wherein the master-slave node includes a master node and a slave node, and when the master node fails, the application may trigger the master-slave switching to switch the database node connected by the application from the master node to the slave node. In addition, in the cloud scene, the cloud native application is separated through storage calculation, so that the storage resource is elastically expandable, and based on the storage resource, the database nodes connected with the native application are required to be switched.

To meet the needs of the user, an application lossless transparent (Application Lossless Transparent, ALT) handoff is typically required. Lossless means that the transaction is not discarded and is not in an unknown state; key information of the session is not lost; ongoing operations or transactions can continue safely and reliably without losing any data and requiring traffic compensation. The transparency means that the service is not perceived and does not participate in the related process in the switching process.

ALT switching relies on draining transactions. Draining transactions refers to monitoring running transactions, and blocking operations on corresponding sessions when a certain execution site is reached, so as to lay a foundation for subsequent ALT switching. The execution site may be a site that may be blocked during execution of the transaction. Typically, the execution site may be a transaction boundary. For ease of understanding, the following description is provided in connection with an example. Assuming that a transaction includes operation a and operation B, after operation a and operation B are performed, the transaction arrives at the execution site.

Currently, the industry employs middleware connection retention enhancement techniques to implement drain transactions. The middleware may be software located between the application and the database node, which may be, for example, proxy or connector. For ease of description, the following is illustrated with proxy.

In particular, proxy maintains a front-end connection (proxy's connection to the application), monitors the execution of the transaction, intercepts structured query commands (Structured Query Language command, SQL command) for a period of time that characterize the final commit of the transaction in the session, and detects whether the transaction is drained. However, middleware such as proxy intercepts all SQL sentences and monitors each SQL sentence to judge whether the transaction is actually submitted or not, so that a large amount of resources are required to be consumed, and the performance of the service is affected.

In view of this, the embodiment of the application provides a transaction detection method. The method may be performed by a source database node. The source database node obtains the identification of the first session to which the transaction to be detected belongs, then queries a registration record according to the identification of the first session to which the transaction to be detected belongs to obtain a query result, the registration record stores the identification of the second session to which the transaction which does not reach the execution site belongs, and then the source database node obtains a transaction detection result used for representing whether the transaction to be detected is drained according to the query result.

In order to make the technical solution of the present application clearer, the system architecture of the embodiments of the present application is described below with reference to the accompanying drawings.

Referring to the system architecture diagram of the transaction detection method shown in fig. 1, an application 100 connects a source database node 301 through a routing node 200. The source database node 301 may be a server or a terminal, where the server may be a cloud server or a physical server, and the terminal includes, but is not limited to, a desktop, a notebook, a smart phone, and other devices. The routing node 200 may be a node where a proxy or connector is located. The routing node 200 is used to route connection requests to a backend, such as source database node 301.

A first session is created in source database node 301 for storing the communication information of application 100 with source database node 301 for better provision of services based on the communication information. For ease of description, source database Node 301 is denoted as X Node in fig. 1, and accordingly, the first Session in source database Node 301 may be denoted as Session Xn.

When the application 100 has a need for a node switch, a second session may be created at the destination database node 302. The destination database node 302 may be a server or a terminal. The destination database node 302 may be a configured node or a randomly allocated node. For ease of description, the destination database Node 302 is denoted as Y Node in fig. 1, and the second Session in the destination database Node 302 is denoted as Session Yn. It should be noted that, the first Session and the second Session are in one-to-one correspondence, such as Session X1< - > Session Y1, session X2< - > Session Y2, session X3< - > Session Y3.

In this embodiment, source database node 301 may drain transactions first to lay a foundation for ALT handoff. Source database node 301 may detect, among other things, whether a transaction is drained, and when a transaction is drained, source database node 301 may perform subsequent operations to implement an ALT handoff.

Referring to the transaction detection schematic shown in fig. 2, the source database node 301 may maintain a registration record, which in this example may be stored in particular in a data structure of a registration session map (registration session map). Wherein registration session map maintained by the X Node may be denoted as registration session map X. registration session map x has stored therein an identification of at least one second session to which a transaction that does not reach the execution site belongs. The source database Node 301 (for example, X Node in fig. 1) may obtain an identifier of a first session to which the transaction to be detected belongs, query the registration record to obtain a query result according to the identifier of the first session to which the transaction to be detected belongs, and then obtain a result for characterizing whether the transaction to be detected is to drain the transaction according to the query result.

As shown in fig. 2, the source database node 301 may store the identifiers of the session a, the session B, and the session C to registration session map x before the SQL command included in the transaction in the session a, the session B, and the session C is executed, thereby implementing registration of the session a, the session B, and the session C to registration session map x. The source database node 301 may detect whether the transaction is drained by the database engine DB kernel, such as by the database engine invoking the "drain transaction" component to monitor the execution status of the transaction in session a, session B, session C, and when the transaction in session a reaches the execution site, the identity of session a may be removed from registration session map x to deregister. Accordingly, source database node 301 may determine that Session A is drained, and that Session B and Session C are not drained, i.e., session A drain clean, session B, session C not drain clean, by querying the registration record.

When a transaction in session a reaches the execution site, the source database node 301 may block the transaction in session a and then hold the new transaction execution segment (e.g., the transaction in session B) for continued execution, and when the transaction in session B reaches the execution site, the source database node 301 may remove the identity of session B from registration session map x to deregister. Accordingly, source database node 301 may determine that session a, session B are drained, and that session C is not drained, i.e., session a, session B drain clean, session C not drain clean, by querying the registration record. Similarly, source database node 301 may block transactions in session B and then hold the new transaction execution fragment (e.g., transactions in session C) for continued execution, and when a transaction in session C reaches the execution site, source database node 301 may remove the identity of session C from registration session map x to deregister. Accordingly, source database node 301 may determine that session A, session B, and session C are all drained by querying the registration record.

The system architecture and the detection principle of the transaction detection method according to the embodiments of the present application are described above, and the flow of the transaction detection method is described in detail below with reference to the accompanying drawings.

Referring to the flow chart of the transaction detection method shown in fig. 3, the method comprises:

s302: the source database node 301 stores the identity of the session to registration session map before the SQL command included in the transaction in the session begins execution.

During execution of ALT handoff, source database node 301 may drain transactions and then perform session cloning to ensure that ALT handoff is successful. Draining transactions refers to monitoring running transactions, and blocking operations on a corresponding session when a certain execution site is reached. The execution site may also be referred to as an execution boundary, and may have one or more execution boundaries for a transaction.

To detect whether the transaction to be detected is drained, the source database node 301 may store the identity of the session to registration session map to register the session to registration session map before the SQL command included in the transaction in the session begins execution. Wherein registration session map is a specific implementation of registration record, in a possible implementation of the embodiment of the present application, source database node 301 may also implement registration by other manners, for example, source database node 301 may implement session registration by identifying a record session through a key value.

S304: the source database node 301 removes the identity of the session to which the transaction arriving at the execution site belongs from registration session map.

When a command included in a transaction in a session begins execution, source database node 301 may monitor the execution status of the transaction. When a transaction arrives at an execution site, source database node 301 may remove the identity of the session to which the transaction arriving at the execution site belongs from registration session map, thereby enabling de-registration.

The execution sites may include one or more of transaction boundaries, SQL command boundaries, and minimum sub-transaction boundaries, among others. Wherein the transaction boundary may also be referred to as a complete secure transaction boundary (security transaction boundary). A transaction is a logical unit in the execution of a database management system and consists of a finite sequence of database operations. The database operation sequence can be realized through SQL command.

Where the transaction typically begins with begin or start transaction and ends with end, where the pseudo code of the transaction is as follows:

“begin”/“start transaction”

data manipulation

commit/rollback

Lock table// direct adding table lock

unlock table

@autocommit＝0

dml/query table

commit

DDL

select GET_LOCK// user LOCK

select RELEASE_LOCK

end

In some embodiments, the transaction may also be a distributed transaction, such as an extended architecture (eXtended Architecture, XA) transaction. Wherein the pseudocode of the XA transaction is as follows:

XA START xid

Data manipulation

XA END xid

XA PREPARE xid

XA COMMIT xid/XA ROLLBACK xid

one command not in transaction block

normal query

dml in autocommit

In some cases, a transaction (e.g., a long transaction) may also call other transactions, the called transaction may be referred to as a child transaction, the transaction that calls the child transaction may be referred to as a parent transaction, and a parent transaction may call one or more child transactions. Before entering the child transaction, the parent transaction may establish a rollback point, also referred to as a save point, and then execute the child transaction. When child execution ends, parent may continue execution. When the child transaction rolls back, the parent transaction can roll back to the save point established before entering the child transaction, and huge overhead caused by all rollbacks is avoided.

In this embodiment, source database node 301 may be implemented to provide multi-level drain transaction capability by providing multiple levels of execution sites, thereby meeting the requirements of fast drain transaction for different transactions (e.g., short transactions or long transactions).

Further, the source database node 301 may also store an identification of the connection to which the session corresponds in registration session map. As shown in fig. 4, source database node 301 may maintain registration session map group, which registration session map group includes at least one registration session map, illustrated in fig. 4 as registration session map group including n registration session map. In this example, each registration session map can store an identification of M1 objects and an identification of the corresponding connection. For example, registration session map 1 can store the identifications of connections 1 to M1 and the identifications of the corresponding objects, where the identifications of connections 1 to M1 are denoted conn_id (X11) to conn_id (X1M 1).

Referring to the transaction detection diagram shown in fig. 5, the source database node 301 may modulo registration session map group based on the identity conn_id (Xab) of the connection of the current operational session, determining registration session map U. Before the SQL command included in the transaction begins execution in the session, the identity of the connection and the identity of the object, e.g., in the place [ Xab, session ID ], are placed in registration session map U. When the transaction reaches a certain execution site, the source database node 301 may remove the identity of the connection and the identity of the object, e.g., remove [ Xab, session ID ] from registration session map U.

It should be noted that, S302 to S304 are a specific implementation of maintaining the registration record by the source database node 301 in the embodiment of the present application, the transaction detection method of the embodiment of the present application may be performed without performing S302 to S304, for example, the source database node 301 may maintain the registration record in other manners.

S306: the source database node 301 obtains the identity of the session to which the transaction to be detected belongs.

The transaction to be detected may be a running transaction in a session created on source database node 301, subject to triggering an ALT handoff. Source database node 301 has created thereon one or more sessions, each of which may include one or more transactions. The source database node 301 determines the running transaction in the session as a transaction to be detected and obtains an identification of the session (which may also be referred to as a first session) to which the transaction to be detected belongs.

S308: the source database node 301 obtains a query result by querying registration session map according to the identifier of the session to which the transaction to be detected belongs. When the query result indicates that the identifier of the session to which the transaction to be detected belongs matches the identifier of the session in registration session map, executing S310; when the query result indicates that the identifier of the session to which the transaction to be detected belongs does not match the identifier of the session in registration session map, S312 is executed.

registration session map has recorded therein an identification of the session to which the transaction that did not reach the execution site belongs, for example an identification of at least one second session. Based on this, the source database node 301 may compare the identifier of the session to which the transaction to be detected belongs with the identifier of the session to which the transaction that does not reach the execution site in registration session map belongs, thereby implementing the query registration session map, and obtaining the query result. For ease of understanding, still referring to the example of fig. 5, the source database node 100 may look up the [ Xab, session ID ] in registration session map U to enable detection of whether the session arrived at the intended execution site during drain transaction.

In some possible implementations, the source database node 301 may also receive a maximum drain time period set by the user. The maximum Drain period may also be referred to as Drain_TRX_TIMEOUT. In some embodiments, the maximum draining duration may be determined according to the time of normal transaction execution, so that the success rate of the draining transaction may be ensured. Accordingly, the source database node 301 may query the registration record to obtain a query result according to the identifier of the first session to which the transaction to be detected belongs in the period corresponding to the maximum draining duration. For example, source database node 301 may set a timer, and may stop the drain transaction when the time of the timer reaches a maximum drain length. Wherein, the session without entering the execution site will be in the normal state of the system, without ALT protection, the session with the execution site will enter the next link of ALT.

S310 may be executed when the query result indicates that the identification of the session to which the transaction to be detected belongs matches the identification of the session to which the transaction that does not reach the execution site in registration session map belongs, i.e., the query is successful. S312 may be executed when the query result indicates that the identifier of the session to which the transaction to be detected belongs does not match the identifier of the session to which any transaction that does not reach the execution site belongs in registration session map, i.e., the query fails.

In other possible implementations, source database node 301 may also set transaction drain priorities so that transactions are sequentially drained according to the transaction drain priorities.

S310: the source database node 301 determines that the transaction detection result is that the transaction to be detected is not drained.

registration session map registers the session to which the transaction that did not reach the execution site belongs, and when the identifier of the session to which the transaction to be detected belongs matches the identifier of the session to which the transaction that did not reach the execution site at registration session map belongs, it is characterized that the transaction to be detected did not reach the execution site, and the transaction to be detected was not drained.

S312: the source database node 301 determines that the transaction detection result is a transaction drain to be detected.

Similarly, the session to which the transaction that did not reach the execution site is registered in registration session map, and when none of the identifiers of the session to which the transaction to be detected belongs and the session to which the transaction that did not reach the execution site in registration session map belongs match, the identifier of the session to which the transaction to be detected belongs is removed from registration session map, the transaction to be detected does not reach the execution site, and the transaction to be detected is not drained.

Further, the source database node 301 may also recover (recover) the transaction to be detected. The source database node 301 may set a Transaction-related log sequence number (log sequence number, LSN) to guide the recovery of the subsequent Transaction. It should be noted that, depending on the execution sites reached by the transaction to be detected, the source database node 301 may also select different ways to recover in combination with the type of the execution sites. For example, for the transaction to be detected reaching the transaction boundary, the cross-node recovery of the transaction to be detected is not needed, and for the transaction to be detected reaching the SQL command boundary or reaching the minimum sub-transaction boundary, the cross-node recovery of the transaction to be detected is performed.

In the embodiment of the present application, S310 and S312 are a specific implementation of obtaining the transaction detection result according to the query result, and in other possible implementations of the embodiment of the present application, the source database node 301 may obtain the transaction detection result in other manners.

Based on the above description, the embodiment of the application provides a transaction detection method. In the method, the operation of detecting whether the transaction is drained is sunk to the source database node 301 by middleware such as proxy, for example, a database engine DB Kernel in the source database node 301, and the source database node 301 inquires the registration record based on a session registration mechanism, so that whether the transaction is drained is quickly determined, complex and time-consuming SQL statement monitoring and execution state judgment are not required by middleware such as proxy or connector, a large amount of resource occupation is avoided, and the service performance is ensured. Accordingly, proxy and the like middleware can also realize lightweight.

Further, the method also provides a drain_time_out parameter setting for the user to select a possible click time that can be withstood by the user connection under drain transaction. In addition, the method provides a plurality of execution sites, realizes fine granularity drain transaction and meets the requirements of different services.

Based on the transaction detection method provided by the embodiment of the application, the embodiment of the application also provides a transaction detection device. The transaction detection device according to the embodiment of the present application will be described below with reference to the accompanying drawings.

Referring to the schematic structural diagram of the transaction detection device shown in fig. 6, the device 600 includes:

a communication module 602, configured to obtain an identifier of a first session to which a transaction to be detected belongs;

a query module 604, configured to query a registration record according to an identifier of a first session to which the transaction to be detected belongs, to obtain a query result, where the registration record stores an identifier of a second session to which the transaction that does not reach the execution site belongs;

and the detection module 606 is configured to obtain a transaction detection result according to the query result, where the transaction detection result is used to characterize whether the transaction to be detected is drained.

In some possible implementations, the detection module 606 is specifically configured to:

In some possible implementations, the apparatus 600 further includes:

the registration management module 608 is configured to store, before the obtaining the identifier of the first session to which the transaction to be detected belongs, the identifier of a third session, before the structured query SQL command included in the transaction starts to be executed, to the registration record, where the third session includes the at least one second session.

In some possible implementations, the registration management module 608 is further configured to:

In some possible implementations, the communication module 602 is further configured to:

receiving the maximum draining duration set by a user;

the query module 604 is specifically configured to:

In some possible implementations, the apparatus 600 further includes:

and the recovery module 609 is configured to recover the transaction to be detected when the transaction to be detected is drained.

The transaction detection device 600 according to the embodiment of the present application may correspond to performing the method described in the embodiment of the present application, and the above and other operations and/or functions of each module/unit of the transaction detection device 600 are respectively for implementing the corresponding flow of each method in the embodiment shown in fig. 6, which is not described herein for brevity.

The embodiment of the application also provides a database node. The database node may be a server or a terminal. The server may be a cloud server, or a physical server. Cloud servers are servers that support elastic scaling in a cloud environment, and physical servers are typically servers that do not support elastic scaling. Terminals include, but are not limited to, desktop, notebook, or smart phones. The database node may be used as a source database node 301 for implementing the functionality of the transaction detection arrangement 600 in the embodiment shown in fig. 6.

Fig. 7 provides a schematic diagram of a structure of a source database node 301, and as shown in fig. 7, the source database node 301 includes a bus 701, a processor 702, a communication interface 703, and a memory 704. Communication between processor 702, memory 704 and communication interface 703 is via bus 701.

Bus 701 may be a peripheral component interconnect standard (peripheral component interconnect, PCI) bus or an extended industry standard architecture (extended industry standard architecture, EISA) bus, among others. The buses may be divided into address buses, data buses, control buses, etc. For ease of illustration, only one thick line is shown in fig. 7, but not only one bus or one type of bus.

The processor 702 may be any one or more of a central processing unit (central processing unit, CPU), a graphics processor (graphics processing unit, GPU), a Microprocessor (MP), or a digital signal processor (digital signal processor, DSP).

The communication interface 703 is used for communication with the outside. For example, the communication interface 703 is used to obtain an identification of the first session to which the transaction to be detected belongs, or to receive a maximum draining period set by the user, or the like.

The memory 704 may include volatile memory (RAM), such as random access memory (random access memory). The memory 704 may also include a non-volatile memory (non-volatile memory), such as read-only memory (ROM), flash memory, hard Disk Drive (HDD), or solid state drive (solid state drive, SSD).

The memory 704 has stored therein computer readable instructions that are executed by the processor 702 to cause the source database node 301 to perform the transaction detection method (or to implement the functionality of the transaction detection device 600) described previously.

In particular, in the case where the embodiment of the apparatus shown in fig. 6 is implemented, and the functions of the modules of the transaction detection apparatus 600 described in fig. 6, such as the communication module 602, the query module 604, and the detection module 606, are implemented by software, software or program code required to perform the functions of the modules in fig. 6 may be stored in at least one memory 704 in the source database node 301. At least one processor 702 executes program code stored in memory 704 to cause source database node 301 to perform the transaction detection method described previously.

The embodiment of the application also provides a computer readable storage medium. The computer readable storage medium may be any available medium that source database node 301 can store or a data storage device such as a data center containing one or more available media. The usable medium may 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), etc. The computer readable storage medium includes instructions that instruct the source database node 301 to perform the transaction detection method described above.

The embodiment of the application also provides a computer program product. The computer program product includes one or more computer instructions. The processes or functions described in accordance with embodiments of the present application are all or partially developed when the computer instructions are loaded and executed on source database node 301. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from one website, computing device, or data center to another website, computing device, or data center by a wired (e.g., coaxial cable, fiber optic, digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer program product may be a software installation package that may be downloaded and executed on source database node 301 in the event that any of the previously described transaction detection methods are required.

The descriptions of the processes or structures corresponding to the drawings have emphasis, and the descriptions of other processes or structures may be referred to for the parts of a certain process or structure that are not described in detail.

Claims

1. A transaction detection method, the method comprising:

acquiring an identifier of a first session to which a transaction to be detected belongs;

inquiring a registration record according to the identification of the first session to which the transaction to be detected belongs to obtain an inquiry result, wherein the registration record stores the identification of the second session to which the transaction which does not reach the execution site belongs;

and obtaining a transaction detection result according to the query result, wherein the transaction detection result is used for representing whether the transaction to be detected is drained or not.

2. The method of claim 1, wherein obtaining a transaction detection result from the query result comprises:

3. The method according to claim 1 or 2, characterized in that before the obtaining of the identity of the first session to which the transaction to be detected belongs, the method further comprises:

before a structured query SQL command included in a transaction in a third session begins execution, storing an identification of the third session to the log record, the third session including the at least one second session.

4. A method according to claim 3, characterized in that the method further comprises:

5. The method of any one of claims 1 to 4, wherein the execution site comprises any one or more of:

6. The method according to any one of claims 1 to 5, further comprising:

receiving the maximum draining duration set by a user;

and inquiring the registration record according to the identifier of the first session to which the transaction to be detected belongs to obtain an inquiry result, wherein the inquiry result comprises the following steps:

7. The method according to any one of claims 1 to 5, further comprising:

8. The method according to any one of claims 1 to 7, further comprising:

and recovering the transaction to be detected when the transaction to be detected is drained.

9. A transaction detection device, the device comprising:

10. The apparatus of claim 9, wherein the detection module is specifically configured to:

11. The apparatus according to claim 9 or 10, characterized in that the apparatus further comprises:

and the registration management module is used for storing the identification of a third session to the registration record before the structured query SQL command included in the transaction in the third session starts to be executed, wherein the third session comprises the at least one second session.

12. The apparatus of claim 11, wherein the registration management module is further configured to:

13. The apparatus of any one of claims 9 to 12, wherein the execution site comprises any one or more of:

14. The apparatus of any one of claims 9 to 13, wherein the communication module is further configured to:

receiving the maximum draining duration set by a user;

the query module is specifically configured to:

15. The apparatus of any one of claims 9 to 14, wherein the communication module is further configured to:

16. The apparatus according to any one of claims 9 to 15, further comprising:

17. A database node, characterized in that it comprises at least one processor and at least one memory, said at least one memory having stored therein computer readable instructions, said at least one processor executing said computer readable instructions, causing said database node to perform the method according to any of claims 1 to 8.

18. A computer-readable storage medium comprising computer-readable instructions; the computer readable instructions are for implementing the method of any one of claims 1 to 8.

19. A computer program product comprising computer readable instructions; the computer readable instructions are for implementing the method of any one of claims 1 to 8.