Distributed database deadlock processing method and apparatus, device, and storage medium

Abstract

Disclosed in the present invention are a distributed database deadlock processing method and apparatus, a device, and a storage medium. The method comprises: receiving sparse waiting relation sets of single-machine transactions sent by single-machine databases; merging the sparse waiting relation sets of the single-machine transactions sent by the single-machine databases to obtain a sparse waiting relation set of a distributed transaction; performing loop detection on the basis of the sparse waiting relation set of the distributed transaction to obtain a loop set; and acquiring a target single-machine database address corresponding to a target waiting transaction in each loop in the loop set, and sending a distributed deadlock processing command to a target single-machine database on the basis of the target single-machine database address corresponding to the target waiting transaction in each loop, so that the target single-machine database executes the distributed deadlock processing command. By means of the technical solution of the present invention, distributed deadlock can be detected, and the distributed deadlock can be processed.

Description

A distributed database deadlock processing method, device, equipment and storage medium Technical Field

[0001] Embodiments of the present invention relate to the field of computer technology, and in particular to a distributed database deadlock processing method, apparatus, device, and storage medium. Background Art

[0002] Generally speaking, in a database, deadlock refers to a situation where transactions cannot proceed because they each hold a lock required by the other. For distributed databases, deadlocks include stand-alone deadlocks (i.e., deadlocks on a single database) and distributed deadlocks (deadlocks across multiple stand-alone databases).

[0003] For single-machine deadlock, the single-machine database already provides the ability to detect single-machine deadlock.

[0004] Standalone databases cannot detect distributed deadlocks. For example, a distributed deadlock occurs when standalone transaction A1 (on standalone database 1) of distributed transaction A is waiting for a lock held by standalone transaction B1 of distributed transaction B; while standalone transaction B2 of distributed transaction B (on standalone database 2) is waiting for a lock held by standalone transaction A2 of distributed transaction A. This is a typical distributed deadlock scenario, where distributed transactions A and B are waiting for each other's locks, but a standalone database cannot detect this deadlock. Summary of the Invention

[0005] The embodiments of the present invention provide a distributed database deadlock processing method, apparatus, device and storage medium, which can detect distributed deadlock and process the distributed deadlock.

[0006] According to one aspect of the present invention, a distributed database deadlock processing method is provided, comprising:

[0007] Receive a sparse waiting relationship set of stand-alone transactions sent by each stand-alone database, wherein the sparse waiting relationship set of the stand-alone transaction includes: a distributed transaction identifier to which the waiting transaction belongs, a distributed transaction identifier to which a waited transaction corresponding to the waiting transaction belongs, and an address of the stand-alone database corresponding to the waiting transaction;

[0008] Merge the sparse wait relationship sets of the stand-alone transactions sent by each stand-alone database to obtain the sparse wait relationship set of the distributed transaction;

[0009] Performing loop detection according to the sparse wait relationship set of the distributed transaction to obtain a loop set;

[0010] Obtain the target stand-alone database address corresponding to the target waiting transaction in each loop in the loop set, and send a distributed deadlock processing command to the target stand-alone database according to the target stand-alone database address corresponding to the target waiting transaction in each loop, so that the target stand-alone database executes the distributed deadlock processing command.

[0011] According to another aspect of the present invention, a distributed database deadlock processing method is provided, the distributed database deadlock processing method comprising:

[0012] Sending a sparse wait relationship set of a stand-alone transaction to the main gate, so that the main gate merges the sparse wait relationship sets of the stand-alone transactions sent by each stand-alone database to obtain a sparse wait relationship set of a distributed transaction, performing loop detection based on the sparse wait relationship set of the distributed transaction to obtain a loop set, obtaining the target stand-alone database address corresponding to the target wait transaction in each loop in the loop set, and sending a distributed deadlock processing command to the target stand-alone database according to the target stand-alone database address corresponding to the target wait transaction in each loop;

[0013] Receive the distributed deadlock processing command sent by the main Gate, and execute the distributed deadlock processing command.

[0014] According to another aspect of the present invention, a distributed database deadlock processing device is provided, the distributed database deadlock processing device comprising:

[0015] A sparse waiting relationship set receiving module for a stand-alone transaction is configured to receive a sparse waiting relationship set of a stand-alone transaction sent by each stand-alone database, wherein the sparse waiting relationship set of a stand-alone transaction includes: a distributed transaction identifier to which the waiting transaction belongs, a distributed transaction identifier to which a waited transaction corresponding to the waiting transaction belongs, and an address of the stand-alone database corresponding to the waiting transaction;

[0016] A sparse wait relationship set determination module for distributed transactions, configured to merge the sparse wait relationship sets of stand-alone transactions sent by each stand-alone database to obtain a sparse wait relationship set of distributed transactions;

[0017] A loop detection module, configured to perform loop detection based on the sparse wait relationship set of the distributed transaction to obtain a loop set;

[0018] The distributed deadlock processing module is used to obtain the target stand-alone database address corresponding to the target waiting transaction in each loop in the loop set, and send a distributed deadlock processing command to the target stand-alone database according to the target stand-alone database address corresponding to the target waiting transaction in each loop, so that the target stand-alone database executes the distributed deadlock processing command.

[0019] According to another aspect of the present invention, a distributed database deadlock processing device is provided, the distributed database deadlock processing device comprising:

[0020] The sparse waiting relationship set sending module of the stand-alone transaction is used to send the sparse waiting relationship set of the stand-alone transaction to the main gate, so that the main gate merges the sparse waiting relationship sets of the stand-alone transactions sent by each stand-alone database to obtain the sparse waiting relationship set of the distributed transaction, performs loop detection based on the sparse waiting relationship set of the distributed transaction to obtain a loop set, obtains the target stand-alone database address corresponding to the target waiting transaction in each loop in the loop set, and sends a distributed deadlock processing command to the target stand-alone database according to the target stand-alone database address corresponding to the target waiting transaction in each loop;

[0021] The distributed deadlock processing command receiving module is used to receive the distributed deadlock processing command sent by the main Gate and execute the distributed deadlock processing command.

[0022] According to another aspect of the present invention, an electronic device is provided, comprising:

[0023] at least one processor; and

[0024] a memory communicatively connected to the at least one processor; wherein,

[0025] The memory stores a computer program executable by the at least one processor. The computer program is executed by the at least one processor so that the at least one processor can execute the distributed database deadlock processing method according to any embodiment of the present invention.

[0026] According to another aspect of the present invention, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the distributed database deadlock processing method according to any embodiment of the present invention when executed.

[0027] The embodiment of the present invention receives a sparse wait relationship set of stand-alone transactions sent by each stand-alone database, wherein the sparse wait relationship set of the stand-alone transaction includes: a distributed transaction identifier to which the waiting transaction belongs, a distributed transaction identifier to which a waited transaction corresponding to the waiting transaction belongs, and a stand-alone database address corresponding to the waiting transaction; merges the sparse wait relationship sets of the stand-alone transactions sent by each stand-alone database to obtain a sparse wait relationship set of distributed transactions; performs loop detection based on the sparse wait relationship set of distributed transactions to obtain a loop set; obtains a target stand-alone database address corresponding to a target waiting transaction in each loop in the loop set, and sends a distributed deadlock processing command to the target stand-alone database based on the target stand-alone database address corresponding to the target waiting transaction in each loop, so that the target stand-alone database executes the distributed deadlock processing command. A distributed deadlock can be detected and processed.

[0028] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present invention, nor is it intended to limit the scope of the present invention. Other features of the present invention will become readily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments. It should be understood that the following drawings only illustrate certain embodiments of the present invention and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can be obtained based on these drawings without paying any creative work.

[0030] FIG1 is a flow chart of a distributed database deadlock processing method according to an embodiment of the present invention;

[0031] FIG2 is a flow chart of another distributed database deadlock processing method according to an embodiment of the present invention;

[0032] FIG3 is a schematic diagram of a distributed deadlock detection architecture according to an embodiment of the present invention;

[0033] FIG4 is a schematic structural diagram of a distributed database deadlock processing device according to an embodiment of the present invention;

[0034] 5 is a schematic structural diagram of another distributed database deadlock processing device in an embodiment of the present invention;

[0035] FIG6 is a schematic structural diagram of an electronic device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0036] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present invention.

[0037] It should be noted that the terms "first", "second", etc. in the description and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0038] It is understandable that before using the technical solutions disclosed in the various embodiments of this disclosure, the type, scope of use, usage scenarios, etc. of the personal information involved in this disclosure should be informed to the user and the user's authorization should be obtained in an appropriate manner in accordance with relevant laws and regulations.

[0039] Example 1

[0040] FIG1 is a flow chart of a distributed database deadlock handling method provided by an embodiment of the present invention. This embodiment is applicable to distributed database deadlock handling. The method can be executed by a distributed database deadlock handling device in an embodiment of the present invention. The device can be implemented in software and / or hardware. As shown in FIG1 , the method specifically includes the following steps:

[0041] S110: Receive a sparse wait relationship set of a stand-alone transaction sent by each stand-alone database.

[0042] The sparse waiting relationship set of the stand-alone transaction includes: a distributed transaction identifier to which the waiting transaction belongs, a distributed transaction identifier to which a waited transaction corresponding to the waiting transaction belongs, and a stand-alone database address corresponding to the waiting transaction.

[0043] Among them, the sparse waiting relationship set of the stand-alone transaction sent by the stand-alone database includes the distributed transaction identifiers of all waiting transactions in the waiting lock state in the stand-alone database, the distributed transaction identifier of a waited transaction corresponding to each waiting transaction, and the stand-alone database address corresponding to each waiting transaction.

[0044] It should be noted that the embodiment of the present invention is applied to a distributed database, which includes: a main Gate (Gate Leader), at least one sub-Gate (Gate Follower) and at least two stand-alone databases. Among them, the Gate is the entrance to the distributed database, which is mainly responsible for processing client requests and distributing requests to each stand-alone database, and is also responsible for controlling the execution process of distributed transactions. Distributed transactions will start stand-alone transactions on multiple stand-alone databases, that is, distributed transactions contain multiple stand-alone transactions. Stand-alone database: responsible for the storage of distributed database data. Each stand-alone database contains one master and multiple backups to ensure high availability of data. The Gate sends a request to the master of each stand-alone database, and all stand-alone database backups synchronize data with the master based on the Binlog of their master. The specific synchronization method is not limited. The Binlog is a logical log that records the SQL of the executed table structure changes or data modifications.

[0045] S120: Merge the sparse wait relationship sets of the stand-alone transactions sent by the stand-alone databases to obtain a sparse wait relationship set of the distributed transactions.

[0046] Wherein, the distributed transaction identifiers to which the waiting transactions in the sparse waiting relationship set of the distributed transactions belong are all different.

[0047] Specifically, the sparse wait relationship sets of stand-alone transactions sent by each stand-alone database are merged to obtain the sparse wait relationship set of distributed transactions. The main gate merges the sparse wait relationship sets relation_list of stand-alone transactions of all stand-alone databases, removes duplicates, and obtains the distributed transaction sparse wait relationship set global_relation_list.

[0048] Optionally, the sparse wait relationship sets of the stand-alone transactions sent by each stand-alone database are merged to obtain the sparse wait relationship set of the distributed transaction, including:

[0049] Merging the sparse wait relationship sets of the stand-alone transactions sent by each stand-alone database to obtain a first set;

[0050] Deduplication is performed on the first set to obtain a sparse waiting relationship set of distributed transactions.

[0051] Specifically, the first set can be deduplicated to obtain a sparse waiting relationship set of distributed transactions by traversing the relation_list of all stand-alone databases. For the current sparse waiting relationship relation, if there is no waiting_global_xid with relation in the global_relation_list, then the relation is inserted into the global_relation_list.

[0052] S130: Perform loop detection according to the sparse wait relationship set of the distributed transaction to obtain a loop set.

[0053] Specifically, loop detection is performed based on the sparse waiting relationship set of the distributed transaction, and the loop set can be obtained by: determining the distributed transaction identifier of any waiting transaction in the sparse waiting relationship set of the distributed transaction as the starting point, and deeply traversing the directed graph from the starting point to obtain the loop set.

[0054] In a specific example, loop detection includes the following process:

[0055] Find all loops circle_list based on global_relation_list. A loop refers to the edges of a directed graph formed by all relations in global_relation_list. The waiting_global_xid and blocking_global_xid of each relation are the starting point and end point of the edge respectively. Starting from a certain starting point, the directed graph is deeply traversed. If the starting point can be reached, then a loop is formed. The specific method is to traverse the starting points of all edges. For the current starting point start_node, perform the following operations:

[0056] a) If start_node has been marked, that is, color[start_node]>0, the color is a map that records whether a point in the directed graph has been traversed. Continue traversing to the next starting point, and the initial value is 0, which means it has not been traversed; otherwise, go to b)

[0057] b) Update the value of cur_color++ marked in this round. The initial value is 0. The cur_color is used to set the value of color[node] when marking whether the node has been traversed. If the values ​​of color[node1] and color[node2] are the same, it means that these two nodes are traversed in one deep traversal.

[0058] c) Set the current starting point cur_start_node to start_node, the end point of the directed edge where cur_start_node is located to cur_end_node, and start this depth traversal of the directed graph from cur_start_node

[0059] d) Determine whether cur_start_node has been marked:

[0060] If i is marked, that is, color[cur_start_node]>0: compare color[cur_start_node] with cur_color:

[0061] If they are equal, this indicates that the deep traversal started from cur_start_node and returned to cur_start_node. Add the edges (relation) traversed in this deep traversal to a set, which is a circle. If this circle is composed of multiple stand-alone databases, that is, the wait relations in the wait relation set do not come from a single stand-alone database, then add this circle to the result set circle_list. If this is a stand-alone deadlock, ignore the circle and only add the distributed deadlock to the result set. Continue traversing to the next starting point.

[0062] 2. Otherwise: It means that the depth traversal has reached a point that has been traversed in a previous depth traversal. Then stop the depth traversal and continue to traverse the next starting point.

[0063] ii Otherwise: This indicates that this point has never been traversed. Set color[cur_start_node] = cur_color, and then judge:

[0064] 1. If there is an edge starting from cur_end_node in the directed graph, that is, the depth traversal can continue, then set cur_start_node = cur_end_node, the end point of the directed edge where cur_start_node is located is cur_end_node, and continue this depth traversal to enter d);

[0065] 2. Otherwise, continue traversing to the next starting point.

[0066] S140, obtaining the target stand-alone database address corresponding to the target waiting transaction in each loop in the loop set, and sending a distributed deadlock processing command to the target stand-alone database according to the target stand-alone database address corresponding to the target waiting transaction in each loop, so that the target stand-alone database executes the distributed deadlock processing command.

[0067] The target waiting transaction may be any waiting transaction in the loop.

[0068] Specifically, a method for obtaining the target stand-alone database address corresponding to the target waiting transaction in each loop in the loop set may be: selecting the target waiting transaction in each loop in the loop set according to a selection strategy, and obtaining the target stand-alone database address corresponding to the target waiting transaction. The selection strategy may be selecting the waiting transaction with the smallest distributed transaction identifier to which the waiting transaction belongs, or may be selecting the waiting transaction with the least data, which is not limited in this embodiment of the present invention.

[0069] Specifically, the main gate obtains the target stand-alone database address corresponding to the target waiting transaction in each loop in the loop set, and the main gate sends a distributed deadlock processing command to the target stand-alone database according to the target stand-alone database address corresponding to the target waiting transaction in each loop, and the target stand-alone database executes the distributed deadlock processing command.

[0070] Optionally, obtain the target stand-alone database address corresponding to the target waiting transaction in each loop in the loop set, including:

[0071] Determine the distributed transaction to which the target waiting transaction in each loop in the loop set belongs as a victim distributed transaction;

[0072] Get the target stand-alone database address corresponding to the target waiting transaction in each loop in the loop set.

[0073] Specifically, the distributed transaction to which the target waiting transaction in each loop in the loop set belongs may be determined as the victim distributed transaction by selecting, according to a selection strategy, the waiting_global_xid in a waiting relation in the loop as the victim distributed transaction.

[0074] Optionally, the sparse waiting relationship set of the stand-alone transaction further includes: a connection identifier corresponding to the waiting transaction.

[0075] In a specific example, the master gate sends a sparse wait relationship query statement, relation_sql, to each stand-alone database to obtain a partial set of sparse transaction wait relationships, relation_rows. These rows contain the following columns: waiting_global_xid (the identifier of the distributed transaction to which the waiting transaction belongs), waiting_connection_id (the connection identifier corresponding to the waiting transaction), and blocking_global_xid (the identifier of the distributed transaction to which the waiting transaction belongs). The value of the waiting_global_xid column is different for each data row, meaning that each waiting transaction retains only one wait relationship. Based on relation_rows, a sparse wait relationship set, relation_list, for the stand-alone transaction is constructed.

[0076] The sparse waiting relationship set of the stand-alone transaction includes: waiting_global_xid (distributed transaction identifier to which the waiting transaction belongs), waiting_connection_id (connection identifier corresponding to the waiting transaction), blocking_global_xid (distributed transaction identifier to which the waited transaction belongs), and the stand-alone database address waiting_host corresponding to the waiting transaction.

[0077] The specific construction method is to traverse relation_rows. For each row of data in relation_rows, add the value of waiting_host to form a waiting relationship and add it to relation_list. The value of waiting_host is so that when the main gate obtains relation_rows, it knows which stand-alone database each row of data is obtained from. That is, the value of waiting_host is the address of the stand-alone database corresponding to the waiting transaction.

[0078] The technical solution of this embodiment is to receive a sparse waiting relationship set of stand-alone transactions sent by each stand-alone database, wherein the sparse waiting relationship set of the stand-alone transaction includes: a distributed transaction identifier to which the waiting transaction belongs, a distributed transaction identifier to which a waited transaction corresponding to the waiting transaction belongs, and a stand-alone database address corresponding to the waiting transaction; merge the sparse waiting relationship sets of the stand-alone transactions sent by each stand-alone database to obtain a sparse waiting relationship set of distributed transactions; perform loop detection based on the sparse waiting relationship set of the distributed transactions to obtain a loop set; obtain a target stand-alone database address corresponding to the target waiting transaction in each loop in the loop set, and send a distributed deadlock processing command to the target stand-alone database based on the target stand-alone database address corresponding to the target waiting transaction in each loop, so that the target stand-alone database executes the distributed deadlock processing command, thereby detecting and processing distributed deadlocks.

[0079] Example 2

[0080] FIG2 is a flow chart of a distributed database deadlock handling method provided by an embodiment of the present invention. This embodiment is applicable to distributed database deadlock handling. The method can be executed by a distributed database deadlock handling device in an embodiment of the present invention. The device can be implemented in software and / or hardware. As shown in FIG2 , the method specifically includes the following steps:

[0081] S210, sending a sparse waiting relationship set of a stand-alone transaction to the main Gate, so that the main Gate merges the sparse waiting relationship sets of the stand-alone transactions sent by each stand-alone database to obtain a sparse waiting relationship set of a distributed transaction, performing loop detection based on the sparse waiting relationship set of the distributed transaction to obtain a loop set, obtaining the target stand-alone database address corresponding to the target waiting transaction in each loop in the loop set, and sending a distributed deadlock processing command to the target stand-alone database according to the target stand-alone database address corresponding to the target waiting transaction in each loop.

[0082] It should be noted that the method for obtaining the sparse waiting relationship set of the stand-alone transaction sent by the stand-alone database to the main Gate is: the stand-alone database traverses all running transactions to obtain a transaction list, and generates a waiting transaction set based on the transactions in the transaction list that are in the waiting lock state; obtains a list of waited transactions corresponding to each waiting transaction in the waiting transaction set; and generates a sparse waiting relationship set based on the distributed transaction identifier of the target waited transaction in the waited transaction list, the distributed transaction identifier of the waiting transaction, and the stand-alone database address corresponding to the waiting transaction.

[0083] Optionally, before sending the sparse wait relationship set of a single-machine transaction to the main gate, the following is also included:

[0084] Generate a transaction list based on running transactions;

[0085] Generate a waiting transaction set according to the transactions in the transaction list that are in a waiting lock state;

[0086] Obtain a list of waited transactions corresponding to each waiting transaction in the waiting transaction set;

[0087] A sparse waiting relationship set is generated according to the distributed transaction identifier to which the target waited transaction in the waited transaction list belongs, the distributed transaction identifier to which the waiting transaction belongs, and the single-machine database address corresponding to the waiting transaction.

[0088] Specifically, the method of generating the waiting transaction set according to the transactions in the transaction list that are in the waiting lock state may be: obtaining the transactions in the transaction list that are in the waiting lock state, and generating the waiting transaction set according to the transactions in the transaction list that are in the waiting lock state.

[0089] Specifically, the method of generating a sparse waiting relationship set based on the distributed transaction identifier of the target waited transaction in the waited transaction list, the distributed transaction identifier of the waiting transaction, and the stand-alone database address corresponding to the waiting transaction can be: any waited transaction in the waited transaction list is determined as the target waited transaction, and a sparse waiting relationship set is generated based on the distributed transaction identifier of the target waited transaction, the distributed transaction identifier of the waiting transaction, and the stand-alone database address corresponding to the waiting transaction.

[0090] In a specific example, lock_waits_table maintains the latest and full transaction waiting relationships on a single-machine database. Each row of data in the table represents a waiting relationship, that is, a transaction is waiting for a lock owned by another transaction, and a transaction can wait for multiple transactions.

[0091] The running transaction waiting relationship table (lock_waits_table) is a system table of a stand-alone database, and the system table is an internal table of the stand-alone database.

[0092] The running transaction waiting relationship table mainly contains the following columns:

[0093] waiting_trx_id: waiting transaction ID

[0094] waiting_connection_id: waiting transaction user connection ID

[0095] waiting_query: waiting for the sql being executed by the transaction

[0096] blocking_trx_id: waiting transaction identifier

[0097] The embodiment of the present invention makes structural changes to the waiting relationship table of running transactions, adding the following columns:

[0098] waiting_global_xid: the distributed transaction identifier to which the waiting transaction belongs

[0099] blocking_global_xid: The distributed transaction identifier to which the waiting transaction belongs.

[0100] The distributed transaction ID (global_xid) is a globally unique identifier for distributed transactions. It is generated by Gate and sent to a stand-alone database when a stand-alone transaction is started. There is no restriction on the sending method. That is, stand-alone transactions sent by distributed transactions to multiple stand-alone databases have the same global_xid.

[0101] Each time the lock_waits_table is queried, the standalone database first clears the data in the lock_waits_table and then builds the latest and full transaction wait relationship data according to the following main process:

[0102] The stand-alone database traverses the transaction list trx_list (the transaction list includes all running transactions in the stand-alone database). The maintenance method of the trx_list is not limited. The following operations are performed on the current transaction cur_trx:

[0103] A. If cur_trx is waiting for a lock, then go to B; otherwise, continue to traverse the next transaction.

[0104] B. Find all transactions blocking_trx_list that cur_trx is waiting for. The method for finding blocking_trx_list is not limited. Traverse blocking_trx_list and perform the following operations on the current waiting transaction blocking_trx:

[0105] Construct row data row, waiting_connection_id (connection identifier corresponding to the waiting transaction), waiting_query (SQL being executed by the waiting transaction), blocking_global_xid (distributed transaction identifier of the waiting transaction corresponding to the waiting transaction), waiting transaction identifier, waiting transaction identifier, and distributed transaction identifier of the waiting transaction.

[0106] Insert row into lock_waits_table.

[0107] S220: Receive a distributed deadlock processing command sent by the master Gate, and execute the distributed deadlock processing command.

[0108] Specifically, the method of receiving the distributed deadlock processing command sent by the main Gate and executing the distributed deadlock processing command can be: receiving the distributed deadlock processing command sent by the main Gate, wherein the distributed deadlock processing command includes: the distributed transaction identifier to which the target waiting transaction belongs and the connection identifier corresponding to the target waiting transaction; traversing all connections of the current stand-alone database, obtaining the target connection whose connection identifier is the connection identifier corresponding to the target waiting transaction; if the target connection is running a transaction, the distributed transaction identifier to which the running transaction belongs is the same as the distributed transaction identifier to which the target waiting transaction belongs, and the running transaction is in a waiting lock state, then stopping the waiting lock and rolling back the running transaction. After the rollback is successful, returning the deadlock error to the main Gate, and the main Gate returns the deadlock error to the client.

[0109] In a specific example, after the Gate Leader detects all loops in circle_list, it performs distributed deadlock processing on each loop. The main process is as follows:

[0110] Traverse circle_list and perform the following operations on the current circle:

[0111] According to the selection strategy, a waiting relation in the circle is selected as the sacrificial distributed transaction with waiting_global_xid. The selection strategy is not limited, and the waiting relation with the smallest waiting_global_xid can be selected.

[0112] Get the waiting_host in the relation, that is, the stand-alone database address corresponding to the waiting transaction.

[0113] Send a distributed deadlock handling command to the stand-alone database represented by waiting_host. The syntax of the distributed deadlock handling command is not limited, but it must include waiting_global_xid and waiting_connection_id in the parameter relation.

[0114] In another specific example, as shown in Figure 3, a distributed database includes: a Gate Leader, at least one Gate Follower, and at least two stand-alone databases. The Gate Leader periodically obtains a sparse transaction wait relationship set for stand-alone transactions from all stand-alone databases. For the purposes of high availability and load balancing, a client can select any Gate to initiate a distributed transaction, and only the Gate Leader will execute the distributed deadlock detection process. The Gate Leader detects distributed deadlocks based on the sparse transaction wait relationship sets of stand-alone transactions sent by all stand-alone databases. If a distributed deadlock is detected, a victim distributed transaction is selected based on a selection strategy. The selection strategy is not limited here, but it must ensure idempotence, that is, the same victim distributed transaction is selected each time using this selection strategy. The victim distributed transaction is the distributed transaction to be rolled back. Among the multiple distributed transactions that constitute a distributed deadlock, one must be rolled back so that the other distributed transactions can end their wait locks and continue execution. The Gate Leader sends a distributed deadlock handling command to the stand-alone database where the waiting transaction is the wait relationship of the victim distributed transaction. When a standalone database receives a distributed deadlock handling command, it rolls back the standalone transaction of the sacrificial distributed transaction on that standalone database and returns a deadlock error to the Gate that initiated the sacrificial distributed transaction. Upon receiving the deadlock error, the Gate that initiated the sacrificial distributed transaction sends a rollback command to the other standalone databases. After successfully rolling back all standalone transactions, it returns a deadlock error to the client.

[0115] Optionally, receiving a distributed deadlock processing command sent by the master Gate and executing the distributed deadlock processing command includes:

[0116] Receive a distributed deadlock processing command sent by the main Gate, wherein the distributed deadlock processing command includes: a distributed transaction identifier to which the target waiting transaction belongs and a connection identifier corresponding to the target waiting transaction;

[0117] Traversing all connections of the current stand-alone database to obtain a target connection whose connection identifier is the connection identifier corresponding to the target waiting transaction;

[0118] If the target connection is running a transaction, the distributed transaction identifier of the running transaction is the same as the distributed transaction identifier of the target waiting transaction, and the running transaction is in the waiting lock state, then stop waiting for the lock and roll back the running transaction;

[0119] Sending a deadlock error to a target gate corresponding to the target connection, so that after receiving the deadlock error, if the distributed transaction to which the running transaction belongs has a stand-alone transaction on another stand-alone database, the target gate rolls back the stand-alone transaction on the other stand-alone database of the distributed transaction to which the running transaction belongs;

[0120] A deadlock error is sent to a client corresponding to the distributed transaction to which the running transaction belongs.

[0121] In a specific example, a stand-alone database receives a distributed deadlock handling command. The main execution process is as follows:

[0122] Traverse all connections and find the connection waiting_connection whose connection identifier is waiting_connection_id, that is, find the connection where the transaction to be rolled back is located.

[0123] If the waiting_connection is currently running a transaction whose global_xid is the waiting_global_xid and is waiting for a lock, the wait for the lock is stopped, the transaction is rolled back, and a deadlock error is returned to the Gate connected to the waiting_connection. Upon receiving the deadlock error, the Gate proactively rolls back the distributed transaction on the other standalone database and returns a deadlock error to the client, which is the user who initiated the distributed transaction.

[0124] It should be noted that if the distributed transaction to which the running transaction belongs already has a standalone transaction on another standalone database, the Gate that initiated the sacrificial distributed transaction will receive a deadlock error and send a rollback command to the other standalone database. If the distributed transaction to which the running transaction belongs does not already have a standalone transaction on another standalone database, this step is not required.

[0125] The technical solution of this embodiment is to send a sparse waiting relationship set of stand-alone transactions to the main Gate so that the main Gate merges the sparse waiting relationship sets of stand-alone transactions sent by each stand-alone database to obtain a sparse waiting relationship set of distributed transactions, perform loop detection based on the sparse waiting relationship set of distributed transactions to obtain a loop set, obtain the target stand-alone database address corresponding to the target waiting transaction in each loop in the loop set, and send a distributed deadlock processing command to the target stand-alone database according to the target stand-alone database address corresponding to the target waiting transaction in each loop; receive the distributed deadlock processing command sent by the main Gate, and execute the distributed deadlock processing command, so as to detect distributed deadlocks and process them.

[0126] Example 3

[0127] FIG4 is a schematic diagram of the structure of a distributed database deadlock handling device provided in an embodiment of the present invention. This embodiment is applicable to distributed database deadlock handling situations. The device can be implemented using software and / or hardware and can be integrated into any device that provides distributed database deadlock handling capabilities. As shown in FIG4 , the distributed database deadlock handling device specifically includes: a sparse wait relationship set receiving module 410 for standalone transactions, a sparse wait relationship set determination module 420 for distributed transactions, a loop detection module 430, and a distributed deadlock handling module 440.

[0128] The sparse waiting relationship set receiving module of the stand-alone transaction is used to receive the sparse waiting relationship set of the stand-alone transaction sent by each stand-alone database, wherein the sparse waiting relationship set of the stand-alone transaction includes: the distributed transaction identifier to which the waiting transaction belongs, the distributed transaction identifier to which a waited transaction corresponding to the waiting transaction belongs, and the stand-alone database address corresponding to the waiting transaction;

[0129] A sparse wait relationship set determination module for distributed transactions, configured to merge the sparse wait relationship sets of stand-alone transactions sent by each stand-alone database to obtain a sparse wait relationship set of distributed transactions;

[0130] A loop detection module, configured to perform loop detection based on the sparse wait relationship set of the distributed transaction to obtain a loop set;

[0131] The distributed deadlock processing module is used to obtain the target stand-alone database address corresponding to the target waiting transaction in each loop in the loop set, and send a distributed deadlock processing command to the target stand-alone database according to the target stand-alone database address corresponding to the target waiting transaction in each loop, so that the target stand-alone database executes the distributed deadlock processing command.

[0132] The above-mentioned product can execute the method provided by any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0133] Example 4

[0134] FIG5 is a schematic diagram of the structure of a distributed database deadlock handling device provided in an embodiment of the present invention. This embodiment is applicable to distributed database deadlock handling situations. The device can be implemented using software and / or hardware and can be integrated into any device that provides distributed database deadlock handling capabilities. As shown in FIG5 , the distributed database deadlock handling device specifically includes: a sparse wait relationship set sending module 510 for a single-machine transaction and a distributed deadlock handling command receiving module 520.

[0135] Among them, the sparse waiting relationship set sending module of the stand-alone transaction is used to send the sparse waiting relationship set of the stand-alone transaction to the main gate, so that the main gate merges the sparse waiting relationship sets of the stand-alone transactions sent by each stand-alone database to obtain the sparse waiting relationship set of the distributed transaction, performs loop detection based on the sparse waiting relationship set of the distributed transaction to obtain a loop set, obtains the target stand-alone database address corresponding to the target waiting transaction in each loop in the loop set, and sends a distributed deadlock processing command to the target stand-alone database according to the target stand-alone database address corresponding to the target waiting transaction in each loop;

[0136] The distributed deadlock processing command receiving module is used to receive the distributed deadlock processing command sent by the main Gate and execute the distributed deadlock processing command.

[0137] The above-mentioned product can execute the method provided by any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0138] Example 5

[0139] FIG6 shows a block diagram of an electronic device 10 that can be used to implement an embodiment of the present invention. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices (such as helmets, glasses, watches, etc.) and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present invention described and / or required herein.

[0140] As shown in FIG6 , the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 and a random access memory (RAM) 13, that is communicatively connected to the at least one processor 11. The memory stores a computer program that can be executed by the at least one processor, and the processor 11 can perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 12 or the computer program loaded from the storage unit 18 into the random access memory (RAM) 13. Various programs and data required for the operation of the electronic device 10 can also be stored in the RAM 13. The processor 11, ROM 12, and RAM 13 are connected to each other via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0141] Multiple components in the electronic device 10 are connected to the I / O interface 15, including an input unit 16, such as a keyboard, a mouse, etc.; an output unit 17, such as various types of displays, speakers, etc.; a storage unit 18, such as a magnetic disk, an optical disk, etc.; and a communication unit 19, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 19 allows the electronic device 10 to exchange information / data with other devices via a computer network such as the Internet and / or various telecommunication networks.

[0142] The processor 11 can be any general-purpose and / or specialized processing component with processing and computing capabilities. Some examples of the processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various specialized artificial intelligence (AI) computing chips, various processors that run machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The processor 11 executes the various methods and processes described above, such as the distributed database deadlock handling method.

[0143] In some embodiments, the distributed database deadlock handling method can be implemented as a computer program, which is tangibly contained in a computer-readable storage medium, such as the storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 10 via the ROM 12 and / or the communication unit 19. When the computer program is loaded into the RAM 13 and executed by the processor 11, one or more steps of the distributed database deadlock handling method described above can be performed. Alternatively, in other embodiments, the processor 11 can be configured to execute the distributed database deadlock handling method in any other appropriate manner (e.g., by means of firmware).

[0144] Various embodiments of the systems and techniques described herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), system-on-chip systems (SOCs), programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include being implemented in one or more computer programs that are executable and / or interpreted on a programmable system that includes at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0145] Computer programs for implementing the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when the computer program is executed by the processor, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The computer program may be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0146] In the context of the present invention, computer-readable storage media can be tangible media that can contain or store a computer program for use with an instruction execution system, device or equipment or used in combination with an instruction execution system, device or equipment. Computer-readable storage media can include but are not limited to electronic, magnetic, optical, electromagnetic, infrared or semiconductor systems, devices or equipment, or any suitable combination of the foregoing. Alternatively, computer-readable storage media can be machine-readable signal media. More specific examples of machine-readable storage media can include electrical connections based on one or more lines, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), optical fibers, portable compact disk read-only memories (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0147] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, voice input, or tactile input).

[0148] The systems and techniques described herein can be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.

[0149] A computing system may include clients and servers. The clients and servers are typically remote from each other and typically interact via a communication network. This client-server relationship arises through computer programs running on the respective computers, creating a client-server relationship. The server may be a cloud server, also known as a cloud computing server or cloud host. This server is a hosting product within the cloud computing service ecosystem that addresses the management difficulties and limited scalability of traditional physical hosting and VPS services.

[0150] It should be understood that the various forms of the processes shown above can be used to reorder, add, or delete steps. For example, the steps described in the present invention can be performed in parallel, sequentially, or in a different order, as long as the desired results of the technical solution of the present invention can be achieved. This is not limited herein.

[0151] The above specific embodiments do not limit the scope of protection of the present invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions may be made based on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention are intended to be included within the scope of protection of the present invention.

Claims

1. A method for handling deadlocks in a distributed database, characterized in that Applied to a distributed database, the distributed database includes: a main Gate, at least one secondary Gate, and at least two single-machine databases. The distributed database deadlock detection method is executed by the main Gate, and the distributed database deadlock detection method includes: Receiving a sparse waiting relationship set of single-machine transactions sent by each single-machine database, where the sparse waiting relationship set of the single-machine transactions includes: the distributed transaction identifier to which the waiting transaction belongs, the distributed transaction identifier to which a waiting transaction corresponding to the waiting transaction belongs, and the address of the single-machine database corresponding to the waiting transaction; Merging the sparse waiting relationship sets of single-machine transactions sent by each single-machine database to obtain a sparse waiting relationship set of distributed transactions; Performing loop detection based on the sparse waiting relationship set of the distributed transactions to obtain a loop set; Obtaining the address of the target single-machine database corresponding to the target waiting transaction in each loop in the loop set, and sending a distributed deadlock handling command to the target single-machine database according to the address of the target single-machine database corresponding to the target waiting transaction in each loop, so that the target single-machine database executes the distributed deadlock handling command.

2. The method according to claim 1, wherein Merging the sparse waiting relationship sets of single-machine transactions sent by each single-machine database to obtain a sparse waiting relationship set of distributed transactions, including: Merging the sparse waiting relationship sets of single-machine transactions sent by each single-machine database to obtain a first set; Removing duplicates from the first set to obtain a sparse waiting relationship set of distributed transactions.

3. The method according to claim 1, wherein Obtaining the address of the target single-machine database corresponding to the target waiting transaction in each loop in the loop set, including: Determining the distributed transaction to which the target waiting transaction in each loop in the loop set belongs as the sacrificed distributed transaction; Obtaining the address of the target single-machine database corresponding to the target waiting transaction in each loop in the loop set.

4. The method according to claim 1, wherein The sparse waiting relationship set of the single-machine transactions further includes: the connection identifier corresponding to the waiting transaction.

5. A method for handling deadlocks in a distributed database, characterized in that, Applied to a distributed database, the distributed database includes: a main Gate, at least one secondary Gate, and at least two single-machine databases. The distributed database deadlock detection method is executed by the single-machine database, and the distributed database deadlock detection method includes: Sending a sparse waiting relationship set of single-machine transactions to the main Gate, so that the main Gate merges the sparse waiting relationship sets of single-machine transactions sent by each single-machine database to obtain a sparse waiting relationship set of distributed transactions, performs loop detection based on the sparse waiting relationship set of the distributed transactions to obtain a loop set, obtains the address of the target single-machine database corresponding to the target waiting transaction in each loop in the loop set, and sends a distributed deadlock handling command to the target single-machine database according to the address of the target single-machine database corresponding to the target waiting transaction in each loop; Receiving the distributed deadlock handling command sent by the main Gate and executing the distributed deadlock handling command.

6. The method according to claim 5, wherein Receiving the distributed deadlock handling command sent by the main Gate and executing the distributed deadlock handling command, including: Receive the distributed deadlock handling command sent by the master Gate, where the distributed deadlock handling command includes: the distributed transaction identifier of the target waiting transaction and the connection identifier corresponding to the target waiting transaction; Traverse all connections of the current single-machine database to obtain a target connection with a connection identifier that is the connection identifier corresponding to the target waiting transaction; If the target connection is running a transaction, the distributed transaction identifier of the running transaction is the same as the distributed transaction identifier of the target waiting transaction, and the running transaction is in a waiting-for-lock state, then stop waiting for the lock and roll back the running transaction; Send the deadlock error to the target Gate corresponding to the target connection, so that after the target Gate receives the deadlock error, if there is a single-machine transaction of the distributed transaction to which the running transaction belongs on other single-machine databases, the target Gate rolls back the single-machine transaction of the distributed transaction to which the running transaction belongs on other single-machine databases; Send the deadlock error to the client corresponding to the distributed transaction to which the running transaction belongs.

7. The method according to claim 5, wherein Before sending the sparse waiting relationship set of the single-machine transaction to the master Gate, it further includes: Generate a transaction list according to the running transactions; Generate a waiting transaction set according to the transactions in the waiting-for-lock state in the transaction list; Obtain the list of waited-for transactions corresponding to each waiting transaction in the waiting transaction set; Generate a sparse waiting relationship set according to the distributed transaction identifier of the target waited-for transaction, the distributed transaction identifier of the waiting transaction, and the address of the single-machine database corresponding to the waiting transaction in the list of waited-for transactions.

8. A distributed database deadlock handling device, characterized in that, Applied to a distributed database, the distributed database includes: a master Gate, at least one slave Gate, and at least two single-machine databases. The distributed database deadlock detection device is configured in the master Gate, and the distributed database deadlock detection device includes: A sparse waiting relationship set receiving module for single-machine transactions, which is used to receive the sparse waiting relationship sets of single-machine transactions sent by each single-machine database, where the sparse waiting relationship set of the single-machine transaction includes: the distributed transaction identifier of the waiting transaction, the distributed transaction identifier of a waited-for transaction corresponding to the waiting transaction, and the address of the single-machine database corresponding to the waiting transaction; A sparse waiting relationship set determination module for distributed transactions, which is used to merge the sparse waiting relationship sets of single-machine transactions sent by each single-machine database to obtain a sparse waiting relationship set for distributed transactions; A loop detection module, which is used to perform loop detection according to the sparse waiting relationship set of the distributed transaction to obtain a loop set; A distributed deadlock handling module, which is used to obtain the target single-machine database address corresponding to the target waiting transaction in each loop in the loop set, and send a distributed deadlock handling command to the target single-machine database according to the target single-machine database address corresponding to the target waiting transaction in each loop, so that the target single-machine database executes the distributed deadlock handling command.

9. A distributed database deadlock handling device, characterized in that, Applied to a distributed database, the distributed database includes: a main Gate, at least one secondary Gate, and at least two single-machine databases. The distributed database deadlock detection device is configured in the single-machine database, and the distributed database deadlock detection device includes: A sparse waiting relationship set sending module for a single-machine transaction, which is used to send the sparse waiting relationship set of the single-machine transaction to the main Gate, so that the main Gate merges the sparse waiting relationship sets of the single-machine transactions sent by each single-machine database to obtain the sparse waiting relationship set of the distributed transaction, performs loop detection according to the sparse waiting relationship set of the distributed transaction to obtain a loop set, obtains the target single-machine database address corresponding to the target waiting transaction in each loop in the loop set, and sends a distributed deadlock handling command to the target single-machine database according to the target single-machine database address corresponding to the target waiting transaction in each loop; A distributed deadlock handling command receiving module, which is used to receive the distributed deadlock handling command sent by the main Gate and execute the distributed deadlock handling command.

10. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program executable by the at least one processor. The computer program is executed by the at least one processor so that the at least one processor can execute the distributed database deadlock handling method according to any one of claims 1-7.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions, and the computer instructions are used to implement the distributed database deadlock handling method according to any one of claims 1-7 when executed by a processor.

Images