CN116974775A - Deadlock detection method, device, computer equipment and storage medium - Google Patents

Deadlock detection method, device, computer equipment and storage medium Download PDF

Info

Publication number
CN116974775A
CN116974775A CN202310641177.9A CN202310641177A CN116974775A CN 116974775 A CN116974775 A CN 116974775A CN 202310641177 A CN202310641177 A CN 202310641177A CN 116974775 A CN116974775 A CN 116974775A
Authority
CN
China
Prior art keywords
local
waiting
transaction
global
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310641177.9A
Other languages
Chinese (zh)
Inventor
石志林
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN202310641177.9A priority Critical patent/CN116974775A/en
Publication of CN116974775A publication Critical patent/CN116974775A/en
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/52Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • G06F9/524Deadlock detection or avoidance
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25Integrating or interfacing systems involving database management systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor

Abstract

The application relates to a deadlock detection method, a device, a computer apparatus, a storage medium and a computer program product. The method relates to artificial intelligence technology, comprising: filtering the object lock waiting information associated with the global non-waiting transaction of the non-waiting object lock from the local waiting information of each of at least two database nodes to obtain the local waiting information after global updating; for each piece of globally updated local waiting information, when the object lock support held by the local non-waiting transaction in the globally updated local waiting information is pre-released, filtering the object lock waiting information associated with the local non-waiting transaction from the globally updated local waiting information to obtain the locally updated local waiting information; and carrying out global deadlock detection on the basis of the local waiting information after each local update to obtain a global deadlock detection result. By adopting the method, the accuracy of deadlock detection can be improved, and the normal operation of database resource scheduling can be ensured.

Description

Deadlock detection method, device, computer equipment and storage medium
Technical Field
The present application relates to the field of computer technology, and in particular, to a deadlock detection method, apparatus, computer device, storage medium, and computer program product.
Background
With the development of computer technology, various data such as game progress data, transaction data, log data, and the like are increasing in medical, game, advertisement, shopping, and the like. With the business requirements of efficient processing and analysis of various mass data, a distributed data system is widely applied, and the distributed data system supports large-scale parallel data processing, including various processing such as data query, deletion, addition and update.
At present, the accuracy of deadlock detection is low in the process of processing high-concurrency data processing transactions by a distributed data system, and the deadlock is difficult to discover in time, so that the normal operation of data processing is influenced.
Disclosure of Invention
Based on this, it is necessary to provide a deadlock detection method, an apparatus, a computer device, a computer readable storage medium and a computer program product capable of improving the accuracy of the deadlock detection, in view of the above technical problems.
In a first aspect, the present application provides a deadlock detection method. The method comprises the following steps:
acquiring local waiting information of each of at least two database nodes; each local wait information includes object lock wait information between transactions in the affiliated database node;
Filtering the object lock waiting information associated with the global non-waiting transaction from the local waiting information to obtain the local waiting information after global updating; globally non-waiting transactions, which are transactions that do not wait for an object lock in at least two database nodes;
for each piece of globally updated local waiting information, when the object lock support held by the local non-waiting transaction in the globally updated local waiting information is pre-released, filtering the object lock waiting information associated with the local non-waiting transaction from the globally updated local waiting information to obtain the locally updated local waiting information; the local non-waiting transaction is a transaction which does not wait for an object lock in a database node to which the global updated local waiting information belongs;
and performing global deadlock detection on at least two database nodes based on the local waiting information after each local update to obtain a global deadlock detection result.
In a second aspect, the application further provides a deadlock detection device. The device comprises:
the local waiting information acquisition module is used for acquiring the local waiting information of each of at least two database nodes; each local wait information includes object lock wait information between transactions in the affiliated database node;
The global updating module is used for filtering the object lock waiting information associated with the global non-waiting transaction from the local waiting information to obtain the local waiting information after global updating; globally non-waiting transactions, which are transactions that do not wait for an object lock in at least two database nodes;
the local updating module is used for aiming at each piece of globally updated local waiting information, when the object lock support held by the local non-waiting transaction in the aimed globally updated local waiting information is released in advance, filtering the object lock waiting information associated with the local non-waiting transaction from the globally updated local waiting information, and obtaining the locally updated local waiting information; the local non-waiting transaction is a transaction which does not wait for an object lock in a database node to which the global updated local waiting information belongs;
and the waiting information processing module is used for carrying out global deadlock detection on at least two database nodes based on the local waiting information after each local update to obtain a global deadlock detection result.
In a third aspect, the present application also provides a computer device. The computer device comprises a memory and a processor, wherein the memory stores a computer program, and the processor realizes the steps of the deadlock detection method when executing the computer program.
In a fourth aspect, the present application also provides a computer-readable storage medium. The computer readable storage medium has stored thereon a computer program which, when executed by a processor, implements the steps of the deadlock detection method described above.
In a fifth aspect, the present application also provides a computer program product. The computer program product comprises a computer program which, when executed by a processor, implements the steps of the deadlock detection method described above.
According to the deadlock detection method, the device, the computer equipment, the storage medium and the computer program product, the object lock waiting information associated with the global non-waiting transaction of the object lock in at least two database nodes is filtered out from the local waiting information of each of the at least two database nodes, the local non-waiting transaction which is not waiting for the object lock in the database node to which the global updated local waiting information belongs and is held is determined according to each piece of global updated local waiting information, the object lock waiting information associated with the local non-waiting transaction is filtered out, the local updated local waiting information is obtained, and the global deadlock detection is carried out on the at least two database nodes based on the local waiting information after each local update. In the deadlock detection processing process, object lock waiting information of transactions which do not wait for an object lock in the global database node is filtered, the object lock waiting information of transactions which do not wait for the object lock in the local database node is further filtered, the global object lock waiting information of the database node can be effectively simplified, information interference of deadlock detection is reduced, global deadlock detection is carried out through the simplified object lock waiting information, and accuracy of deadlock detection can be improved.
Drawings
FIG. 1 is an application environment diagram of a deadlock detection method in one embodiment;
FIG. 2 is a flow diagram of a method of deadlock detection in one embodiment;
FIG. 3 is a flow diagram of global updates in one embodiment;
FIG. 4 is a schematic diagram of a global wait diagram in one embodiment;
FIG. 5 is a diagram of a global wait diagram in another embodiment;
FIG. 6 is a schematic diagram of two transactions creating a deadlock in one embodiment;
FIG. 7 is a diagram of four transactions deadlock in one embodiment;
FIG. 8 is a schematic diagram of three transactional execution in one embodiment;
FIG. 9 is a schematic diagram of a deadlock detection process in the embodiment shown in FIG. 8;
FIG. 10 is a block diagram of the structure of a deadlock detection device in one embodiment;
FIG. 11 is an internal block diagram of a computer device in one embodiment.
Detailed Description
The present application will be described in further detail with reference to the drawings and examples, in order to make the objects, technical solutions and advantages of the present application more apparent. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the application.
The deadlock detection method provided by the embodiment of the application can be applied to an application environment shown in fig. 1. Wherein the terminal 102 communicates with a plurality of database nodes 104 via a network, the data storage system may store data that the database nodes 104 need to process. The data storage system may be integrated on the database node 104 or may be located on a cloud or other server. The database node 104 may specifically be used as a database server in a distributed database system to store data as a segment of a database, and the terminal 102 may trigger data processing from different database nodes 104 as required, such as performing various processes of data query, data addition, data deletion, and the like. The terminal 102 communicates with the server 106 through a network, and the server may be a server dedicated to performing deadlock detection processing, or may be a node selected from database nodes to perform deadlock detection processing. The server 106 may communicate with the various database nodes 104 over a network. The server 106 obtains local waiting information of each of the plurality of database nodes 104, filters out the object lock waiting information associated with the global non-waiting transaction of the object lock in the plurality of database nodes 104 from the local waiting information of each of the plurality of database nodes 104, determines, for each global updated local waiting information, that the object lock in the database node 104 to which the targeted global updated local waiting information belongs is not waiting and that the held object lock supports the pre-released local non-waiting transaction, and the server 106 filters out the object lock waiting information associated with the local non-waiting transaction to obtain the local updated local waiting information, and performs global deadlock detection on the plurality of database nodes 104 based on the local waiting information after each local update to obtain a global deadlock detection result for the plurality of database nodes 104. The server 106 may feed back global deadlock detection results of the plurality of database nodes 104 to the terminal 102.
The terminal 102 may be, but not limited to, various desktop computers, notebook computers, smart phones, tablet computers, internet of things devices, and portable wearable devices, where the internet of things devices may be smart speakers, smart televisions, smart air conditioners, smart vehicle devices, and the like. The portable wearable device may be a smart watch, smart bracelet, headset, or the like. The database node 104 and the server 106 may be independent physical servers, or may be a server cluster or a distributed system formed by a plurality of physical servers, or may be a cloud server that provides cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDNs, and basic cloud computing services such as big data and artificial intelligence platforms. The terminal 102 and the server 104 may be directly or indirectly connected by wired or wireless communication. The terminal 102 and the database node 104 and the server 104 may each be directly or indirectly connected by wired or wireless communication means, respectively.
Cloud technology (Cloud technology) refers to a hosting technology that unifies serial resources such as hardware, software, networks and the like in a wide area network or a local area network to realize calculation, storage, processing and sharing of data. The cloud technology is a generic term of network technology, information technology, integration technology, management platform technology, application technology and the like based on cloud computing business model application, can form a resource pool, and is flexible and convenient as required. Cloud computing technology will become an important support. Background services of technical networking systems require a large amount of computing, storage resources, such as video websites, picture-like websites, and more portals. Along with the high development and application of the internet industry, each article possibly has an own identification mark in the future, the identification mark needs to be transmitted to a background system for logic processing, data with different levels can be processed separately, and various industry data needs strong system rear shield support and can be realized only through cloud computing.
Specifically, cloud computing (cloud computing) refers to the delivery and usage patterns of IT infrastructure, meaning that required resources are obtained in an on-demand, easily scalable manner over a network; generalized cloud computing refers to the delivery and usage patterns of services, meaning that the required services are obtained in an on-demand, easily scalable manner over a network. Such services may be IT, software, internet related, or other services. Cloud Computing is a product of fusion of traditional computer and network technology developments such as Grid Computing (Grid Computing), distributed Computing (distributed Computing), parallel Computing (Parallel Computing), utility Computing (Utility Computing), network storage (Network Storage Technologies), virtualization (Virtualization), load balancing (Load balancing), and the like. With the development of the internet, real-time data flow and diversification of connected devices, and the promotion of demands of search services, social networks, mobile commerce, open collaboration and the like, cloud computing is rapidly developed. Unlike the previous parallel distributed computing, the generation of cloud computing will promote the revolutionary transformation of the whole internet mode and enterprise management mode in concept.
The deadlock detection method provided by the embodiment of the application can be realized based on an artificial intelligence (Artificial Intelligence, AI) technology. Artificial intelligence is the theory, method, technique and application system that uses a digital computer or a digital computer-controlled machine to simulate, extend and expand human intelligence, sense the environment, acquire knowledge and use the knowledge to obtain optimal results. In other words, artificial intelligence is an integrated technology of computer science that attempts to understand the essence of intelligence and to produce a new intelligent machine that can react in a similar way to human intelligence. Artificial intelligence, i.e. research on design principles and implementation methods of various intelligent machines, enables the machines to have functions of sensing, reasoning and decision. The artificial intelligence technology is a comprehensive subject, and relates to the technology with wide fields, namely the technology with a hardware level and the technology with a software level. Artificial intelligence infrastructure technologies generally include technologies such as sensors, dedicated artificial intelligence chips, cloud computing, distributed storage, big data processing technologies, operation/interaction systems, mechatronics, and the like. The artificial intelligence software technology mainly comprises a computer vision technology, a voice processing technology, a natural language processing technology, machine learning/deep learning and other directions. The deadlock detection method can sense, infer and make a decision on the global deadlock by relying on an artificial intelligence technology, so that the global deadlock can be accurately detected.
In one embodiment, as shown in fig. 2, a deadlock detection method is provided, where the method is executed by a computer device, specifically, may be executed by a computer device such as a terminal or a server, or may be executed by the terminal and the server together, and in an embodiment of the present application, the method is applied to the server in fig. 1, and is described by taking the example as an example, including the following steps:
step 202, obtaining local waiting information of each of at least two database nodes; each local wait information includes object lock wait information between transactions in the affiliated database node.
The deadlock refers to a blocking phenomenon caused by competition of resources or communication of two or more processes in the execution process, and if no external force is applied, the two processes cannot be pushed down, at the moment, the system is in a deadlock state or the system generates a deadlock, and the processes which are always waiting for each other are called deadlock processes. In the context of data processing, deadlocks may be caused by transactions competing for resources for data processing, which may include transactions or business operations. Data in a database can be updated through transactions, for example, the data in the database can be updated, but deadlock is easy to generate when a plurality of transactions are processed concurrently. The database nodes are nodes in a database system, and the nodes in the database system can comprise data storage nodes and coordinator nodes; the data storage nodes are main storage and parallel computing units of data, the coordinator node is used as an entrance for interaction between a user and the system, the coordinator node can divide a received query meter to each data storage node for execution, and then the processing results are summarized and returned to the user client according to the query results.
The local waiting information includes object lock waiting information between transactions in the affiliated database node, i.e. the local waiting information may be recorded in the affiliated database node, object lock holding information of each triggered data processing transaction and object lock waiting information. The expression form of the local waiting information can be flexibly set according to actual needs, such as a node diagram form, a text description form and the like. Object locks are one of the locking mechanisms used to prevent conflicts caused by multi-process concurrent operations, and object locks may be used to protect database objects such as tables, data, or transactions. When a transaction triggers data processing in a database node, the target data is locked by an object lock holding the target data, so that the target data is prevented from being contended by other transactions, and the accuracy of data processing is ensured. For example, if the transaction a triggers processing for the data1 in the database node 1, and if the update processing is performed, the transaction a may hold an object lock of the data1 on the database node 1, so as to prevent other transactions from generating data contention and collision for the data 1. At this time, the transaction a holds the object lock of the data1 on the database node 1, that is, the transaction a is the holding transaction of the object lock of the data 1; and other transactions needing to be processed for the data1 need to wait for the transaction A to release the object lock of the data1 held by the transaction A before corresponding processing can be performed for the data1, and other transactions can be used as waiting transactions of the object lock of the data1, namely waiting for release of the object lock. The object lock waiting information can be recorded in the local end of the corresponding database node, and the waiting dependency relationship of the object lock among all the transactions, namely, for a certain object lock, the execution of the waiting transaction of the object lock needs to depend on the holding transaction of the object lock, namely, the waiting transaction waiting for the release of the object lock can be aimed at data processing only after the holding transaction releases the object lock.
Specifically, for the database nodes needing deadlock detection, the server may acquire local waiting information of each database node, where the local waiting information includes object lock waiting information between transactions in the database nodes to which the local waiting information belongs. In a specific implementation, the server may detect object lock waiting information between transactions in the database nodes, and obtain local waiting information of the corresponding database nodes according to the object lock waiting information between transactions.
Step 204, filtering the object lock waiting information associated with the global non-waiting transaction from the local waiting information to obtain the local waiting information after global updating; a global non-waiting transaction is a transaction that does not wait for an object lock in at least two database nodes.
The global non-waiting transaction does not wait for the object lock in at least two database nodes, namely, the global non-waiting transaction does not wait for the object lock of other transactions in any one database node, and the execution of the global non-waiting transaction is independent of the release of the other object locks. If the global non-waiting transaction does not wait for the object lock in each database node, the object lock waiting information associated with the global non-waiting transaction does not include the object lock information of the global non-waiting transaction, including the information of the object lock held by the global non-waiting transaction and the transaction information depending on the global non-waiting transaction. The globally updated local waiting information is the local waiting information obtained after filtering the object lock waiting information associated with the globally non-waiting transaction.
Specifically, the server may perform object lock relationship analysis according to the object lock latency information in each local latency information to determine latency relationships between transactions triggered in each database node. Based on the object lock relationships between the transactions, the server may determine a global unhatched transaction for unhatched object locks from the transactions. For example, in database node 1, transaction A waits for object lock 1 for data 1 held by transaction B; transaction B waits for object lock 2 of data 2 held by transaction C; in the database node 2, the transaction C waits for the object lock 3 of the data 3 held by the transaction D, and for the global database formed by the database node 1 and the database node 2, the transaction a waits for the object lock 1 in the database node 1, the transaction B waits for the object lock 2 in the database node 1, the transaction C waits for the object lock 3 in the database node 2, and the transaction D does not wait for the object lock in the database node 1 and the database node 2, so that the execution of the transaction D does not need to wait for other transactions, and the transaction D can be determined as a global non-waiting transaction.
The server can determine the object lock waiting information associated with the global non-waiting transaction, for example, the object lock waiting information associated with the global non-waiting transaction can be determined according to the object lock held by the global non-waiting transaction, and the server filters the object lock waiting information associated with the global non-waiting transaction from the local waiting information so as to simplify the global layer for each local waiting information and obtain the local waiting information after global updating. When filtering the object lock waiting information associated with the global non-waiting transaction, the server can filter the object lock waiting information associated with the global non-waiting transaction in each piece of local waiting information to obtain the local waiting information after global updating; if the local waiting information does not contain the object lock waiting information associated with the global non-waiting transaction, the local waiting information can be directly used as the global updated local waiting information. For example, in the database node 1 and the database node 2 in the previous example, the transaction D is a global non-waiting transaction, but only the local waiting information of the database node 2 includes the object lock waiting information associated with the transaction D, the object lock waiting information associated with the transaction D may be filtered out of the local waiting information of the database node 2, and the local waiting information of the database node 1 may be directly reserved, so as to obtain the local waiting information after global updating of the database node 1 and the database node 2.
Step 206, for each piece of globally updated local waiting information, when the object lock support held by the local non-waiting transaction in the globally updated local waiting information is pre-released, filtering the object lock waiting information associated with the local non-waiting transaction from the globally updated local waiting information to obtain the locally updated local waiting information; the local non-waiting transaction is a transaction which does not wait for an object lock in a database node to which the global updated local waiting information belongs.
The local non-waiting transaction does not wait for the object lock in the corresponding affiliated database node, namely the local non-waiting transaction does not wait for the object lock of other transactions in the affiliated database node, and the execution of the local non-waiting transaction on the local side of the database node does not depend on the release of the other object locks. In the database node to which the local waiting information after global updating belongs, the local non-waiting transaction does not wait for the object lock held by other transactions, and the local non-waiting transaction holds the object lock in the database node, namely is relied on by other transactions in the database node. The object lock held by the local non-waiting transaction supports pre-release, which indicates that the lock of the object lock held by the local non-waiting transaction can be released even if the local non-waiting transaction does not end the transaction, and then the object lock waiting information associated with the local non-waiting transaction in the affiliated database node can be filtered, so that the local waiting information is further simplified.
The decision whether the object lock supports pre-release can be set according to the service requirement, for example, the decision can be made according to the type of the transaction and the state of the transaction. For example, for an update, delete, insert data operation transaction, the object lock held by the transaction may be considered to support pre-release when the transaction is in the resolution phase, and not when the transaction is in the execution phase. In addition, for select, query, etc. data operation transactions, it may be directly determined that the object lock held by the transaction supports pre-release. If the local non-waiting transaction does not wait for an object lock in the database node to which the local waiting information after the global update is directed, the object lock waiting information associated with the local non-waiting transaction does not include the object lock information of the local non-waiting transaction waiting, but includes the information of the object lock held by the local non-waiting transaction in the database node to which the local non-waiting transaction belongs and the transaction information dependent on the local non-waiting transaction. The local waiting information after local updating is the local waiting information obtained by further filtering the object lock waiting information associated with the local non-waiting transaction.
Specifically, for each obtained local waiting information after global updating, the server performs local simplification processing for each local waiting information, for each local waiting information after global updating, the server determines each triggered transaction in the corresponding database node according to the local waiting information after global updating, and determines a local object lock relationship in the database node between each transaction. Based on the local object lock relationship in the database node between the transactions, the server may determine, from the transactions, that the local non-waiting transaction is a transaction in the database node to which the globally updated local waiting information belongs that does not wait for the object lock, i.e., the local non-waiting transaction does not wait for the object lock in the database node. The server may determine, for an object lock held by the local non-waiting transaction, whether the object lock held by the local non-waiting transaction supports pre-release, thereby determining whether the object lock held by the local non-waiting transaction supports releasing the lock of the object lock if the local non-waiting transaction is not finished. For the held object lock supporting the pre-released local non-waiting transaction, the server can determine the local non-waiting transaction associated object lock waiting information from the aimed global updated local waiting information and filter the aimed global updated local waiting information, so that local simplification is realized, and the local updated local waiting information is obtained. The server performs local simplification processing on each piece of global updated local waiting information, and obtains each piece of local updated local waiting information after traversing each piece of global updated local waiting information.
Step 208, global deadlock detection is performed on at least two database nodes based on the local waiting information after each local update, so as to obtain a global deadlock detection result.
The global deadlock detection is performed globally on at least two database nodes by a pointer, and is different from the deadlock detection which aims at the local side of each database node. For a plurality of database nodes, even if each local side of each database node has no deadlock, the global database formed by the plurality of database nodes still has a possible deadlock, namely the global deadlock.
Specifically, the server may perform global deadlock detection by integrating the local waiting information after each local update, so as to detect whether global deadlock exists in the whole of at least two database nodes, and obtain a global deadlock detection result for at least two database nodes. In a specific implementation, the server may analyze the object lock relationship between the transactions according to the local waiting information after each local update, and determine whether a global deadlock exists in at least two database nodes based on the object lock relationship analysis result, so as to obtain a global deadlock detection result.
In the deadlock detection method, object lock waiting information associated with global non-waiting transactions of object locks in at least two database nodes is filtered out from local waiting information of at least two database nodes, the local non-waiting transactions which are not waiting for the object locks in the database nodes to which the global updated local waiting information belongs and support pre-released object locks are determined according to the local waiting information after global updating, the object lock waiting information associated with the local non-waiting transactions is filtered out, the local updated local waiting information is obtained, and global deadlock detection is carried out on the at least two database nodes based on the local waiting information after local updating. In the deadlock detection processing process, object lock waiting information of transactions which do not wait for an object lock in the global database node is filtered, the object lock waiting information of transactions which do not wait for the object lock in the local database node is further filtered, the global object lock waiting information of the database node can be effectively simplified, information interference of deadlock detection is reduced, global deadlock detection is carried out through the simplified object lock waiting information, and accuracy of deadlock detection can be improved.
In one embodiment, as shown in fig. 3, the processing of global update, that is, filtering the object lock waiting information associated with the global non-waiting transaction from the local waiting information, to obtain the local waiting information after global update, includes:
step 302, determining global non-waiting transactions in at least two database nodes based on respective local waiting information.
Wherein the globally non-waiting transaction waits for other object locks in each database node. Specifically, the server determines global non-waiting transactions in each database node based on each local waiting information, the server may determine a holding transaction and a waiting transaction of each object lock according to the object lock waiting information in the local waiting information, and the server may determine a transaction which is not a waiting transaction in each database node as a global non-waiting transaction.
And step 304, filtering the object lock waiting information associated with the global non-waiting transaction from the local waiting information to obtain the global updated local waiting information.
The object lock waiting information associated with the global non-waiting transaction may include various information related to the object lock held by the global non-waiting transaction, such as transaction information of the global non-waiting transaction, information of the object lock held by the global non-waiting transaction, or waiting transaction information of the object lock held by the global non-waiting transaction.
Specifically, the server may determine the object lock waiting information associated with the global unhatched transaction, and may obtain the object lock waiting information associated with the global unhatched transaction according to the object lock held by the global unhatched transaction and the waiting transaction of the object lock held by the global unhatched transaction. And the server filters the object lock waiting information associated with the global non-waiting transaction from the local waiting information respectively to obtain the local waiting information after global updating. In a specific application, for local waiting information including object lock waiting information associated with a global non-waiting transaction, the server can filter out the local waiting information in a targeted manner to obtain globally updated local waiting information; for local waiting information which does not comprise the object lock waiting information associated with the global non-waiting transaction, the server can directly serve as the local waiting information after global updating without processing.
In a specific application, the specific form of the local wait information may be a node diagram, and the local wait information may include a local wait diagram, in the local wait diagram, vertices represent transactions triggered in the affiliated database nodes, and directed edges connected between the vertices represent object lock wait relationships between transactions represented by the vertices, where the directions of the directed edges may be used to represent wait and hold relationships of the object lock. For example, an open circle may be employed to characterize transactions, a directed edge connected between open circles is used to characterize an object lock waiting relationship between transactions, the directed edge points from a holding transaction of an object lock to a waiting transaction of the object lock, and as shown in fig. 4, the database globally refers to data node 1 and database node 2, in database node 1, vertex a points to vertex B through the directed edge, i.e., vertex B characterizes the object lock of the transaction characterized by vertex a; likewise, the transaction characterized by vertex E waits for the object lock of the transaction characterized by vertex D; the transaction characterized by vertex D waits for the object lock of the transaction characterized by vertex C; in database node 2, the transaction characterized by vertex F waits for the object lock of the transaction characterized by vertex F. The global wait diagram can be formed based on the local wait diagram, and global deadlock detection can be conducted through the global wait diagram.
In this embodiment, the server determines the global non-waiting transaction according to each local waiting information, and filters the object lock waiting information associated with the global non-waiting transaction from each local waiting information, so that filtering and simplifying are performed on each local waiting information at the global layer, information interference of deadlock detection can be reduced, global deadlock detection is performed on the simplified object lock waiting information, and accuracy of deadlock detection can be improved.
In one embodiment, the local wait information includes a local wait map; the vertices in the local wait-for graph characterize transactions triggered in the affiliated database node; the directed edges in the local wait graph point from the vertices of the wait transaction that characterize the object lock to the vertices of the hold transaction that characterize the object lock. Based on each local wait information, determining a global non-waiting transaction in at least two database nodes, comprising: forming global waiting diagrams of at least two database nodes according to each local waiting diagram, and determining respective global degree of each vertex in the global waiting diagrams; the global degree is obtained according to the sum of the local degrees of the vertexes; the local degree is used for representing the number of directed edges of the vertex, which are directed to other vertices, in the local waiting diagram to which the vertex belongs; and determining a global zero-degree vertex with the global degree of zero in the global waiting diagram according to the global degree of each vertex.
The local wait information may be in the form of a node diagram, and specifically may include a local wait diagram, where object lock wait information between transactions in the affiliated database nodes is represented by vertices and directed edges connecting two different vertices. The vertex in the local waiting diagram characterizes the transaction triggered in the affiliated database node, namely, the transaction is mapped to the vertex to characterize, for example, the transaction A can be characterized by the vertex A; the directed edges in the local wait graph point from the vertices of the waiting transactions that characterize the object lock to the vertices of the holding transactions that characterize the object lock, i.e., by mapping the object lock waiting relationship between transactions to the directed edges that connect the vertices, the directed edges point from the waiting transactions of the object lock to the holding transactions, e.g., the directed edges that can point through vertex a to vertex B, characterize the object lock held by transaction a to wait for transaction B. As shown in fig. 5, in database node 1, a transaction characterized by vertex a waits for an object lock of a transaction characterized by vertex B, and a transaction characterized by vertex B waits for an object lock of a transaction characterized by vertex C; in database node 2, the transaction characterized by vertex B waits for the object lock of the transaction characterized by vertex a.
Upon determining a global non-waiting transaction, the vertices of the respective tokens may be determined from the respective local wait graphs. The global waiting diagram is constructed according to each local waiting diagram and is used for carrying out global vertex analysis on the whole database nodes. The degree of the vertex is used for representing the number of directional edges of the vertex pointing to other vertexes, if the vertex A simultaneously points to the vertex B, the vertex C and the vertex D through 3 directional edges, the degree of the vertex can be determined to be 3. The local degree is used for representing the number of directed edges of the vertex pointing to other vertexes in the local waiting diagram; according to the sum of the local disciplines of the same vertex in each local waiting graph, the global discipline of the vertex can be obtained, and the vertex corresponding to the global non-waiting transaction can be determined from the global waiting graph through the global discipline. The global zero-degree vertex is a vertex with global degree of 0, and if the global degree of 0, the vertex indicates that in each local waiting diagram, the vertex does not point to other vertices through a directed edge, i.e. does not wait for other object locks, i.e. the transaction represented by the global zero-degree vertex belongs to a global non-waiting transaction.
Specifically, the server may construct a global latency graph of at least two database nodes according to each local latency graph, and for each vertex in the global latency graph, the server may determine a global degree of egress of each vertex. The global degree of departure of the vertex can be obtained according to the local degree of departure of the vertex on each local waiting diagram, the server can traverse each vertex, determine the local degree of departure of the vertex on each local waiting diagram, namely determine the number of directed edges of the vertex pointing to other vertexes in each local waiting diagram, and sum to obtain the global degree of departure of the vertex according to the local degree of departure of the vertex on each local waiting diagram. The server can determine a global zero-degree vertex in the global waiting diagram according to the respective global degree value of each vertex, specifically can determine the vertex with the global degree of zero as the global zero-degree vertex, and the transaction represented by the global zero-degree vertex belongs to a global non-waiting transaction, so that the global non-waiting transaction can be determined.
Further, filtering the object lock waiting information associated with the global non-waiting transaction from the local waiting information to obtain the global updated local waiting information, including: deleting global zero-degree vertexes and directed edges pointing to the global zero-degree vertexes in each local waiting diagram respectively to obtain each global updated local waiting diagram; and obtaining the local waiting information after global updating according to the local waiting map after global updating.
The transaction represented by the global zero-degree vertex belongs to a global non-waiting transaction, the directed edge pointing to the global zero-degree vertex represents the object lock waiting relationship of the object held by the waiting global non-waiting transaction, and all local waiting graphs can be simplified at the global level by deleting the global zero-degree vertex and the directed edge pointing to the global zero-degree vertex in the local waiting graph, so that all the globally updated local waiting graphs can be obtained.
Specifically, the server may determine a global zero-degree vertex and a directed edge pointing to the global zero-degree vertex in each local waiting graph, and delete the global zero-degree vertex and the directed edge pointing to the global zero-degree vertex in each local waiting graph respectively, so as to obtain each globally updated local waiting graph. The server can obtain the local waiting information after global updating according to the local waiting diagram after global updating, for example, the local waiting diagram after global updating can be directly used as the local waiting information after global updating.
In this embodiment, for each local waiting diagram constructed based on the object lock waiting information mapping, the global degree of each vertex is determined in the global waiting diagram formed by each local waiting diagram, the global zero degree vertex which can represent the global non-waiting transaction is determined based on the global degree of each local waiting diagram, and the global zero degree vertex and the directed edge pointing to the global zero degree vertex are deleted in each local waiting diagram, so that global simplification updating of each local waiting diagram is realized by using the global zero degree vertex, information interference of deadlock detection can be reduced, and the accuracy and the deadlock detection efficiency of deadlock detection can be improved by performing global deadlock detection on the simplified object lock waiting information.
In one embodiment, when the object lock support pre-release held by the local non-waiting transaction in the globally updated local waiting information is aimed at, filtering the object lock waiting information associated with the local non-waiting transaction from the globally updated local waiting information to obtain the locally updated local waiting information, including: determining that a transaction is not locally waited based on the targeted globally updated local wait information; the local non-waiting transaction is a transaction in which the object lock is not waiting in the local database node; the local database node is the database node to which the local waiting information subjected to global updating belongs; and when the object lock held by the local non-waiting transaction supports pre-release, filtering the object lock waiting information associated with the local non-waiting transaction from the local waiting information subjected to global updating, and obtaining the local waiting information subjected to local updating.
Wherein the local non-waiting transaction does not wait for an object lock in the corresponding affiliated database node. The object lock waiting information associated with the local non-waiting transaction may include various information related to the object lock held by the local non-waiting transaction, such as transaction information of the local non-waiting transaction, information of the object lock held by the local non-waiting transaction, or waiting transaction information of the object lock held by the local non-waiting transaction. The decision whether the object lock supports pre-release can be set according to the service requirement, and particularly can be determined according to the type of the transaction and the state of the transaction.
Specifically, for each piece of global updated local waiting information, the server performs local updating processing, and the specific server determines a local non-waiting transaction based on the local waiting information after the global updating, where the local non-waiting transaction is a transaction of a non-waiting object lock in a database node to which the local waiting information after the global updating belongs. In specific implementation, the server may determine a local database node to which the targeted global updated local waiting information belongs, determine a holding transaction and a waiting transaction of each object lock in the local database node according to the object lock waiting information in the targeted global updated local waiting information, and determine a transaction which is not a waiting transaction in the local database node as a local non-waiting transaction. The server may determine whether the local object lock not awaiting the transaction hold supports pre-release. If the server can determine the transaction type and the transaction state of the local non-waiting transaction, the server can determine the object lock held by the local non-waiting transaction according to the transaction type and the transaction state, so as to determine whether the object lock held by the local non-waiting transaction supports pre-release.
When the object lock held by the local non-waiting transaction supports pre-release, namely when the local non-waiting transaction is not ended, the object lock held by the local non-waiting transaction can be released, the server can determine the object lock waiting information associated with the local non-waiting transaction, and the specific server can obtain the object lock waiting information associated with the local non-waiting transaction according to the object lock held by the local non-waiting transaction and the waiting transaction of the object lock held by the local non-waiting transaction in the affiliated database node. And filtering the object lock waiting information associated with the local non-waiting transaction from the local waiting information subjected to global updating by the server to obtain the local waiting information subjected to local updating.
In this embodiment, the server determines that the transaction is not locally waiting based on the local waiting information after global update, and filters the object lock waiting information associated with the local waiting information from the local waiting information after global update, so that filtering and simplifying the local waiting information at the local layer of the database node can reduce information interference of deadlock detection, and accuracy and processing efficiency of deadlock detection can be improved by performing global deadlock detection on the simplified object lock waiting information.
In one embodiment, the local wait information includes a local wait map; the vertices in the local wait-for graph characterize transactions triggered in the affiliated database node; the directed edges in the local wait graph point from the vertices of the wait transaction that characterize the object lock to the vertices of the hold transaction that characterize the object lock; the globally updated local wait information includes each globally updated local wait map. Determining that a transaction is not locally waiting based on the targeted globally updated local waiting information, including: determining respective local discharges of each vertex in the local waiting diagram after global updating; the local degree is used for representing the number of directed edges of the vertex, which are directed to other vertices, in the local waiting diagram to which the vertex belongs; and determining a local zero-degree vertex with the local degree of zero in the local waiting diagram after the global updating according to the local degree of each vertex.
The local wait information may specifically include a local wait diagram, where object lock wait information between transactions in the affiliated database node is characterized by vertices and directed edges connecting between two different vertices. The global updated local waiting information includes local waiting diagrams after global updating, that is, the obtained local waiting diagrams after global updating can be used as the local waiting information after global updating. The local degree of a vertex is used to characterize the number of directed edges that the vertex points to other vertices in the local wait graph to which it belongs. The local zero-degree vertex is a vertex with a local degree of 0, and if the local degree of 0, the vertex does not point to other vertices through a directed edge in the local waiting diagram, that is, other object locks are not waiting, and a transaction represented by the local zero-degree vertex belongs to a local non-waiting transaction.
Specifically, for each globally updated local waiting graph, the server performs local update processing, and for the globally updated local waiting graph for which the server is aimed, the server may determine the local output of each vertex, and specifically may obtain the local output of the vertex according to the number of directional edges of the vertex pointing to other vertices in the globally updated local waiting graph. The server may determine the local degree of each vertex in the local wait map for the global update by traversing each vertex. And the server determines a local zero-degree vertex in the local waiting diagram after global updating according to the local degree of each vertex, specifically determines the vertex with the local degree of zero as the local zero-degree vertex, and the transaction represented by the local zero-degree vertex belongs to a local non-waiting transaction, so that the local non-waiting transaction can be determined.
Further, when the object lock supported by the local non-waiting transaction is pre-released, filtering the object lock waiting information associated with the local non-waiting transaction from the local waiting information after global updating, to obtain the local waiting information after local updating, including: when the object lock support pre-release of the transaction represented by the local zero-degree vertex is carried out, deleting the directed edge pointing to the local zero-degree vertex from the local waiting diagram after the global updating, and obtaining the local waiting diagram after the local updating; and obtaining the local waiting information after the local update according to the local waiting diagram after the local update.
The transaction represented by the local zero-degree vertex belongs to a local non-waiting transaction, the directed edge pointing to the local zero-degree vertex represents an object lock waiting relationship of an object held by the waiting local non-waiting transaction, and the local waiting graph can be simplified at a local layer by deleting the directed edge pointing to the global zero-degree vertex, so that a local updated local waiting graph is obtained.
Specifically, the server may determine whether the object lock held by the transaction represented by the local zero-degree vertex supports pre-release, and in the case that the object lock held by the transaction represented by the local zero-degree vertex supports pre-release, the server determines a directed edge pointing to the local zero-degree vertex in the local wait map after global update, and deletes the directed edge pointing to the local zero-degree vertex to obtain the local wait map after local update. The server can obtain the local waiting information after local updating according to the local waiting diagram after local updating, and specifically can directly take the local waiting diagram after local updating as the local waiting information after local updating.
In this embodiment, for each local waiting diagram constructed based on the object lock waiting information mapping, after global updating is performed, local updating is performed on each local waiting diagram after global updating, for each local waiting diagram after global updating, the local degree of each vertex is determined in each local waiting diagram after global updating, based on the local degree of each local zero degree vertex which can represent a local non-waiting transaction is determined, under the condition that the object lock held by the transaction represented by the local zero degree vertex supports pre-release, the directed edge of each local zero degree vertex in each local waiting diagram after global updating is deleted, so that local partial simplified updating is performed on the local waiting diagram after global updating by using the local zero degree vertex, information interference of deadlock detection can be reduced, and accuracy and deadlock detection efficiency of deadlock detection can be improved by performing global deadlock detection on the simplified object lock waiting information.
In one embodiment, when the object lock supported pre-release of the transaction represented by the local zero-degree vertex, deleting the directed edge pointing to the local zero-degree vertex from the local wait diagram after the global update, and obtaining the local wait diagram after the local update includes: determining directed edges to be filtered pointing to local zero-degree vertexes in the local waiting diagram after global updating; the directed edge to be filtered represents the object lock support pre-release which is represented by the transaction held by the local zero-degree vertex; and deleting the directed edges to be filtered from the local waiting diagram after the global updating, and obtaining the local waiting diagram after the local updating.
The object lock which is held by the transaction and is characterized by the local zero-degree vertex is supported to be pre-released by the directed edge to be filtered. In the local waiting diagram after the global updating, the directed edges pointing to the local zero-degree vertex can comprise a plurality of types, and the directed edges to be filtered can be filtered to perform the targeted local updating on the local waiting diagram, so that the accuracy of deadlock detection is guaranteed.
Specifically, the server determines, in the local wait diagram after global updating, a directed edge to be filtered pointing to the local zero-degree vertex, where the directed edge to be filtered characterizes object lock support pre-release held by a transaction characterized by the local zero-degree vertex. In the local waiting diagram, the directed edges can be divided into a plurality of types, such as strong relation edges and weakening edges, wherein the strong relation edges belong to the directed edges which can not be filtered, and the weakening edges belong to the directed edges which can be filtered. In a specific application, the object lock held by the transaction represented by the local zero-degree vertex is not supported to be released in advance by the strong relation edge, namely the object lock held by the transaction represented by the local zero-degree vertex cannot be released when the transaction represented by the local zero-degree vertex is not ended; the object lock held by the transaction represented by the weakened edge represents the local zero-degree vertex supports pre-release, namely the object lock held by the transaction represented by the local zero-degree vertex can be released in advance when the transaction represented by the local zero-degree vertex is not finished. The server deletes the directed edges to be filtered out in the global updated local waiting diagram, and then, carrying out local updating by using the local zero-degree vertex to obtain a local waiting diagram after local updating.
In this embodiment, the server deletes the target local waiting diagram after global updating, which characterizes the object lock supported by the transaction characterized by the local zero-degree vertex, from the pre-released directed edges to be filtered, so as to utilize the directed edges to be filtered, which point to the local zero-degree vertex, to perform targeted local simplified updating on the global updated local waiting diagram, thereby reducing information interference of deadlock detection, and performing global deadlock detection through the simplified object lock waiting information, and improving accuracy and efficiency of deadlock detection.
In one embodiment, when the object lock held by the local non-waiting transaction supports pre-release, filtering the object lock waiting information associated with the local non-waiting transaction from the targeted globally updated local waiting information to obtain the locally updated local waiting information, including: determining the transaction type of the local non-waiting transaction and the transaction execution state; when the transaction type belongs to the pre-release transaction type and the transaction execution state indicates that the local object lock which is not held by the transaction supports pre-release, filtering the object lock waiting information associated with the local non-waiting transaction from the local waiting information which is updated globally, and obtaining the local waiting information after the local update.
Wherein the transaction types are used to distinguish between different transaction operations, i.e. different transaction operations may correspond to different transaction types. Such as operations transactions for updating, selecting, querying, deleting, inserting, etc., data may be considered to belong to different transaction types. The transaction execution state is used for describing the stage in the process of executing the transaction, and the transaction execution is in different stages, so that the locking release condition of the object lock held by the transaction execution state is different. For example, for an update type transaction, the transaction is in an resolution phase, such as when resolving a specific operation instruction, the object lock held by the transaction supports pre-release; while the transaction is in an execution phase, such as specifically performing a data update process, the transaction-holding object lock does not support pre-release.
Specifically, the server may determine a transaction type and a transaction execution state of the local non-waiting transaction, where the transaction type and the transaction execution state of the local non-waiting transaction may be determined according to transaction attribute information of the local non-waiting transaction, that is, the server may query the transaction attribute information of the local non-waiting transaction, and the server may determine the transaction type and the transaction execution state of the local non-waiting transaction from the transaction attribute information. The server determines whether the transaction type of the local non-waiting transaction belongs to a pre-release transaction type, wherein the pre-release transaction type refers to a transaction type supporting pre-release, and specifically can comprise a transaction type supporting pre-release unconditionally or a transaction type supporting pre-release conditionally. The server determines whether the object lock held by the local non-waiting transaction supports pre-release according to the transaction execution state, and when the transaction type of the local non-waiting transaction belongs to the pre-release transaction type and the transaction execution state indicates that the object lock held by the local non-waiting transaction supports pre-release, the server can determine the object lock waiting information associated with the local non-waiting transaction from the local waiting information after global updating, and filter the local waiting information to obtain the local waiting information after local updating.
In this embodiment, the server determines, according to the transaction type of the local non-waiting transaction and the execution state of the transaction, the pre-release of the object lock held by the local non-waiting transaction, so that the accuracy of the pre-release determination can be ensured, and the object lock waiting information of the object lock which is held and supports pre-release of the local non-waiting transaction is filtered, so that the object lock waiting information can be simplified on the local side of the database node, thereby being beneficial to improving the accuracy of deadlock detection.
In one embodiment, the deadlock detection method further comprises: and when the target global updated local waiting information does not support pre-release of the object lock held by the local non-waiting transaction of the target global updated local waiting information in the database nodes to which the target global updated local waiting information belongs, performing global deadlock detection on at least two database nodes through the target global updated local waiting information, and obtaining a global deadlock detection result.
The method comprises the steps that an object lock held by a local non-waiting transaction does not support pre-release, and the fact that the object lock held by the local non-waiting transaction cannot be released under the condition that the local non-waiting transaction is not ended is indicated, at the moment, local update of local waiting information by the local non-waiting transaction cannot be carried out, and then global deadlock detection can be carried out by directly utilizing the globally updated local waiting information.
Specifically, for each obtained local waiting information after global updating, the server performs local simplification processing for each local waiting information, for each local waiting information after global updating, the server determines for an object lock held by a local non-waiting transaction, and when the object lock held by the local non-waiting transaction does not support pre-release, the server may not update the local waiting information after global updating; and when the object lock support pre-release of the local non-waiting transaction holding object lock in the database node to which the local waiting information after the global updating is aimed is carried out, the local non-waiting transaction can be aimed to update. And for the globally updated local waiting information which is not subjected to local updating, the server performs global deadlock detection on the database node through the globally updated local waiting information to obtain a global deadlock detection result.
In this embodiment, for a local non-waiting transaction in which the held object lock does not support pre-release, the server does not locally update the local waiting information after the corresponding global update, and global deadlock detection is directly performed on at least two database nodes through the local waiting information after the corresponding global update, so that local update processing can be flexibly performed according to the local non-waiting transaction in the database node to which the local waiting information after each global update belongs, the validity of the local update can be ensured, new information interference caused by the local update is avoided, and the accuracy of deadlock detection can be improved.
In one embodiment, global deadlock detection is performed on at least two database nodes based on local waiting information updated locally, so as to obtain a global deadlock detection result, including: detecting an object lock relation between transactions in at least two database nodes based on the local waiting information updated by each local, so as to obtain an object lock relation detection result; and when the object lock relation detection result indicates that the transaction waiting for the object lock exists in at least two database nodes, obtaining a global deadlock detection result indicating that the global deadlock exists in at least two database nodes.
The object lock relation detection result is a detection result of an object lock relation among all the transactions, and whether an object lock waiting relation exists among all the transactions can be determined according to the object lock relation detection result. Specifically, for each obtained local updated local waiting information, the server detects an object lock relationship between transactions in each database node based on each local updated local waiting information. The specific server can determine the holding transaction and the waiting transaction of the object lock in each database node based on the local waiting information after each local update, and can determine whether the transaction waiting for the object lock exists or not by performing transaction matching on the holding transaction and the waiting transaction of each object lock, so as to obtain the object lock relation detection result. When the object lock relation detection result indicates that there are transactions waiting for the object lock in the at least two database nodes, the global deadlock detection result obtained by the server may indicate that there are global deadlocks in the at least two database nodes.
For example, for the database node 1 and the database node 2, based on the local waiting information after the local update of the database node 1 and the database node 2, it is determined that the object lock 1 waiting for the transaction B exists in the database node 1, and the object lock 2 waiting for the transaction a exists in the database node 2, then it may be determined that the object locks waiting for each other exist in the database node 1 and the database node 2 between the transaction a and the transaction B, that is, the transaction a is the waiting transaction of the object lock 1 held by the transaction B and the holding transaction of the object lock 2 waiting for the transaction B, and the transaction B is the waiting transaction of the object lock 2 held by the transaction a and the holding transaction of the object lock 1 waiting for the transaction a, so as to form a locking cycle, that is, it may be determined that the global deadlock exists in the database node 1 and the database node 2, and a global deadlock detection result indicating that the global deadlock exists in the database node 1 and the database node 2 may be obtained.
In this embodiment, the server detects an object lock relationship between transactions in at least two database nodes based on the local waiting information updated locally, so that the accuracy of deadlock detection can be improved by performing global deadlock detection through the simplified object lock waiting information.
In one embodiment, the deadlock detection method further comprises: when the object lock relation detection result indicates that the transaction waiting for the object lock does not exist in at least two database nodes, a global deadlock detection result is obtained, wherein the global deadlock detection result indicates that the at least two database nodes do not exist in the current deadlock detection period; and when the next deadlock detection period is reached, global deadlock detection processing of the next deadlock detection period is performed for at least two database nodes.
The deadlock detection period can be set according to actual needs, for example, 1 second, so that periodic deadlock detection can be continuously performed on the database nodes. Specifically, when the object lock relation detection result indicates that there is no transaction waiting for the object lock in at least two database nodes, after the global deadlock detection is performed based on the simplified object lock waiting information, determining that there is no global deadlock in each database node, and then the obtained global deadlock detection result indicates that there is no global deadlock in at least two database nodes in the current deadlock detection period. Further, the server may detect whether the next deadlock detection period is reached, and when the next deadlock detection period is reached, the server may trigger global deadlock detection processing for the next deadlock detection period for at least two database nodes, and may specifically circularly acquire local waiting information of each of the at least two database nodes to perform processing of deadlock detection.
In this embodiment, when the global deadlock detection result of the present deadlock detection period indicates that there is no global deadlock, the server may continue to perform global deadlock detection processing for the next deadlock detection period, so that global deadlock detection can be continuously performed on each database node, global deadlock can be detected in time, and normal data processing of the database node is guaranteed.
In one embodiment, the deadlock detection method further comprises: when the global deadlock detection result indicates that the global deadlock exists in at least two database nodes, determining that a deadlock associated transaction of the global deadlock exists in the at least two database nodes; and determining release transactions from the deadlock associated transactions according to the deadlock release strategy, and terminating the release transactions.
Where a deadlock associated transaction is a transaction associated with a global deadlock, it may specifically include a transaction that causes a deadlock to occur. For example, transaction A holds object lock 1 of data1 in database node 1 while transaction A waits in database node 2 for object lock 2 of data2 held by transaction B; transaction B waits in database node 1 for object lock 1 of data1 held by transaction a, and transaction B holds in database node 2 object lock 2 of data2, at which time a global deadlock is formed in database node 1 and database node 2, which is caused by transaction a and transaction B, i.e. both transaction a and transaction B are associated transactions as deadlocks. The release transaction is a transaction which is released preferentially when the deadlock is released, and the waiting loop can be broken through releasing the release transaction in the dead lock associated transaction, so that the global deadlock is released. The deadlock release policy is a policy for releasing global deadlocks, and based on the deadlock release policy, release transactions can be determined, so that the global deadlocks are released by terminating the release transactions.
Specifically, when the global deadlock detection result indicates that a global deadlock exists in at least two database nodes, the server may perform a global deadlock cancellation process. The server may determine that a deadlock associated transaction of a global deadlock exists in at least two database nodes, where the deadlock associated transaction is a transaction that initiates the global deadlock, and may specifically be determined according to an object lock waiting relationship between each transaction. The server acquires a preset deadlock release strategy, determines release transactions from the deadlock associated transactions according to the determined deadlock release strategy, and breaks a waiting loop in the global deadlock by terminating the determined release transactions so as to release the global deadlock in at least two database nodes. In a specific application, the deadlock release policy may include a policy to terminate the youngest transaction, i.e. the server may determine the youngest transaction of the dead lock associated transactions, i.e. the transaction with the latest trigger time, as a release transaction, and release the global deadlock by terminating the release transaction.
In this embodiment, when a global deadlock exists in at least two database nodes, the server determines a release transaction from the deadlock associated transactions with the global deadlock according to a deadlock release policy, and terminates the release transaction, so as to release the global deadlock, and thus, the global deadlock can be timely released, and normal operation of each database node is ensured.
In one embodiment, at least two database nodes belong to nodes in a distributed database; the deadlock detection method is performed by a coordinator node in the distributed database.
The distributed database comprises a plurality of nodes, and each node can respectively store data. The nodes in the distributed database may include data storage nodes and coordinator nodes; the data storage nodes are main storage and parallel computing units of data, the coordinator node is used as an entrance for interaction between a user and the system, the coordinator node can divide a received query meter to each data storage node for execution, and then the processing results are summarized and returned to the user client according to the query results. Specifically, the database nodes belong to nodes in the distributed database, that is, at least two database nodes can include a data storage node or a coordinator node; the deadlock detection method is executed by the coordinator node in the distributed database, namely global deadlock detection processing is carried out on the nodes in the distributed database through the coordinator node in the distributed database, so that normal operation of the distributed database is ensured.
In this embodiment, through the coordinator node in the distributed database, global deadlock detection is performed for at least two nodes in the distributed database, so that normal operation of the distributed database can be ensured.
The application also provides an application scene, and the application scene applies the deadlock detection method. Specifically, the application of the dead lock detection method in the application scene is as follows:
how to efficiently process and analyze large amounts of data for large data warehouse systems has been a great challenge to system developers: OLTP (On-Line Transaction Processing, online transaction processing) systems can severely impact performance because they can execute multiple transactions simultaneously, which can easily result in deadlocks. OLTP systems are database processing systems that process transactions and business operations in a real-time environment. In OLTP systems, each transaction and business operation is considered a transaction that must satisfy the ACID attribute: atomicity (atom), consistency (Consistency), isolation (Isolation), and Durability (Durability), meaning that all operations either succeed or fail completely in one transaction, guaranteeing data integrity and Consistency. The deadlock detection method provided by the embodiment can solve the problem of deadlock of the transaction in the distributed system, can obviously improve the stability of the large-scale distributed system, enables the system to support the concurrent writing and reading operation of the large-scale distributed transaction of the OLTP system, and greatly improves the performance of the system.
The deadlock detection method provided by the embodiment can be applied to a distributed data system oriented to important business scenes such as advertisements, user analysis and the like, and particularly relates to a large-scale distributed data system, which uses a massive parallel processing architecture, reduces locking overhead and increases the OLTP response time through a global deadlock detector, and meanwhile, performance is not sacrificed on the OLAP (Online Analytical Processing, online analysis and processing) workload. OLAP is a data analysis and processing technology, can be used for rapidly carrying out complex analysis and inquiry on large-scale data, is mainly used in data warehouses and business intelligent systems, can carry out multidimensional exploration and analysis on the data in a multidimensional data analysis mode, and can realize multi-angle and multidimensional analysis on the data so as to better support decision analysis. In addition, a brand new distributed transaction isolation component is designed based on the global deadlock detector to manage transactions of the OLTP system, so that resource conflict in a high concurrency scene can be avoided, ultrahigh throughput can be provided on high concurrency real-time calculation, and the performance of the OLTP data system is improved.
The deadlock detection method provided by the embodiment can be applied to optimization of object locks aiming at a distributed system, wherein the object locks are one of locking mechanisms for preventing conflict caused by multi-process concurrent operation, and are used for protecting database objects such as tables, data or transactions. The object lock optimization for the distributed system is a core for improving the performance of the OLTP system, the core idea is to solve the global deadlock problem in the distributed environment through a global deadlock detection algorithm, and delete transaction dependence and weakened edges based on greedy rules, so that deadlock in the distributed system is easier to discover and clear, and the accuracy of deadlock detection can be improved.
In particular, locks are widely used in databases to prevent race conditions of different granularity, such as different types of locks that may include spin locks, lightweight locks, and object locks, to apply different scenario needs. Where spin locks and lightweight locks are used to protect critical areas in read or write shared memory, locks are acquired in the same order, etc., following a predetermined rule based on which deadlocks involving spin locks and lightweight locks can be broken. While the object lock directly affects the concurrency performance of the process, such as a table, data or a transaction, the deadlock detection method provided in this embodiment is mainly used for performing deadlock detection optimization on the object lock.
Some objects, such as tables, may be operated on concurrently by transactions, and upon accessing such objects, locks should be held in the correct mode to protect the object. This embodiment employs a two-stage lock: the object lock is held in the first phase, the transaction identifier is written into the data line to lock the corresponding object in the second phase, and the object lock is released when the transaction is committed or aborted. Locks can be divided into different levels, such as eight different levels of locking patterns, with higher levels of locking patterns allowing finer concurrency control with lower concurrency. For example, an exclusive lock can only perform one operation at a time, so that concurrent control is finer. As shown in table 1 below, eight locking patterns, respective conflict patterns, and corresponding typical operation statements.
TABLE 1
Among them, shared locks are a lock mechanism for concurrency control that allows multiple transactions to read the same data object at the same time, but does not allow them to perform update and delete operations until all transactions holding the shared lock release the lock. The sharing lock can ensure data consistency and isolation when data are read concurrently, and data competition and conflict are avoided. An exclusive lock is a lock that is used to ensure data consistency and requires that, when certain operations (e.g., updates, deletions) are performed, the associated data line be exclusively locked to prevent other transactions from modifying the line. An exclusive lock is a strict level of locking that blocks other transactions from reading and modifying the line until the lock is released. Taking the example of a shared lock in Table 1, with a lock level of 3, the latches with lock levels 4,5,6,7,8 conflict, a typical operation may be an operation transaction that creates an index.
Updating or deleting of each transaction for the same relationship requires acquiring a lock, and deadlock occurs if multiple transactions operate on the same relationship at the same time and wait for each other to release the lock. In current distributed data systems, the object lock logic is not always detected, and thus global deadlock is often encountered. To avoid such problems, it is common practice to increase the locking level of operations to ensure that transactions are run serially. This results in very poor performance of the system when executing multiple transactions because updates or deletions for only one transaction can be handled at a time on the same table. For example, most alter table statements will change the directory and affect the optimizer generation plan, so these alter table statements are not allowed to run concurrently with other statements operating the same table. In table 1 above, the alter table statement will hold an AccessExclusive lock on the table, while AccessExclusive is the highest locking level, conflicting with all locking levels.
In a common distributed data system, the lock level of operation statements, such as INSERT, DELETE, UPDATE, etc., is important in handling global deadlocks. The locking behavior of these operation statements is that, first, during the parse phase, the transaction locks the target table in some way; second, during execution, the transaction writes its identifier to the data. This is one way to lock data using a transaction lock. In a single-segment database where all data is stored on a single server or computer, the first phase will typically lock the target table in RowExclusive mode so that they can run concurrently, only when two transactions just write (UPDATE or DELETE) the same data, will one transaction wait on the transaction lock of the data until the other transaction commits or aborts. The lock levels and resulting dependencies of objects involved in each transaction are recorded by maintaining a lock dependency table, which is a table of dependencies that the lock produces when performing different operations. The lock dependency table may be stored in the shared memory of each segment instance and if a deadlock occurs, the lock information in the shared memory may be easily scanned to free it. However, this approach has serious drawbacks in the distributed architecture, even if each segment in the cluster has a local deadlock handling instance, if transaction waiting behavior occurs between different data segments, then the global deadlock problem cannot be avoided.
The partitioning and storage of data among different nodes in a distributed data system, a cluster is made up of a plurality of nodes, with a coordinator node and a plurality of working nodes, each working node can be considered as a segment, which are responsible for storing data and executing a particular query plan. The division of the segments may be based on factors such as the amount of data, the type of data, the data distribution pattern, etc., to achieve balanced distribution and efficient access of the data. As shown in fig. 6, the database segment ID includes segment 0 and segment 1, each of which stores a corresponding data set. Step 602, transaction a updates the data row of c1=2 in table t1 of segment 0 (implemented by the statement update t1 set..where c1=2), i.e., transaction a updates the data stored in segment 0 of the distributed data system, holding a transaction lock on segment 0; at step 604, transaction B updates the row of data for c1=1 in table t1 of segment 1 (implemented by the statement update t1 set..where c1=1), i.e., transaction B updates the data stored in segment 1, holding the transaction lock on segment 1. All so far perform well with no transaction waiting events occurring. Then, in step 606, transaction B updates the data line of c1=2 in table t1 of segment 0 (implemented by the statement update t1 set..where c1=2), i.e. transaction B updates the same data that transaction a just updated, because transaction a has not yet committed or aborted, transaction B must wait for the end of transaction a before execution can continue, i.e. transaction B waits for the transaction lock of segment 0, i.e. for the object lock of segment 0. At step 608, transaction a updates the data line of c1=1 in table t1 of segment 1 (implemented by the statement update t1 set..where c1=1), i.e. transaction a updates the data in segment 1 locked by transaction B, so transaction B must also wait for it to end before execution can continue, i.e. transaction a waits for the transaction lock of segment 1. At this point, on segment 0, transaction B is waiting for transaction A; on segment 1, transaction A is waiting for transaction B, none of which can take a step forward, which results in a global deadlock, although each instance has no local deadlock.
As shown in fig. 7, all segments, including the coordinator, involve global deadlocks. Specifically, the database segment ID includes segment 0 and segment 1, each of which stores a respective data set. At step 702, transaction a UPDATEs the value of field c2 in the data row of c1=2 in table t1 to 10 (implemented by the statement UPDATE t1 set..c2=10where c1=2), i.e. transaction a locks the data in table t1 in segment 0 by the UPDATE statement, c1=2. At step 704, transaction B UPDATEs the value of field c2 in the data row of c1=1 in table t1 to 20 (implemented by the statement UPDATE t1 set..c2=20where c1=1), i.e. transaction B locks the data in table t1 in segment 1 by the UPDATE statement, c1=1. At step 706, transaction C LOCKs t2, i.e., transaction C LOCKs table t2 in the coordinator and all segments via the LOCK statement. At step 708, transaction C updates the value of field C2 in the data row of c1=2 in table t1 to 30 (implemented by the statement update t1 set..c2=30where c1=2), i.e. transaction C tries to acquire a lock of the data of c1=2 in table t1 on segment 0, but the lock is already locked by transaction a, so transaction C waits. At step 710, transaction a updates the value of field c2 in the data line of c1=1 in table t1 to 10 (implemented by the statement update t1 set..c2=10where c1=1), i.e. transaction a tries to lock the data of c1=1 in table t1 on segment 1, but the lock has been locked by transaction B, so transaction a waits. At step 712, transaction D UPDATEs the value of field c2 in the data row of c1=3 in table t1 to 50 (implemented by the statement UPDATE t1 set.) c2=50where c1=3, i.e. transaction D locks the data of c1=3 in table t1 in segment 0 by the UPDATE statement. At step 714, transaction D LOCKs t2, i.e., transaction D continues to attempt to LOCK table t2 on the coordinator via the LOCK statement, but it will continue to wait because transaction C holds the LOCK on t2. At step 716, transaction B updates the value of field c2 in the data line of c1=3 in table t1 to 40 (implemented by the statement update t1 set..c2=40where c1=3), i.e. transaction B continues to try to lock the data of c1=3 in table t1 on segment 0, but it is locked by transaction D and will therefore also continue to wait. At this point, on segment 1, transaction A is waiting for transaction B; transaction B is waiting for transaction D on segment 0; at the coordinator, transaction D is waiting for transaction C; on segment 0, transaction C is waiting for transaction A; global deadlock thus occurs.
To address such issues, conventional generic distributed data systems do so by using exclusive mode locking for the target table during the SQL (Structured Query Language ) parsing phase in the coordinator, so that transactions executing UPDATE or DELETE are actually running in series, avoiding global deadlocks. However, this approach may result in very poor performance of the distributed data system to handle high concurrency transactions, because even if two transactions actually update different data, the same tables are not allowed to be written at the same time. While for network deadlocks, it is not a problem for OLTP workload and is not considered.
Based on the above, in order to solve the global deadlock problem, the present embodiment provides a global deadlock detection method, specifically, starting a daemon on a coordinator segment; the daemon periodically collects the wait pattern on each segment; the daemon checks if global deadlock occurs; the daemon uses a predefined policy to break global deadlocks, such as terminating the youngest transaction. The global deadlock detection method requires accuracy and integrity, and if it reports a global deadlock, the global deadlock does exist in the data system. The deadlock detection daemon gathers the local latency graph (including the coordinator) for each segment and builds a global latency graph, which is a set of local latency directed graphs, each vertex representing a transaction, from which edges point to holding transactions. For each vertex representing a transaction, its number of outgoing edges is the number of all edges that the vertex points to the other points, and the number of incoming edges is the number of all edges that point to the vertex. The locality of a vertex is the edge value calculated in the wait map for only a single segment. The global degree of a vertex is the sum of the local degrees on all segments of the fixed point. Using deg (G) (V) to represent the global emittance of vertex V, deg (V) to represent the local emittance of vertex V in segment i. As in fig. 7, deg (G) (C) =1 because there is one edge from C to a in segment 0, deg1 (C) =0 because there is no edge from C in segment 1. The waiting information collected from each segment is asynchronous and the delay cannot be ignored in analyzing the information in the coordinator.
There are two different edge symbols in the global standby graph, including strong relationship edges and weak edges. Wherein for strong relationship edges, the wait only disappears after the lock hold transaction ends (commit or abort). A table lock on the target table in an UPDATE or DELETE statement is a typical case, which can only be released at the end of a transaction, and the edge can only be deleted if the holding transaction is not blocked, based on greedy rules, it can be assumed that the holding transaction will end and release all object locks it holds. I.e. if a certain transaction holds a lock and cannot complete its operation due to a blocked lock of other transactions, then it can only be executed if the transaction has completed and released the lock it holds in all other transactions. Any transaction will complete as soon as possible and release its held lock according to greedy rules, so that other transactions can acquire the required lock and continue execution.
For a weakened edge, it is indicated that a lock holding transaction may release the lock even if the transaction is not ended. For example, a data lock held before the data content is modified during execution of a low-level delete or update operation. Such edges can only be deleted if the holding transaction is not blocked by others in a particular segment. Based on greedy rules, it may be assumed that a hold transaction will release a lock that prevents waiting for the transaction without committing or aborting. A weak relationship edge is a transaction that allows a lock to be released even if the transaction is not completed, such as when a delete or update operation is performed, the transaction holds the lock prior to modifying the data content. Transactions that perform delete or update operations will first establish a lock on the target table prior to the operation, i.e., the "parameter-analyze" resolution phase. Then during the execution phase, the transaction will write its identifier into the data line, locking the data line. The "parameter-analysis" parsing stage refers to a stage of parsing user input commands in a database management system and performing syntax and semantic verification on the user input commands. At this stage, the system checks the command for legitimacy and converts it into an internal data structure for subsequent processing.
The most important idea in the deadlock detection method is greedy rules, and the deadlock detection method keeps deleting weakened edges which are likely to continue to run. When a weakened edge cannot be deleted any more, a global deadlock may occur if there are still any other edges. In that case, the detection daemon will lock all processes in the coordinator to check whether all the remaining edges are still valid. If some transactions have completed, such as terminated or committed, the deadlock detection daemon will simply discard all information, call the sleeping program, and continue the global deadlock detection work in the next round.
With regard to the processing flow of deadlock detection, as shown below, after the global wait diagram G is constructed,
/>
specifically, in each cycle, it first deletes all vertices with global degree zero, and then scans each local waiting graph to delete all weakened edges pointing to vertices with local degree zero. Deadlock detection is a greedy algorithm, in other words, if it is possible to let lock-holding transactions continue executing, always assuming that they will eventually release all locks they hold. Specifically, all edges of the vertex with global degree 0 in the global graph can be deleted because the existence of the edges is meaningless, the vertex with global degree 0 has no waiting relation to be satisfied, so the edges connected with the vertex with global degree 0 also lose the function, and the edges can be safely deleted without influencing the deadlock detection result. At the same time, all local out-of-0 weakened edges in the local map can be deleted because this type of edges represent that a locked transaction can release the lock without ending the transaction, while not being blocked by other transactions, and therefore can be safely deleted without causing a deadlock. The enhanced edge cannot be deleted in the local map because the local degree of departure is 0 in the local map, and there will not be any waiting relationship to be satisfied without representing the vertices, and there may be waiting relationships in other local maps.
For the deadlock situation shown in fig. 7, by the deadlock detection method provided in this embodiment, it may be determined that there is no vertex with a global degree of zero in the waiting diagram, so that any edge is not deleted in the first round, there is no weakened edge in each segment, and any edge cannot be deleted in the second round. The wait diagram is the final state, which contains global loops, meaning that global deadlocks occur.
As shown in fig. 8, the database segment ID includes segment 0 and segment 1, each of which stores a corresponding data set. At step 802, transaction a UPDATEs the value of field c2 in the data row of c1=3 in table t1 to 10 (implemented by the statement UPDATE t1 set..c2=10where c1=3), i.e. transaction a locks the data in table t1 in slice segment 0 to c1=3 using the UPDATE statement. At step 804, transaction C UPDATEs the value of field C2 in the data row of c1=1 in table t1 to 30 (implemented by the statement UPDATE t1 set..c2=30where c1=1), i.e. transaction C locks the data in table t1 in fragment 1 using the UPDATE statement to c1=1. At step 806, transaction B806 updates the value of field C2 in the data row of c1=1 or c2=3 in table t1 to 20 (implemented by the statement update t1 set.) c2=20where c1=1or c2=3), i.e. transaction B attempts to lock the data in table t1 containing c1=1 or c1=3, is blocked by transaction a on segment 0 and by transaction C on segment 1. At step 808, transaction a updates the value of field c2 in the data row of c1=1 in table t1 to 10 (implemented by the statement update t1 set..c2=10where c1=1), i.e. transaction a attempts to lock the data in table t1 containing c1=1 in slice segment 1, blocked by the data lock held by transaction B on slice segment 1.
Further, based on the deadlock detection method provided in the present embodiment, deadlock detection is performed with respect to the example shown in fig. 8. As shown in fig. 9, first, in fig. 9 a, that is, in the original waiting diagram, we can find that deg (G) (C) =0, according to the deadlock detection method, we can delete vertex C and all its edges, and we can get b diagram after this step is performed. Next, in fig. 9B, no vertex satisfies deg (G) (v) =0, the local departure is checked and deg1 (B) =0 is found, according to the deadlock detection algorithm, all weakened edges pointing to B in segment 1 can be deleted, and after this step is performed, a c-graph is obtained. Then, in figure 9 c, we find deg (G) (a) =0, all edges pointing to a can be deleted, with the result that figure 9 d, i.e. finally no edges remain, so the deadlock detection algorithm will report that there is no deadlock in this case.
The deadlock detection method provided by the embodiment is dependent on the following final state attribute: any edge cannot be deleted any more, and the global waiting diagram is not changed any more; all transactions of the global wait map still exist. Combining the two properties, one can conclude that: the final weakened edge is up to date. According to the deletion policy, if the final transaction waiting diagram contains loops, then a global deadlock may occur. If a global deadlock occurs, the global wait diagram must contain one cycle by definition and no further transactions can be executed in the diagram. The deadlock detection algorithm cannot delete these edges and therefore will report a global deadlock. The deadlock detection algorithm is complete. Detecting a global deadlock unlocks the youngest vertex and ends its transaction, breaking the global deadlock. After enabling deadlock detection, the lock level performance of UPDATE and INSERT may be significantly degraded compared to the previous performance. Transactions that update or delete the same table may run in parallel. The deadlock detection daemon only periodically executes a simple call to acquire a wait chart from a segment, so it does not consume too much resources in the cluster.
It should be understood that, although the steps in the flowcharts related to the embodiments described above are sequentially shown as indicated by arrows, these steps are not necessarily sequentially performed in the order indicated by the arrows. The steps are not strictly limited to the order of execution unless explicitly recited herein, and the steps may be executed in other orders. Moreover, at least some of the steps in the flowcharts described in the above embodiments may include a plurality of steps or a plurality of stages, which are not necessarily performed at the same time, but may be performed at different times, and the order of the steps or stages is not necessarily performed sequentially, but may be performed alternately or alternately with at least some of the other steps or stages.
Based on the same inventive concept, the embodiment of the application also provides a deadlock detection device for realizing the above-mentioned deadlock detection method. The implementation of the solution provided by the device is similar to the implementation described in the above method, so the specific limitation in the embodiment of one or more deadlock detection devices provided below may be referred to the limitation of the deadlock detection method hereinabove, and will not be repeated here.
In one embodiment, as shown in fig. 10, there is provided a deadlock detection apparatus 1000, comprising: a local wait information acquisition module 1002, a global update module 1004, a local update module 1006, and a wait information processing module 1008, wherein:
a local waiting information obtaining module 1002, configured to obtain local waiting information of each of at least two database nodes; each local wait information includes object lock wait information between transactions in the affiliated database node;
the global updating module 1004 is configured to filter, from the local waiting information, object lock waiting information associated with a global non-waiting transaction, and obtain local waiting information after global updating; globally non-waiting transactions, which are transactions that do not wait for an object lock in at least two database nodes;
the local update module 1006 is configured to, for each piece of globally updated local waiting information, filter, from the globally updated local waiting information, the object lock waiting information associated with the local non-waiting transaction when the object lock support held by the local non-waiting transaction in the globally updated local waiting information is pre-released, and obtain the locally updated local waiting information; the local non-waiting transaction is a transaction which does not wait for an object lock in a database node to which the global updated local waiting information belongs;
And the waiting information processing module 1008 is configured to perform global deadlock detection on at least two database nodes based on the local waiting information after each local update, so as to obtain a global deadlock detection result.
In one embodiment, the global update module 1004 is further configured to determine, based on each local wait information, a global non-waiting transaction in at least two database nodes; and filtering the object lock waiting information associated with the global non-waiting transaction from the local waiting information to obtain the global updated local waiting information.
In one embodiment, the local wait information includes a local wait map; the vertices in the local wait-for graph characterize transactions triggered in the affiliated database node; the directed edges in the local wait graph point from the vertices of the wait transaction that characterize the object lock to the vertices of the hold transaction that characterize the object lock; the global updating module 1004 is further configured to compose a global waiting diagram of at least two database nodes according to each local waiting diagram, and determine respective global output degrees of each vertex in the global waiting diagram; the global degree is obtained according to the sum of the local degrees of the vertexes; the local degree is used for representing the number of directed edges of the vertex, which are directed to other vertices, in the local waiting diagram to which the vertex belongs; according to the global degree of each vertex, determining a global zero degree vertex with the global degree of zero in a global waiting diagram; deleting global zero-degree vertexes and directed edges pointing to the global zero-degree vertexes in each local waiting diagram respectively to obtain each global updated local waiting diagram; and obtaining the local waiting information after global updating according to the local waiting map after global updating.
In one embodiment, the local update module 1006 is further configured to determine that the transaction is not locally waiting based on the targeted globally updated local wait information; the local non-waiting transaction is a transaction in which the object lock is not waiting in the local database node; the local database node is the database node to which the local waiting information subjected to global updating belongs; and when the object lock held by the local non-waiting transaction supports pre-release, filtering the object lock waiting information associated with the local non-waiting transaction from the local waiting information subjected to global updating, and obtaining the local waiting information subjected to local updating.
In one embodiment, the local wait information includes a local wait map; the vertices in the local wait-for graph characterize transactions triggered in the affiliated database node; the directed edges in the local wait graph point from the vertices of the wait transaction that characterize the object lock to the vertices of the hold transaction that characterize the object lock; the globally updated local waiting information comprises a local waiting diagram after global updating; the local update module 1006 is further configured to determine respective local disciplines of each vertex in the local wait map after the global update; the local degree is used for representing the number of directed edges of the vertex, which are directed to other vertices, in the local waiting diagram to which the vertex belongs; according to the local degree of each vertex, determining a local zero degree vertex with zero local degree of degree in the local waiting diagram after the global updating; when the object lock support pre-release of the transaction represented by the local zero-degree vertex is carried out, deleting the directed edge pointing to the local zero-degree vertex from the local waiting diagram after the global updating, and obtaining the local waiting diagram after the local updating; and obtaining the local waiting information after the local update according to the local waiting diagram after the local update.
In one embodiment, the local update module 1006 is further configured to determine, in the local wait diagram after the global update, a directed edge to be filtered pointing to the local zero-degree vertex; the directed edge to be filtered represents the object lock support pre-release which is represented by the transaction held by the local zero-degree vertex; and deleting the directed edges to be filtered from the local waiting diagram after the global updating, and obtaining the local waiting diagram after the local updating.
In one embodiment, the local update module 1006 is further configured to determine a transaction type of the local non-waiting transaction and a transaction execution state in which the local non-waiting transaction is located; when the transaction type belongs to the pre-release transaction type and the transaction execution state indicates that the local object lock which is not held by the transaction supports pre-release, filtering the object lock waiting information associated with the local non-waiting transaction from the local waiting information which is updated globally, and obtaining the local waiting information after the local update.
In one embodiment, the waiting information processing module 1008 is further configured to, when the target global updated local waiting information does not support pre-release of an object lock held by a local non-waiting transaction of the local non-waiting object lock in the database node to which the target global updated local waiting information belongs, perform global deadlock detection on at least two database nodes through the target global updated local waiting information, and obtain a global deadlock detection result.
In one embodiment, the waiting information processing module 1008 is further configured to detect an object lock relationship between transactions in at least two database nodes based on the local waiting information after each local update, to obtain an object lock relationship detection result; and when the object lock relation detection result indicates that the transaction waiting for the object lock exists in at least two database nodes, obtaining a global deadlock detection result indicating that the global deadlock exists in at least two database nodes.
In one embodiment, the system further comprises a period detection module, configured to obtain a global deadlock detection result, where the global deadlock detection result indicates that at least two database nodes do not have a global deadlock in the current deadlock detection period, when the object lock relation detection result indicates that there is no transaction waiting for the object lock in the at least two database nodes; and when the next deadlock detection period is reached, global deadlock detection processing of the next deadlock detection period is performed for at least two database nodes.
In one embodiment, the system further comprises a deadlock release module, configured to determine a deadlock associated transaction in which a global deadlock exists in at least two database nodes when the global deadlock detection result indicates that the global deadlock exists in at least two database nodes; and determining release transactions from the deadlock associated transactions according to the deadlock release strategy, and terminating the release transactions.
In one embodiment, at least two database nodes belong to nodes in a distributed database; the deadlock detection method is performed by a coordinator node in the distributed database.
The various modules in the deadlock detection device described above may be implemented in whole or in part by software, hardware, and combinations thereof. The above modules may be embedded in hardware or may be independent of a processor in the computer device, or may be stored in software in a memory in the computer device, so that the processor may call and execute operations corresponding to the above modules.
In one embodiment, a computer device is provided, which may be a server or a terminal, and the internal structure thereof may be as shown in fig. 11. The computer device includes a processor, a memory, an Input/Output interface (I/O) and a communication interface. The processor, the memory and the input/output interface are connected through a system bus, and the communication interface is connected to the system bus through the input/output interface. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The database of the computer device is used for storing data related to the deadlock detection method. The input/output interface of the computer device is used to exchange information between the processor and the external device. The communication interface of the computer device is used for communicating with an external terminal through a network connection. The computer program, when executed by a processor, implements a deadlock detection method.
It will be appreciated by those skilled in the art that the structure shown in FIG. 11 is merely a block diagram of some of the structures associated with the present inventive arrangements and is not limiting of the computer device to which the present inventive arrangements may be applied, and that a particular computer device may include more or fewer components than shown, or may combine some of the components, or have a different arrangement of components.
In an embodiment, there is also provided a computer device comprising a memory and a processor, the memory having stored therein a computer program, the processor implementing the steps of the method embodiments described above when the computer program is executed.
In one embodiment, a computer-readable storage medium is provided, storing a computer program which, when executed by a processor, implements the steps of the method embodiments described above.
In an embodiment, a computer program product is provided, comprising a computer program which, when executed by a processor, implements the steps of the method embodiments described above.
It should be noted that, the user information (including but not limited to user equipment information, user personal information, etc.) and the data (including but not limited to data for analysis, stored data, presented data, etc.) related to the present application are information and data authorized by the user or sufficiently authorized by each party, and the collection, use and processing of the related data need to comply with the related laws and regulations and standards of the related country and region.
Those skilled in the art will appreciate that implementing all or part of the above described methods may be accomplished by way of a computer program stored on a non-transitory computer readable storage medium, which when executed, may comprise the steps of the embodiments of the methods described above. Any reference to memory, database, or other medium used in embodiments provided herein may include at least one of non-volatile and volatile memory. The nonvolatile Memory may include Read-Only Memory (ROM), magnetic tape, floppy disk, flash Memory, optical Memory, high density embedded nonvolatile Memory, resistive random access Memory (ReRAM), magnetic random access Memory (Magnetoresistive Random Access Memory, MRAM), ferroelectric Memory (Ferroelectric Random Access Memory, FRAM), phase change Memory (Phase Change Memory, PCM), graphene Memory, and the like. Volatile memory can include random access memory (Random Access Memory, RAM) or external cache memory, and the like. By way of illustration, and not limitation, RAM can be in the form of a variety of forms, such as static random access memory (Static Random Access Memory, SRAM) or dynamic random access memory (Dynamic Random Access Memory, DRAM), and the like. The databases referred to in the embodiments provided herein may include at least one of a relational database and a non-relational database. The non-relational database may include, but is not limited to, a blockchain-based distributed database, and the like. The processor referred to in the embodiments provided in the present application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic unit, a data processing logic unit based on quantum computing, or the like, but is not limited thereto.
The technical features of the above embodiments may be arbitrarily combined, and all possible combinations of the technical features in the above embodiments are not described for brevity of description, however, as long as there is no contradiction between the combinations of the technical features, they should be considered as the scope of the description.
The foregoing examples illustrate only a few embodiments of the application and are described in detail herein without thereby limiting the scope of the application. It should be noted that it will be apparent to those skilled in the art that several variations and modifications can be made without departing from the spirit of the application, which are all within the scope of the application. Accordingly, the scope of the application should be assessed as that of the appended claims.

Claims (16)

1. A method of deadlock detection, the method comprising:
acquiring local waiting information of each of at least two database nodes; each local wait information includes object lock wait information between transactions in the affiliated database node;
filtering the object lock waiting information associated with the global non-waiting transaction from the local waiting information to obtain the local waiting information after global updating; the global non-waiting transaction is a transaction that does not wait for an object lock in the at least two database nodes;
For each piece of globally updated local waiting information, when the object lock support held by the local non-waiting transaction in the globally updated local waiting information is pre-released, filtering the object lock waiting information associated with the local non-waiting transaction from the globally updated local waiting information to obtain the locally updated local waiting information; the local non-waiting transaction is a transaction which does not wait for an object lock in a database node to which the globally updated local waiting information belongs;
and performing global deadlock detection on the at least two database nodes based on the local waiting information after each local update to obtain a global deadlock detection result.
2. The method of claim 1, wherein filtering the object lock wait information associated with the globally non-waiting transaction from each local wait information to obtain each globally updated local wait information comprises:
determining global non-waiting transactions in the at least two database nodes based on each of the local waiting information;
and filtering the object lock waiting information associated with the global non-waiting transaction from the local waiting information to obtain the local waiting information after global updating.
3. The method of claim 2, wherein the local wait information comprises a local wait map; the vertex in the local wait diagram characterizes the transaction triggered in the affiliated database node; the directed edge in the local wait graph points from the vertex of the wait transaction that characterizes the object lock to the vertex of the hold transaction that characterizes the object lock;
the determining, based on each of the local wait information, a global non-waiting transaction in the at least two database nodes, comprising:
forming a global waiting diagram of the at least two database nodes according to each local waiting diagram, and determining respective global degree of each vertex in the global waiting diagram; the global degree is obtained according to the sum of local degrees of the vertexes; the local degree is used for representing the number of directed edges of the vertex, which are directed to other vertices, in the local waiting diagram to which the vertex belongs;
according to the global degree of each vertex, determining a global zero degree vertex with the global degree of zero in the global waiting diagram;
filtering the object lock waiting information associated with the global non-waiting transaction from the local waiting information to obtain local waiting information after global updating, including:
Deleting the global zero degree vertex and the directed edge pointing to the global zero degree vertex in each local waiting diagram respectively to obtain each globally updated local waiting diagram;
and obtaining the local waiting information after global updating according to the local waiting map after global updating.
4. The method according to claim 1, wherein when the object lock held by the local non-waiting transaction in the globally updated local waiting information supports pre-release, filtering the object lock waiting information associated with the local non-waiting transaction from the globally updated local waiting information to obtain the locally updated local waiting information, including:
determining that a transaction is not locally waited based on the targeted globally updated local wait information; the local non-waiting transaction is a transaction in the local database node that does not wait for an object lock; the local database node is the database node to which the local waiting information subjected to global updating belongs;
and when the object lock supported by the local non-waiting transaction is pre-released, filtering the object lock waiting information associated with the local non-waiting transaction from the targeted global updated local waiting information to obtain the local updated local waiting information.
5. The method of claim 4, wherein the local wait information comprises a local wait map; the vertex in the local wait diagram characterizes the transaction triggered in the affiliated database node; the directed edge in the local wait graph points from the vertex of the wait transaction that characterizes the object lock to the vertex of the hold transaction that characterizes the object lock; the globally updated local waiting information comprises a local waiting diagram after global updating;
the determining that the transaction is not locally waited based on the targeted global updated local wait information comprises:
determining respective local discharges of each vertex in the local waiting diagram after global updating; the local degree is used for representing the number of directed edges of the vertex, which are directed to other vertices, in the local waiting diagram to which the vertex belongs;
according to the local degree of each vertex, determining a local zero degree vertex with zero local degree of degree in the local waiting diagram after the global updating;
and when the object lock held by the local non-waiting transaction supports pre-release, filtering the object lock waiting information associated with the local non-waiting transaction from the targeted global updated local waiting information to obtain local updated local waiting information, wherein the method comprises the following steps:
When the object lock support held by the transaction represented by the local zero-degree vertex is pre-released, deleting the directed edge pointing to the local zero-degree vertex from the local waiting diagram subjected to the targeted global update, and obtaining the local waiting diagram subjected to the local update;
and obtaining the local waiting information after local updating according to the local waiting diagram after local updating.
6. The method of claim 5, wherein the object lock held by the transaction when characterized by the local zero-degree vertex supports pre-release, deleting a directed edge pointing to the local zero-degree vertex in the local wait for graph for the global update, obtaining a local updated local wait for graph, comprising:
determining directed edges to be filtered pointing to the local zero-degree vertex in the local waiting diagram after the targeted global updating; the directed edges to be filtered represent object locks supported pre-release of transactions represented by the local zero degree vertices;
and deleting the directed edges to be filtered from the local waiting diagram subjected to the global updating to obtain the local waiting diagram subjected to the local updating.
7. The method of claim 4, wherein filtering the object lock wait information associated with the local non-waiting transaction from the targeted globally updated local wait information while the object lock held by the local non-waiting transaction supports pre-release, comprises:
Determining the transaction type of the local non-waiting transaction and the transaction execution state;
and when the transaction type belongs to a pre-release transaction type and the transaction execution state indicates that the local object lock which is not held by the transaction supports pre-release, filtering the object lock waiting information associated with the local non-waiting transaction from the local waiting information which is updated globally to obtain the local waiting information which is updated locally.
8. The method according to claim 1, wherein the method further comprises:
and when the target global updated local waiting information does not support pre-release of the object lock held by the local non-waiting transaction of the target global updated local waiting information in the database nodes to which the target global updated local waiting information belongs, performing global deadlock detection on the at least two database nodes through the target global updated local waiting information to obtain a global deadlock detection result.
9. The method according to claim 1, wherein the performing global deadlock detection on the at least two database nodes based on the local waiting information after each local update to obtain a global deadlock detection result includes:
detecting the object lock relation between the transactions in the at least two database nodes based on the local waiting information after each local update to obtain an object lock relation detection result;
And when the object lock relation detection result indicates that the transaction waiting for the object lock exists in the at least two database nodes, obtaining a global deadlock detection result indicating that the global deadlock exists in the at least two database nodes.
10. The method according to claim 9, wherein the method further comprises:
when the object lock relation detection result indicates that no transaction waiting for the object lock exists in the at least two database nodes, a global deadlock detection result is obtained, wherein the global deadlock detection result indicates that the at least two database nodes do not have global deadlock in the current deadlock detection period;
and when the next deadlock detection period is reached, global deadlock detection processing of the next deadlock detection period is carried out for the at least two database nodes.
11. The method according to any one of claims 1 to 10, further comprising:
when the global deadlock detection result indicates that global deadlock exists in the at least two database nodes, determining that a deadlock associated transaction of the global deadlock exists in the at least two database nodes;
and determining release transactions from the deadlock related transactions according to a deadlock release strategy, and terminating the release transactions.
12. The method according to any of claims 1 to 10, wherein the at least two database nodes belong to nodes in a distributed database; the deadlock detection method is performed by a coordinator node in the distributed database.
13. A deadlock detection device, the device comprising:
the local waiting information acquisition module is used for acquiring the local waiting information of each of at least two database nodes; each local wait information includes object lock wait information between transactions in the affiliated database node;
the global updating module is used for filtering the object lock waiting information associated with the global non-waiting transaction from the local waiting information to obtain the local waiting information after global updating; the global non-waiting transaction is a transaction that does not wait for an object lock in the at least two database nodes;
the local updating module is used for aiming at each piece of globally updated local waiting information, when the object lock support held by the local non-waiting transaction in the aimed globally updated local waiting information is released in advance, filtering the object lock waiting information associated with the local non-waiting transaction from the globally updated local waiting information to obtain the locally updated local waiting information; the local non-waiting transaction is a transaction which does not wait for an object lock in a database node to which the globally updated local waiting information belongs;
And the waiting information processing module is used for carrying out global deadlock detection on the at least two database nodes based on the local waiting information after each local update to obtain a global deadlock detection result.
14. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that the processor implements the steps of the method of any one of claims 1 to 12 when the computer program is executed.
15. A computer readable storage medium, on which a computer program is stored, characterized in that the computer program, when being executed by a processor, implements the steps of the method of any of claims 1 to 12.
16. A computer program product comprising a computer program, characterized in that the computer program, when being executed by a processor, implements the steps of the method of any one of claims 1 to 12.
CN202310641177.9A 2023-05-31 2023-05-31 Deadlock detection method, device, computer equipment and storage medium Pending CN116974775A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310641177.9A CN116974775A (en) 2023-05-31 2023-05-31 Deadlock detection method, device, computer equipment and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310641177.9A CN116974775A (en) 2023-05-31 2023-05-31 Deadlock detection method, device, computer equipment and storage medium

Publications (1)

Publication Number Publication Date
CN116974775A true CN116974775A (en) 2023-10-31

Family

ID=88477492

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310641177.9A Pending CN116974775A (en) 2023-05-31 2023-05-31 Deadlock detection method, device, computer equipment and storage medium

Country Status (1)

Country Link
CN (1) CN116974775A (en)

Similar Documents

Publication Publication Date Title
Bailis et al. Scalable atomic visibility with RAMP transactions
CN105630860B (en) Database system with transaction control block index
CN105630865B (en) N-bit compressed versioned column data array for memory columnar storage
AU2016244128B2 (en) Processing database transactions in a distributed computing system
Lindström et al. IBM solidDB: In-Memory Database Optimized for Extreme Speed and Availability.
US8364909B2 (en) Determining a conflict in accessing shared resources using a reduced number of cycles
US20160147750A1 (en) Versioned Insert Only Hash Table for In-Memory Columnar Stores
US20130227194A1 (en) Active non-volatile memory post-processing
US9576038B1 (en) Consistent query of local indexes
US20140372374A1 (en) Difference determination in a database environment
US11698893B2 (en) System and method for use of lock-less techniques with a multidimensional database
Zamanian et al. Chiller: Contention-centric transaction execution and data partitioning for modern networks
Turcu et al. Automated data partitioning for highly scalable and strongly consistent transactions
US9971822B1 (en) Replicated state management using journal-based registers
US10747749B2 (en) Methods and systems for managing distributed concurrent data updates of business objects
US11080261B2 (en) Hybrid concurrency control
US9390111B2 (en) Database insert with deferred materialization
Wongkham et al. Are updatable learned indexes ready?
Shetty et al. Growth of relational model: Interdependence and complementary to big data
CN111949673B (en) Hbase storage-based distributed pessimistic lock and implementation method thereof
CN116974775A (en) Deadlock detection method, device, computer equipment and storage medium
Lee et al. Hierarchical Quadrant Spatial LSM Tree for Indexing Blockchain-based Geospatial Point Data
Kvet et al. Enhancing Analytical Select Statements Using Reference Aliases
Kvet Dangling predicates and function call optimization in the Oracle database
Zhang et al. Brief announcement: on enhancing concurrency in distributed transactional memory

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication