Transaction replay method and apparatus

Abstract

Embodiments of the present specification provide a transaction playback method and device, wherein the transaction playback method comprises: obtaining a to-be-playback transaction and a start timestamp of the to-be-playback transaction; determining a first target queue to which the to-be-playback transaction is to be inserted; and in a case where the start timestamp of the to-be-playback transaction is not greater than a specified commit timestamp of a second target queue, inserting the to-be-playback transaction into the first target queue for playback, wherein the second target queue and the first target queue respectively record transactions for playback and commit timestamps of the transactions, and transactions between the second target queue and the first target queue are played back in parallel. The present scheme can improve the efficiency of transaction playback.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of database technology, and in particular to a transaction replay method. Background Technology

[0002] Logical replication is a method for copying objects and their changes, widely used in scenarios such as master-slave database replication, online data migration in distributed databases, and online database upgrades. In these scenarios, the operations used to modify objects can be transactions: a unit of program execution that accesses and updates data items in the database. For example, in relational databases, a transaction can be a single Structured Query Language (SQL) statement, a group of SQL statements, or an entire program. Therefore, changes to the replicated object can include: acquiring the transaction for the replicated object, replaying the acquired transaction for the replicated object, and committing the transaction upon completion of the replay.

[0003] In practical applications, logical replication often involves multiple transactions. Furthermore, read-write dependencies may exist between different transactions: one transaction can only be replayed after another transaction has finished replaying. To address this, multiple transactions are typically replayed serially. However, in the database application scenarios described above, there are usually a large number of concurrent transactions, and this serial replay method can easily lead to a significant decrease in transaction replay efficiency. Therefore, a faster solution is needed. Summary of the Invention

[0004] In view of this, embodiments of this specification provide a transaction replay method. One or more embodiments of this specification also relate to a transaction replay apparatus, a computing device, a computer-readable storage medium, and a computer program to address the technical deficiencies existing in the prior art.

[0005] According to a first aspect of the embodiments of this specification, a transaction replay method is provided, comprising:

[0006] Obtain the transaction to be replayed and the start timestamp of the transaction to be replayed;

[0007] A first target queue is determined to be inserted into the transaction to be replayed, wherein the transactions recorded in the first target queue have a serial replay execution relationship with the transaction to be replayed;

[0008] If the start timestamp of the transaction to be replayed is not greater than the specified commit timestamp of the second target queue, the transaction to be replayed is inserted into the first target queue for replay. The second target queue and the first target queue respectively record the transaction to be replayed and the commit timestamp of the transaction. Transactions between the second target queue and the first target queue are replayed in parallel.

[0009] Optionally, the specified commit timestamp includes: the commit timestamps of all transactions in the second target queue that have not been replayed;

[0010] The step of inserting the transaction to be replayed into the first target queue for replay when the start timestamp of the transaction to be replayed is not greater than the specified commit timestamp of the second target queue includes:

[0011] Compare the start timestamp of the transaction to be replayed with the commit timestamps of all unreplayed transactions in the second target queue.

[0012] If the start timestamp of the transaction to be replayed is not greater than the commit timestamp of all transactions in the second target queue that have not been replayed, then the transaction to be replayed will be inserted into the first target queue for replay.

[0013] Optionally, after comparing the start timestamp of the transaction to be replayed with the commit timestamps of all incomplete replay transactions in the second target queue, the method further includes:

[0014] If the commit timestamp of a first transaction that has not been replayed in the second target queue is less than the start timestamp of the transaction to be replayed, then wait for the first transaction to be replayed.

[0015] Optionally, the specified commit timestamp is: the minimum commit timestamp of the transactions in the second target queue that have not been replayed;

[0016] The step of inserting the transaction to be replayed into the first target queue for replay when the start timestamp of the transaction to be replayed is not greater than the specified commit timestamp of the second target queue includes:

[0017] Compare the start timestamp of the transaction to be replayed with the minimum commit timestamp;

[0018] If the start timestamp of the transaction to be replayed is not greater than the minimum commit timestamp, then the transaction to be replayed is inserted into the first target queue for replay.

[0019] Optionally, after comparing the start timestamp of the transaction to be replayed with the minimum commit timestamp, the method further includes:

[0020] If the start timestamp of the transaction to be replayed is greater than the minimum commit timestamp, then wait for the unreplayed transactions in the second target queue to be replayed.

[0021] Optionally, determining the first target queue to which the transaction to be replayed is to be inserted includes:

[0022] Obtain the target object identifier of the transaction to be replayed;

[0023] Find the first target queue corresponding to the target object identifier from each queue.

[0024] Optionally, after inserting the transaction to be replayed into the first target queue for replay, the method further includes:

[0025] If the transaction to be replayed is not replayed when the preset time threshold is reached, then the third target queue with the shortest total replay time is determined from the second target queue. The total replay time of any queue is the total time required for all unreplayed transactions in that queue to be replayed.

[0026] The transaction to be replayed is retrieved from the current first target queue and inserted into the third target queue.

[0027] Optionally, obtaining the transaction to be replayed includes:

[0028] Obtain the snapshot timestamp of the target object and the database log of the target object;

[0029] The database logs are parsed to obtain transactions whose commit timestamps are greater than or equal to the snapshot timestamps, which are then used as the transactions to be replayed.

[0030] Optionally, each transaction corresponds to a transaction identifier;

[0031] During the process of parsing the database logs of the target object, if abort information is obtained, the transaction identifier corresponding to the abort information is acquired.

[0032] Delete the transaction corresponding to the transaction identifier from the cache.

[0033] According to a second aspect of the embodiments of this specification, a transaction replay apparatus is provided, comprising:

[0034] The data acquisition module is configured to acquire the transaction to be replayed and the start timestamp of the transaction to be replayed;

[0035] The queue determination module is configured to determine the first target queue into which the transaction to be replayed is to be inserted, wherein the transactions recorded in the first target queue have a serial replay execution relationship with the transaction to be replayed;

[0036] The transaction replay module is configured to insert the transaction to be replayed into the first target queue for replay if the start timestamp of the transaction to be replayed is not greater than the specified commit timestamp of the second target queue. The second target queue and the first target queue respectively record the transaction to be replayed and the commit timestamp of the transaction. The transactions between the second target queue and the first target queue are replayed in parallel.

[0037] Optionally, the specified commit timestamp includes: the commit timestamps of all transactions in the second target queue that have not been replayed;

[0038] The transaction replay module is further configured as follows:

[0039] Compare the start timestamp of the transaction to be replayed with the commit timestamps of all unreplayed transactions in the second target queue.

[0040] If the start timestamp of the transaction to be replayed is not greater than the commit timestamp of all transactions in the second target queue that have not been replayed, then the transaction to be replayed will be inserted into the first target queue for replay.

[0041] Optionally, the transaction replay module is further configured to:

[0042] After comparing the start timestamp of the transaction to be replayed with the commit timestamps of all transactions in the second target queue that have not been replayed, if the commit timestamp of a first transaction in the second target queue that has not been replayed is less than the start timestamp of the transaction to be replayed, then wait for the first transaction to be replayed.

[0043] Optionally, the specified commit timestamp is: the minimum commit timestamp of the transactions in the second target queue that have not been replayed;

[0044] The transaction replay module is further configured as follows:

[0045] Compare the start timestamp of the transaction to be replayed with the minimum commit timestamp;

[0046] If the start timestamp of the transaction to be replayed is not greater than the minimum commit timestamp, then the transaction to be replayed is inserted into the first target queue for replay.

[0047] Optionally, the transaction replay module is further configured to:

[0048] After comparing the start timestamp of the transaction to be replayed with the minimum commit timestamp, if the start timestamp of the transaction to be replayed is greater than the minimum commit timestamp, then wait for the unreplayed transactions in the second target queue to be replayed.

[0049] Optionally, the transaction replay module is further configured to:

[0050] After inserting the transaction to be replayed into the first target queue for replay, if the transaction to be replayed is not replayed when the preset time threshold is reached, then the third target queue with the shortest total replay time is determined from the second target queue. The total replay time of any queue is the total time required for all unreplayed transactions in that queue to be replayed.

[0051] The transaction to be replayed is retrieved from the current first target queue and inserted into the third target queue.

[0052] According to a third aspect of the embodiments of this specification, a computing device is provided, comprising:

[0053] Memory and processor;

[0054] The memory is used to store computer-executable instructions, and the processor is used to implement any of the steps of the transaction replay method when executing the computer-executable instructions.

[0055] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores computer-executable instructions, which, when executed by a processor, implement the steps of any of the transaction replay methods described herein.

[0056] According to a fifth aspect of the embodiments of this specification, a computer program is provided, wherein when the computer program is executed in a computer, it causes the computer to perform the steps of the transaction replay method described above.

[0057] One embodiment of this specification implements the acquisition of the transaction to be replayed and its start timestamp; determines the first target queue into which the transaction to be replayed is to be inserted; and inserts the transaction to be replayed into the first target queue for replay if the start timestamp of the transaction to be replayed is not greater than the specified commit timestamp of the second target queue. The transactions recorded in the first target queue and the transaction to be replayed have a serial replay execution relationship; the second target queue and the first target queue respectively record the transaction to be replayed and its commit timestamp, and the transactions between the second target queue and the first target queue are replayed in parallel. Therefore, if the start timestamp of the transaction to be replayed is not greater than the specified commit timestamp of the second target queue, it indicates that the transaction to be replayed cannot see the transactions recorded in the second target queue, there is no read-write dependency between the transaction to be replayed and the transactions recorded in the second target queue, and the transaction to be replayed and the transactions recorded in the second target queue can be executed in parallel. Furthermore, the transactions between the second target queue and the first target queue are replayed in parallel. Therefore, inserting the transaction to be replayed into the first target queue for replay can ensure improved transaction replay efficiency. Furthermore, the transactions recorded in the first target queue have a serial replay execution relationship, which can guarantee that transactions with read-write dependencies can be executed accurately. Therefore, this solution can balance ensuring the accuracy of transaction replay and improving efficiency. Attached Figure Description

[0058] Figure 1 This is a flowchart illustrating the logical replication process;

[0059] Figure 2 This is a flowchart of a transaction replay method provided in one embodiment of this specification;

[0060] Figure 3 This is an example diagram illustrating the execution sequence of a transaction in a transaction replay method provided in one embodiment of this specification.

[0061] Figure 4 This is an example diagram illustrating the processing procedure of a transaction replay method applied to a destination node, provided in one embodiment of this specification.

[0062] Figure 5 This is a flowchart illustrating the processing procedure of a transaction replay method provided in one embodiment of this specification.

[0063] Figure 6 This is a schematic diagram of the structure of a transaction replay device provided in one embodiment of this specification;

[0064] Figure 7 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0065] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0066] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0067] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0068] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0069] A tuple is a table's "rows" stored in a database as "rows" and "columns" as "fields." Databases store table tuples and index entries in page format.

[0070] Multi-Version Concurrency Control (MVCC): In an MVCC database, a write transaction's modification of any row in a table creates a new version of the record, which is committed using the write transaction's commit timestamp. When another transaction, such as a read transaction, reads a record from the same table, it reads the version visible from the read transaction's start timestamp; that is, it reads the latest version of the record whose commit timestamp is less than the read transaction's start timestamp.

[0071] Snapshot Isolation (SI): A transaction can only see the changes made by another transaction that was committed before it began. To support snapshot isolation, a commit timestamp is assigned to a transaction at the start of the transaction and another commit timestamp is assigned when the transaction is committed. Therefore, transaction T1 can see the changes made by transaction T2 if and only if the start timestamp of transaction T1 is greater than the commit timestamp of transaction T2.

[0072] WAL (Write-ahead logging): A mechanism used by the database to write to the log first and then to the disk, which can ensure persistence and fault recovery.

[0073] Data Manipulation Language (DML) is a programming language that uses three core commands—INSERT (insert, update, and delete)—to perform operations on objects and data within a database.

[0074] Database Schema Definition Language (DDL): A language used to manipulate tables in a database, including creating, modifying, and deleting tables.

[0075] For ease of understanding, the following is based on this instruction manual. Figure 1 Using a flowchart as an example, the process of logical replication will be explained in detail. For instance, as shown... Figure 1 As shown, the example illustrates copying objects stored in one database (the sender) and transactions generated for those objects to another database (the receiver). The physical structures of the sender and receiver databases can be the same or different. The sender and receiver can belong to the same physical device, for example, two different virtual machines within the same computer; or, the sender and receiver can belong to different physical devices, for example, node n1 and node n2 respectively. Furthermore, when the sender and receiver are nodes, the sender can be called the source node, and the receiver can be called the destination node. Each node can specifically include one or more computing devices. All of these are valid. Specifically, the logical replication process can include the following steps in the following stages:

[0076] Phase 1 (not in) Figure 1(As shown in the diagram): When logical replication is determined to occur, the sending party generates a publication for one or more tables to be logically replicated and sends this publication to the receiving party. The receiving party subscribes to this publication, establishing a logical replication channel between the sending and receiving parties. Phases 2 and 3 of logical replication are performed through this channel. Furthermore, the receiving party receives the target object sent by the sending party, such as one or more tables to be logically replicated. The subsequent replay transactions in phases 2 and 3 correspond to the target objects. When replaying a transaction, the input to that transaction is the corresponding target object. For example, if the target object is record TP1, and the replay transaction T1 modifies a specified field in record TP1, then replaying transaction T1 may include calling a function to modify the specified field in record TP1.

[0077] Phase 2: The sender modifies the object to be logically replicated, generating a source transaction, and writes this source transaction to the database log. Therefore, when performing logical replication, the sender reads information about the source transaction from the database log, extracts specific information (key information) from the read information, and obtains the transaction to be replayed for logical replication; it performs insert, update, prepare, and commit processing on the transaction to be replayed, obtaining the data stream to be sent; and then sends the data stream to the receiver.

[0078] Phase 3: If the receiver decides to perform logical replication, it prepares for transaction replay. This preparation includes configuring the logical replication environment, starting threads, etc.; replaying the received transactions to be replayed; and writing the replay output to the table after completion.

[0079] Furthermore, in scenarios with high concurrency of transactions to be replayed sent by the sender, the transactions to be replayed on the receiver need to wait, resulting in a significant difference between the replayed transactions and the transactions generated by the sender. This leads to substantial replay lag, impacting the effectiveness of logical replication. Therefore, transaction replay efficiency is crucial for logical replication. To address this, transactions to be replayed that do not have read-write dependencies can be replayed in parallel.

[0080] For example, the RVID (After-update) of the current tuple version generated by each DML operation and the Before-update RVID of the previous version can be recorded. During logical replication, the RVID of the target object corresponding to the transaction to be replayed is sent to the receiver. When the receiver performs parallel replay of the transaction to be replayed, it first determines whether the transaction to be replayed is used to update or delete the target object. If it is, it checks whether the RVID of the target object corresponding to the transaction to be replayed is equal to the Before-update RVID. If it is not equal, it means that there is a transaction with a read-write dependency on the transaction to be replayed that has not yet been replayed. After sleeping for a period of time, the replay operation of the transaction to be replayed is retried until it is successfully replayed. If it is equal, the transaction to be replayed is added to the parallel replay transactions.

[0081] However, the overhead of sleep retries in the above parallel replay is relatively large: it requires sleeping for a certain period of time before retrying the replay operation, and it also requires determining whether the transaction to be replayed is used to update or delete the target object, wasting time and computing resources. Furthermore, setting the sleep time is not convenient: if the sleep time is short, repeatedly scanning and comparing versions can easily increase lock contention for the same table between different replay threads, reducing the replay speed of each thread. If the sleep time is set too long, it will significantly reduce the replay speed of replay threads that need to sleep.

[0082] In addition, the parallel playback described above will add extra storage overhead: an additional 8 bytes of RVID needs to be stored for each row in the table. Furthermore, each table needs to maintain an atomically incrementing sequence number to generate the RVID, and this sequence number needs to be persistent and fault-tolerant.

[0083] To provide a faster solution, this specification provides a transaction replay method, a transaction replay apparatus, a computing device, and a computer-readable storage medium, which are described in detail in the following embodiments.

[0084] Figure 2 A flowchart of a transaction replay method according to an embodiment of this specification is shown, which specifically includes the following steps.

[0085] S202, obtain the transaction to be replayed and the start timestamp of the transaction to be replayed.

[0086] In logical replication, a transaction to be replayed refers to a transaction sent from the sender to the receiver that has not been replayed. Furthermore, the start timestamp of a transaction to be replayed is the timestamp generated when the transaction begins execution on the sender. In one scenario, the database's built-in snapshot isolation mechanism can be executed on the sender, eliminating the need for additional mechanisms to generate start and end timestamps. This reduces computational and storage resource overhead. Thus, during logical replication, a snapshot of the target object can be sent to the receiver as the object for the transaction to be replayed; and the sender can generate a start timestamp when the transaction begins execution on the sender, and a commit timestamp when the transaction completes and is committed on the sender.

[0087] In practical applications, there are multiple ways to obtain the transaction to be replayed. For example, one can directly receive the transaction to be replayed sent by the sender, or one can read the transaction to be replayed sent by the sender from a cache pool. Furthermore, there are multiple ways to obtain the start timestamp of the transaction to be replayed. For example, if the transaction to be replayed contains a start timestamp, the start timestamp can be extracted from the transaction to be replayed; or, if the start timestamp and the transaction to be replayed are sent together, one can receive the start timestamp of the transaction to be replayed sent by the sender. Any method that can obtain the transaction to be replayed and its start timestamp can be used in this specification, and this embodiment does not limit this approach.

[0088] S204, determine the first target queue to be inserted into the transaction to be replayed, and the transactions recorded in the first target queue have a serial replay execution relationship with the transaction to be replayed.

[0089] In practical applications, transactions to be replayed in any queue are replayed sequentially according to the order in which they were inserted into the queue. Therefore, transactions with a sequential replay relationship can be inserted into the same queue. This eliminates the need to determine the replay order of transactions in the queue when replaying them, thus improving transaction replay efficiency. For example, as shown... Figure 3 In one embodiment of this specification, a transaction replay method is provided, and the execution sequence of transactions is illustrated in the diagram below: The start timestamp of transaction T3 is greater than the commit timestamp of transaction T1. Transaction T3 can see the processing of the target object by transaction T1; therefore, transaction T3 has a read-write dependency on transaction T1. Replaying must be performed only after transaction T1 has completed its replay. Therefore, the execution relationship between transaction T3 and transaction T1 is serial replay. Similarly, the execution relationship between transaction T1 and transaction T4 is serial replay, and the execution relationship between transaction T1 and transaction T5 is also serial replay. Furthermore, the execution relationship for parallel replay will be explained in subsequent step S206.

[0090] Furthermore, there are multiple ways to determine the first target queue to which the transaction to be replayed is to be inserted. For ease of understanding and reasonable layout, the following will describe it in detail in the form of optional embodiments.

[0091] S206, if the start timestamp of the transaction to be replayed is not greater than the specified commit timestamp of the second target queue, the transaction to be replayed is inserted into the first target queue for replay. The second target queue and the first target queue respectively record the transaction to be replayed and the commit timestamp of the transaction. The transactions between the second target queue and the first target queue are replayed in parallel.

[0092] The transaction commit timestamp refers to the timestamp generated when the transaction is completed and committed on the sender's end. Furthermore, each timestamp is stored numerically in the computer; the earlier the timestamp represents, the smaller the value, and the later the timestamp represents, the larger the value. Multiple queues are formed, consisting of a first target queue and a second target queue, where the second target queue is different from the first target queue. The number of queues can be preset, allowing the receiver to establish a predetermined number of queues during transaction replay preparation. When there are multiple second target queues, each second target queue can be different, and any second target queue can contain one or more transactions. When multiple transactions exist in a second target queue, the transactions in the second target queue are executed serially to ensure that transactions with read-write dependencies are executed accurately. For example, as shown... Figure 3 In one embodiment of this specification, a transaction replay method is provided, and the execution sequence of transactions is illustrated in the diagram below: The start timestamp of transaction T1 is less than or equal to the commit timestamp of transaction T2. ​​Transaction T1 and transaction T2 are not visible to each other regarding the processing of the target object. Therefore, there is no read-write dependency between transaction T2 and transaction T1, and they can be executed in parallel. Accordingly, during transaction replay, there is a parallel replay execution relationship between transaction T2 and transaction T1. Similarly, there is a parallel replay execution relationship between transactions T3, T4, and T5.

[0093] Furthermore, if write-write conflicts occur when multiple transactions execute in parallel (e.g., simultaneously modifying rows in the same table), only one transaction will successfully commit, while the others will be aborted. Moreover, to obtain the commit timestamp, transactions are only sent to the receiver after the sender has committed. Therefore, the transactions obtained by the receiver will inevitably be free of write-write conflicts, further ensuring that the transactions replayed in parallel in this embodiment are independent of each other. Thus, the correctness of the transaction replay method provided in this embodiment can be further guaranteed.

[0094] In practical applications, parallel transaction replay between the second target queue and the first target queue refers to the following: each queue has a corresponding replay thread, which is invoked to replay the transactions to be replayed in the corresponding queue, with each replay thread invoked in parallel. For example, in parallel transaction replay between queues Q1 and Q2, transaction af1 in queue Q1 and transaction af2 in queue Q2 have a parallel replay execution relationship. When the start timestamp of the transaction to be replayed is not greater than the specified commit timestamp of the second target queue, there are multiple ways to insert the transaction to be replayed into the first target queue for replay. For ease of understanding and reasonable layout, the following will describe it in detail using optional embodiments.

[0095] In one embodiment of this specification, the transactions recorded in the first target queue and the transactions to be replayed have a serial replay execution relationship; the second target queue and the first target queue respectively record the transactions to be replayed and the commit timestamps of the transactions, and the transactions between the second target queue and the first target queue are replayed in parallel. Therefore, if the start timestamp of the transaction to be replayed is not greater than the specified commit timestamp of the second target queue, it indicates that the transaction to be replayed cannot see the transactions recorded in the second target queue, there is no read-write dependency between the transaction to be replayed and the transactions recorded in the second target queue, and the transaction to be replayed and the transactions recorded in the second target queue can be executed in parallel. Furthermore, the transactions between the second target queue and the first target queue are replayed in parallel. Therefore, inserting the transaction to be replayed into the first target queue for replay can ensure improved transaction replay efficiency. Moreover, the transactions recorded in the first target queue have a serial replay execution relationship, which can ensure that transactions with read-write dependencies can be executed accurately. Therefore, this solution can balance ensuring the accuracy of transaction replay and improving efficiency.

[0096] In one alternative implementation, the specified commit timestamp may include: the commit timestamps of all transactions in the second target queue that have not yet been replayed;

[0097] Accordingly, if the start timestamp of the transaction to be replayed is not greater than the specified commit timestamp of the second target queue, the transaction to be replayed is inserted into the first target queue for replay. This can specifically include the following steps:

[0098] Compare the start timestamp of the transaction to be replayed with the commit timestamps of all unreplayed transactions in the second target queue.

[0099] If the start timestamp of the transaction to be replayed is not greater than the commit timestamp of all transactions in the second target queue that have not been replayed, then the transaction to be replayed will be inserted into the first target queue for replay.

[0100] In practical applications, the start timestamp of the transaction to be replayed is no greater than the commit timestamps of all incomplete replay transactions in the second target queue, indicating a parallel replay execution relationship between the transaction to be replayed and all incomplete replay transactions in the second target queue. Furthermore, transactions in the second target queue and the first target queue are replayed in parallel. Therefore, the transaction to be replayed can be inserted into the first target queue for replay. This embodiment, by comparing the commit timestamps of all incomplete replay transactions in the second target queue with the start timestamp of the transaction to be replayed, can accurately determine whether the transaction to be replayed and the transactions in the second target queue are in a parallel replay execution relationship, thereby improving the accuracy of transaction replay.

[0101] In one scenario, to further improve the efficiency of transaction replay, before comparing the start timestamp of the transaction to be replayed with the commit timestamps of all incomplete replay transactions in the second target queue, it can be determined whether the second target queue is empty. If it is empty, then the start timestamp of the transaction to be replayed is determined to be no greater than the commit timestamps of all incomplete replay transactions in the second target queue. Alternatively, for example, a set of commit timestamps of incomplete replay transactions can be maintained for each queue. Specifically, when a transaction to be replayed is inserted into a queue, its commit timestamp can be inserted into the commit timestamp set of that queue. Furthermore, when the transaction to be replayed is completed, its commit timestamp is removed from the commit timestamp set of the queue to which it belongs. Based on this, comparing the start timestamp of the transaction to be replayed with the commit timestamps of all unreplayed transactions in the second target queue can include: determining whether the commit timestamp set of the second target queue is empty; if it is empty, then determining that the start timestamp of the transaction to be replayed is not greater than the commit timestamps of all unreplayed transactions in the second target queue; if it is not empty, then comparing the start timestamp of the transaction to be replayed with each commit timestamp in the commit timestamp set of the second target queue; if none of them are greater than the commit timestamps of all unreplayed transactions in the second target queue, then determining that the start timestamp of the transaction to be replayed is not greater than the commit timestamps of all unreplayed transactions in the second target queue.

[0102] In an optional implementation, after comparing the start timestamp of the transaction to be replayed with the commit timestamps of all unreplayed transactions in the second target queue, the transaction replay method provided in this specification embodiment may further include the following steps:

[0103] If the commit timestamp of the first transaction in the second target queue that has not been replayed is less than the start timestamp of the transaction to be replayed, then wait for the first transaction to be replayed.

[0104] To ensure parallel replay of transactions between the second and first target queues, if the commit timestamp of an incomplete first transaction in the second target queue is less than the start timestamp of the transaction to be replayed, then the process waits for the first transaction to complete its replay. This ensures that the transaction to be replayed can be inserted into the first target queue. For example, waiting for the first transaction to complete its replay can include calling the function `wait_for_dependency()` to wait for the first transaction to complete its replay, thereby ensuring that the commit timestamps of all incomplete transactions in the second target queue are greater than or equal to the start timestamp of the transaction to be replayed.

[0105] This embodiment ensures parallel playback of transactions between the second target queue and the first target queue by waiting for the first transaction to complete its replay.

[0106] In one optional implementation, the specified commit timestamp is: the minimum commit timestamp of the transactions that have not been replayed in the second target queue;

[0107] Accordingly, if the start timestamp of the transaction to be replayed is not greater than the specified commit timestamp of the second target queue, the transaction to be replayed is inserted into the first target queue for replay. This can specifically include the following steps:

[0108] Compare the start timestamp of the transaction to be replayed with the minimum commit timestamp;

[0109] If the start timestamp of the transaction to be replayed is not greater than the minimum commit timestamp, then the transaction to be replayed will be inserted into the first target queue for replay.

[0110] The minimum commit timestamp of transactions not yet replayed in the second target queue refers to the smallest commit timestamp among all the commit timestamps of transactions not yet replayed in the second target queue. For example, if the transactions not yet replayed in the second target queue include transactions af1, af2, and af3; and the commit timestamp ts1 of transaction af1 > the commit timestamp ts2 of transaction af2 > the commit timestamp ts3 of transaction af3, then the minimum commit timestamp of the transactions not yet replayed in the second target queue is ts3. This reduces the number of commit timestamps that do not need to be compared with the start timestamp of the transaction to be replayed, further improving the efficiency of transaction replay.

[0111] Furthermore, similar to the aforementioned embodiment that compares the start timestamp of the transaction to be replayed with the commit timestamps of all incomplete transactions in the second target queue, to further improve transaction replay efficiency, before comparing the start timestamp of the transaction to be replayed with the minimum commit timestamp, it can be determined whether the second target queue is empty. If it is empty, then the start timestamp of the transaction to be replayed is determined to be no greater than the minimum commit timestamp; if it is not empty, then the start timestamp of the transaction to be replayed is compared with the minimum commit timestamp. Alternatively, when an incomplete transaction in the second target queue is replayed, its minimum timestamp is deleted from the second target queue. Thus, if there are no incomplete transactions in the second target queue, the minimum timestamp of the second target queue is empty.

[0112] In an optional implementation, after comparing the start timestamp of the transaction to be replayed with the minimum commit timestamp, the transaction replay method provided in this specification embodiment may further include the following steps:

[0113] If the start timestamp of the transaction to be replayed is greater than the minimum commit timestamp, then wait for the unreplayed transactions in the second target queue to be replayed.

[0114] This embodiment is similar to the above embodiment regarding waiting for the first transaction to complete replay, the difference being that it waits for the transaction with the minimum commit timestamp to complete replay. The same parts are described in the above embodiment regarding waiting for the first transaction to complete replay, and will not be repeated here. Thus, this embodiment can guarantee the parallel replay of transactions between the second target queue and the first target queue.

[0115] In one alternative implementation, determining the first target queue to which the transaction to be replayed is to be inserted may specifically include the following steps:

[0116] Obtain the identifier of the target object of the transaction to be replayed;

[0117] Find the first target queue corresponding to the target object identifier from each queue.

[0118] In practical applications, different transactions targeting the same object are likely to be executed in parallel. Furthermore, these transactions share the same object identifier. The queues refer to multiple queues comprised of a first target queue and a second target queue. Therefore, in this embodiment, searching for the first target queue corresponding to the target object identifier from each queue is equivalent to inserting transactions targeting the same target object into the same queue. This allows different transactions targeting the same target object to be replayed serially. Thus, this embodiment can efficiently determine the first target queue, further improving the efficiency of transaction replay.

[0119] In another alternative implementation, the process of determining the first target queue to which the transaction to be replayed is to be inserted may specifically include the following steps:

[0120] The queues that meet the replay efficiency criteria are designated as the first target queue for inserting transactions to be replayed. The replay efficiency criteria include any one of the following:

[0121] The queue contains no transactions that have not been replayed, has the fewest number of transactions that have not been replayed, has the shortest total time required for all transactions that have not been replayed to be replayed, and has the smallest commit timestamp for transactions that have not been replayed.

[0122] This implementation ensures that transactions awaiting replay are replayed as quickly as possible after being inserted into the first target queue, further improving transaction replay efficiency. Furthermore, it guarantees that transactions awaiting replay are inserted into the queue with the least load, achieving a degree of queue load balancing.

[0123] In an optional implementation, after inserting the transaction to be replayed into the first target queue for replay, the transaction replay method provided in this specification embodiment may further include the following steps:

[0124] If the transaction to be replayed is not replayed when the preset time threshold is reached, then the third target queue with the shortest total replay time is determined from the second target queue. The total replay time of any queue is the total time required for all unreplayed transactions in that queue to be replayed.

[0125] Take the transaction to be replayed from the current first target queue and insert it into the third target queue.

[0126] The third target queue is the queue with the shortest total replay time among the second target queues. Furthermore, if a transaction to be replayed is not executed when the preset time threshold is reached, it indicates that the load on the first target queue is relatively too high. Therefore, retrieving transactions to be replayed from the current first target queue and inserting them into the third target queue can adjust the transactions requiring replay between queues, effectively reducing the load on the first target queue, achieving queue load balancing, and further improving the efficiency of transaction replay. In one scenario, to ensure that transactions between queues are executed in a parallel replay relationship and to further improve the accuracy of transaction replay, the transaction to be replayed can be inserted into the third target queue if the start timestamp of the transaction to be replayed is not greater than the specified commit timestamp of the fourth target queue. The fourth target queue is any queue other than the third target queue. The specified timestamp includes: the commit timestamps of all unreplayed transactions in the fourth target queue, or the minimum commit timestamp of the unreplayed transactions in the fourth target queue. In other words, before inserting the transaction to be replayed into the third target queue, similar processing to that performed before inserting the transaction to be replayed into the first target queue can be performed. The difference is that the transactions being judged and awaiting replay completion are transactions in the fourth target queue. Therefore, if the commit timestamp of a second transaction in the fourth target queue that has not yet been replayed is less than the start timestamp of the transaction to be replayed, then the second transaction is waited for to complete its replay; or, if the start timestamp of the transaction to be replayed is greater than the aforementioned minimum commit timestamp, then the transaction in the fourth target queue that has not yet been replayed is waited for to complete its replay. The identical parts will not be repeated here; please refer to the above description of the embodiment regarding the processing performed before inserting the transaction to be replayed into the first target queue.

[0127] Furthermore, to further improve the efficiency of transaction replay, the resource allocation of threads in each queue can be adjusted using a round-robin scheduling algorithm. This reduces the efficiency loss caused by competition for resources between different queues. The round-robin scheduling algorithm allocates a time period, called the thread's time slice: the length of time the thread is allowed to run. If a thread is still running at the end of its time slice, its computing resources are preempted and allocated to another thread. If a thread is blocked or terminated before the end of its time slice, resource switching occurs immediately: the computing resources occupied by that thread are allocated to another thread.

[0128] In one optional implementation, the above-mentioned acquisition of the transaction to be replayed may specifically include the following steps:

[0129] Parse the database logs to obtain the transactions to be replayed.

[0130] In practical applications, the database may be empty, lacking the target object, and therefore there is no need to generate a snapshot of the target object. Consequently, there are no third transactions with commit timestamps later than the snapshot timestamp. Thus, during logical replication, all transactions recorded in the database log are new transactions, and these new transactions can be replayed. Therefore, the database log can be parsed to obtain the transactions to be replayed. For example, the source node parses the database log to obtain the transactions to be replayed and sends them to the destination node. In this way, this embodiment can achieve accurate logical replication even when the database is empty.

[0131] In another optional implementation, the above-mentioned acquisition of the transaction to be replayed may specifically include the following steps:

[0132] Obtain the snapshot timestamp of the target object and the database log of the target object;

[0133] Parse the database logs to obtain transactions whose commit timestamps are greater than or equal to the snapshot timestamps, and use these as transactions to be replayed.

[0134] To further reduce resource overhead, if snapshots are used to isolate the start and commit timestamps of transactions, the sender can generate a snapshot of the target object and send it to the receiver as a copy of the target object. Furthermore, when a snapshot of the target object is generated, a snapshot timestamp is also generated accordingly. Transactions with commit timestamps less than the snapshot timestamp are used to obtain the snapshot of the target object, thus eliminating the need for replay. Therefore, transactions with commit timestamps greater than or equal to the snapshot timestamp can be considered as transactions to be replayed. Specifically, parsing the database log to obtain transactions with commit timestamps greater than or equal to the snapshot timestamps can include: reading the transactions and their commit timestamps from the database log, comparing the read commit timestamps with the snapshot timestamps to obtain the transactions with commit timestamps greater than or equal to the snapshot timestamps.

[0135] Furthermore, generating a snapshot of the target object includes: generating a snapshot timestamp for the target object, which can be specified; reading the data state of the target object in the database using the snapshot timestamp; and generating a snapshot of the target object from the read data state. Specifically, from the versions of each record in the target table stored in the database, the version visible to the snapshot timestamp of the target object is read, and the read version is generated as a snapshot of the target object. Here, the target table refers to the table where the target object resides. The version visible to the snapshot timestamp of the target object is the version whose commit timestamp is less than the snapshot timestamp of the target object, which is also the record. Thus, in this embodiment, the snapshot of the target object generated based on the snapshot timestamp includes the modifications of the third transaction whose commit timestamp is less than the snapshot timestamp, which is the execution result of the third transaction. Therefore, the third transaction does not need to be replayed. Therefore, the method of obtaining transactions to be replayed provided in this embodiment can reduce the abnormal replay results, resource waste, and reduced replay efficiency caused by repeatedly replaying third transactions that do not need to be replayed.

[0136] In one alternative implementation, each transaction corresponds to a transaction identifier;

[0137] Accordingly, after parsing the database logs of the target object as described above, the transaction replay method provided in this embodiment may further include the following steps:

[0138] During the process of parsing the database logs of the target object, if abort information is obtained, the transaction identifier corresponding to the abort information is retrieved.

[0139] Remove the transaction corresponding to the transaction identifier from the cache.

[0140] In practical applications, a transaction refers to a unit of program execution that accesses and updates data items in a database. For example, in a relational database, a transaction can be a single SQL statement, a group of SQL statements, or an entire program. Therefore, to ensure the integrity and accuracy of transactions, the sender can generate a transaction identifier for each transaction. Based on this, the sender creates a cache set in the cache for each transaction identifier, caching the DML and / or DDL operations contained in the transaction. This cache set can then be considered a transaction. Furthermore, if an abort message is parsed, it indicates that a transaction for a certain object has been aborted. Therefore, to improve efficiency and reduce resource consumption, the transaction corresponding to the transaction identifier can be deleted from the cache. For example, the abort message can specifically be an abort record. Additionally, the elements in the cache set have an execution order; therefore, the cache set can specifically be in the form of a queue.

[0141] The following is in conjunction with the appendix Figure 4Taking the application of the transaction replay method provided in this manual to the destination node as an example, the transaction replay method will be further explained. Figure 4 This is an example diagram illustrating the processing procedure of a transaction replay method applied to a destination node, provided in one embodiment of this specification. The processing procedure includes the following stages 1 to 2:

[0142] Phase 1: The destination node receives the target snapshot and the transaction to be replayed generated for that snapshot from the source node. The target snapshot is equivalent to the snapshot generated based on the snapshot timestamp of the target object, as described above. For details, please refer to the description of the steps for generating a snapshot of the target object in the embodiment for obtaining the transaction to be replayed, which will not be repeated here. Furthermore, the transaction to be replayed is a transaction whose commit timestamp is greater than or equal to the snapshot timestamp. This transaction can specifically include DML operations and / or DDL operations. The target object can be a record (row) to be copied in a table of the source node. Alternatively, the target object can be one or more tables in the source node. The source node obtains the target snapshot and the transaction to be replayed generated for that snapshot, which specifically includes: parsing the database log and constructing a cache set with transaction identifiers in the cache area; comparing the commit timestamp of the transaction in the commit records of the database log with the snapshot timestamp; if the commit timestamp of the transaction is greater than or equal to the snapshot timestamp, then caching the DML operations and / or DDL operations contained in the transaction to the cache set with the transaction identifier of that transaction. In addition, the cache set can also cache the operation types (e.g., update, delete, or insert) and / or DDL operation types (e.g., create, modify, or delete), operation values, and identifiers of the rows operated on, such as key values ​​(i.e., primary key values), contained in the transaction. Furthermore, the information cached in this set can be sent to the destination node along with the transaction to be replayed.

[0143] Phase 2: If each modification in the transaction to be replayed is a DML operation, the destination node locates the row (tuple) of the table to be modified based on the primary key value corresponding to the DML operation, and then replays the DML operation on the records in the located row, thereby modifying the records in the located row. If each modification in the transaction to be replayed is a DDL operation, the destination node locates the table to be modified based on the identifier of the table corresponding to the DDL operation, and then replays the DDL operation on the located table, thereby modifying the located table. After the transaction to be replayed is completed, the destination node can commit the transaction to be replayed and store the replay result in the table. Specifically, the destination node creates multiple queues and starts a thread for each queue, such as threads thr1 to thrn, which are used to read and replay the transactions to be replayed from the queues. To achieve parallel playback based on snapshot isolation, before inserting a transaction T1 into a queue, the destination node must wait for the second target queue to meet a timestamp condition: the commit timestamps of all transactions in the second target queue that have not yet been played back must be greater than or equal to the start timestamp of transaction T1. When the timestamp condition is met, the first target queue is determined from queues Q1 to Qn, and the transaction to be played back is inserted into the first target queue.

[0144] For ease of understanding, the above embodiments are described in an exemplary manner below. For example, as shown... Figure 5 As shown in the flowchart, a transaction replay method according to an embodiment of this specification includes the following steps:

[0145] S502, obtain the target object identifier of the transaction to be replayed, and find the first target queue corresponding to the target object identifier from each queue. Execute S504 to S508, or S510 to S514.

[0146] S504, compare the start timestamp of the transaction to be replayed with the commit timestamps of all unreplayed transactions in the second target queue.

[0147] S506, if the start timestamp of the transaction to be replayed is not greater than the commit timestamp of all transactions in the second target queue that have not been replayed, then the transaction to be replayed is inserted into the first target queue for replay.

[0148] S508, if the commit timestamp of the first transaction that has not been replayed in the second target queue is less than the start timestamp of the transaction to be replayed, then wait for the first transaction to be replayed.

[0149] S510 compares the start timestamp of the transaction to be replayed with the minimum commit timestamp.

[0150] S512, if the start timestamp of the transaction to be replayed is not greater than the minimum commit timestamp, then the transaction to be replayed is inserted into the first target queue for replay.

[0151] S514, if the start timestamp of the transaction to be replayed is greater than the minimum commit timestamp, then wait for the unreplayed transactions in the second target queue to be replayed.

[0152] The steps described in this embodiment are the same as those in some of the above embodiments, and will not be repeated here. Please refer to the description of the above embodiments for details.

[0153] Corresponding to the above method embodiments, this specification also provides embodiments of a transaction replay device. Figure 6 A schematic diagram of a transaction playback device according to one embodiment of this specification is shown. Figure 6 As shown, the device includes:

[0154] The data acquisition module 602 is configured to acquire the transaction to be replayed and the start timestamp of the transaction to be replayed;

[0155] The queue determination module 604 is configured to determine a first target queue into which the transaction to be replayed is to be inserted, wherein the transactions recorded in the first target queue have a serial replay execution relationship with the transaction to be replayed.

[0156] The transaction replay module 606 is configured to insert the transaction to be replayed into the first target queue for replay if the start timestamp of the transaction to be replayed is not greater than the specified commit timestamp of the second target queue. The second target queue and the first target queue respectively record the transaction to be replayed and the commit timestamp of the transaction. The transactions between the second target queue and the first target queue are replayed in parallel.

[0157] In one embodiment of this specification, the transactions recorded in the first target queue and the transactions to be replayed have a serial replay execution relationship; the second target queue and the first target queue respectively record the transactions to be replayed and the commit timestamps of the transactions, and the transactions between the second target queue and the first target queue are replayed in parallel. Therefore, if the start timestamp of the transaction to be replayed is not greater than the specified commit timestamp of the second target queue, it indicates that the transaction to be replayed cannot see the transactions recorded in the second target queue, there is no read-write dependency between the transaction to be replayed and the transactions recorded in the second target queue, and the transaction to be replayed and the transactions recorded in the second target queue can be executed in parallel. Furthermore, the transactions between the second target queue and the first target queue are replayed in parallel. Therefore, inserting the transaction to be replayed into the first target queue for replay can ensure improved transaction replay efficiency. Moreover, the transactions recorded in the first target queue have a serial replay execution relationship, which can ensure that transactions with read-write dependencies can be executed accurately. Therefore, this solution can balance ensuring the accuracy of transaction replay and improving efficiency.

[0158] In one optional implementation, the specified commit timestamp includes: the commit timestamps of all transactions in the second target queue that have not been replayed;

[0159] The transaction replay module 606 is further configured as follows:

[0160] Compare the start timestamp of the transaction to be replayed with the commit timestamps of all unreplayed transactions in the second target queue.

[0161] If the start timestamp of the transaction to be replayed is not greater than the commit timestamp of all transactions in the second target queue that have not been replayed, then the transaction to be replayed will be inserted into the first target queue for replay.

[0162] In an optional implementation, the transaction replay module 606 is further configured to:

[0163] After comparing the start timestamp of the transaction to be replayed with the commit timestamps of all transactions in the second target queue that have not been replayed, if the commit timestamp of a first transaction in the second target queue that has not been replayed is less than the start timestamp of the transaction to be replayed, then wait for the first transaction to be replayed.

[0164] In one optional implementation, the specified commit timestamp is: the minimum commit timestamp of the transactions in the second target queue that have not been replayed;

[0165] The transaction replay module 606 is further configured as follows:

[0166] Compare the start timestamp of the transaction to be replayed with the minimum commit timestamp;

[0167] If the start timestamp of the transaction to be replayed is not greater than the minimum commit timestamp, then the transaction to be replayed is inserted into the first target queue for replay.

[0168] In an optional implementation, the transaction replay module 606 is further configured to:

[0169] After comparing the start timestamp of the transaction to be replayed with the minimum commit timestamp, if the start timestamp of the transaction to be replayed is greater than the minimum commit timestamp, then wait for the unreplayed transactions in the second target queue to be replayed.

[0170] In an optional implementation, the transaction replay module 606 is further configured to:

[0171] After inserting the transaction to be replayed into the first target queue for replay, if the transaction to be replayed is not replayed when the preset time threshold is reached, then the third target queue with the shortest total replay time is determined from the second target queue. The total replay time of any queue is the total time required for all unreplayed transactions in that queue to be replayed.

[0172] The transaction to be replayed is retrieved from the current first target queue and inserted into the third target queue.

[0173] In an optional implementation, the data acquisition module 602 is further configured to:

[0174] Obtain the snapshot timestamp of the target object and the database log of the target object;

[0175] The database logs are parsed to obtain transactions whose commit timestamps are greater than or equal to the snapshot timestamps, which are then used as the transactions to be replayed.

[0176] In one alternative implementation, each transaction corresponds to a transaction identifier;

[0177] The data acquisition module 602 is further configured to:

[0178] During the process of parsing the database logs of the target object, if abort information is obtained, the transaction identifier corresponding to the abort information is acquired.

[0179] Delete the transaction corresponding to the transaction identifier from the cache.

[0180] In an optional implementation, the queue determination module 604 is further configured to:

[0181] Obtain the target object identifier of the transaction to be replayed;

[0182] Find the first target queue corresponding to the target object identifier from each queue.

[0183] The above is a schematic scheme of a transaction replay device according to this embodiment. It should be noted that the technical solution of this transaction replay device and the technical solution of the above-described transaction replay method belong to the same concept. For details not described in detail in the technical solution of the transaction replay device, please refer to the description of the technical solution of the above-described transaction replay method.

[0184] Figure 7A structural block diagram of a computing device 700 according to one embodiment of this specification is shown. The components of the computing device 700 include, but are not limited to, a memory 710 and a processor 720. The processor 720 is connected to the memory 710 via a bus 730, and a database 750 is used to store data.

[0185] The computing device 700 also includes an access device 740, which enables the computing device 700 to communicate via one or more networks 760. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 740 may include one or more of any type of wired or wireless network interface (e.g., Network Interface Controller (NIC)), such as an IEEE 802.11 Wireless Local Area Networks (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC) interface, and so on.

[0186] In one embodiment of this specification, the above-described components of the computing device 700 and Figure 7 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 7 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0187] The computing device 700 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or PCs. The computing device 700 can also be a mobile or stationary server.

[0188] The processor 720 is configured to execute the following computer-executable instructions, which, when executed by the processor, implement the steps of the transaction replay method described above.

[0189] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the transaction replay method described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the transaction replay method described above.

[0190] An embodiment of this specification also provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the transaction replay method described above.

[0191] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the transaction replay method described above belong to the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the transaction replay method described above.

[0192] An embodiment of this specification also provides a computer program, wherein when the computer program is executed in a computer, it causes the computer to perform the steps of the above-described transaction replay method.

[0193] The above is an illustrative example of a computer program according to this embodiment. It should be noted that the technical solution of this computer program and the technical solution of the transaction replay method described above belong to the same concept. Details not described in detail in the technical solution of the computer program can be found in the description of the technical solution of the transaction replay method described above.

[0194] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0195] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

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

[0197] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0198] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A transaction replay method, comprising: Obtain the transaction to be replayed and the start timestamp of the transaction to be replayed; A first target queue is determined to be inserted into the transaction to be replayed, wherein the transactions recorded in the first target queue have a serial replay execution relationship with the transaction to be replayed; If the start timestamp of the transaction to be replayed is not greater than the specified commit timestamp of the second target queue, the transaction to be replayed is inserted into the first target queue for replay. The specified commit timestamp refers to the commit timestamp of the transaction in the second target queue that has not been replayed. The second target queue and the first target queue respectively record the transaction to be replayed and the commit timestamp of the transaction. Transactions between the second target queue and the first target queue are replayed in parallel.

2. The method according to claim 1, wherein the specified submission timestamp includes: The commit timestamps of all transactions in the second target queue that have not yet been replayed; The step of inserting the transaction to be replayed into the first target queue for replay when the start timestamp of the transaction to be replayed is not greater than the specified commit timestamp of the second target queue includes: Compare the start timestamp of the transaction to be replayed with the commit timestamps of all unreplayed transactions in the second target queue. If the start timestamp of the transaction to be replayed is not greater than the commit timestamp of all transactions in the second target queue that have not been replayed, then the transaction to be replayed will be inserted into the first target queue for replay.

3. The method according to claim 2, further comprising, after comparing the start timestamp of the transaction to be replayed with the commit timestamps of all incomplete replay transactions in the second target queue: If the commit timestamp of a first transaction that has not been replayed in the second target queue is less than the start timestamp of the transaction to be replayed, then wait for the first transaction to be replayed.

4. The method according to claim 1, wherein the specified commit timestamp is: the minimum commit timestamp of the transactions in the second target queue that have not been replayed; The step of inserting the transaction to be replayed into the first target queue for replay when the start timestamp of the transaction to be replayed is not greater than the specified commit timestamp of the second target queue includes: Compare the start timestamp of the transaction to be replayed with the minimum commit timestamp; If the start timestamp of the transaction to be replayed is not greater than the minimum commit timestamp, then the transaction to be replayed is inserted into the first target queue for replay.

5. The method according to claim 4, further comprising, after comparing the start timestamp of the transaction to be replayed with the minimum commit timestamp: If the start timestamp of the transaction to be replayed is greater than the minimum commit timestamp, then wait for the unreplayed transactions in the second target queue to be replayed.

6. The method according to any one of claims 1 to 5, wherein determining the first target queue to which the transaction to be replayed is to be inserted comprises: Obtain the target object identifier of the transaction to be replayed; Find the first target queue corresponding to the target object identifier from each queue.

7. The method according to any one of claims 1 to 5, further comprising, after inserting the transaction to be replayed into the first target queue for replay: If the transaction to be replayed is not replayed when the preset time threshold is reached, then the third target queue with the shortest total replay time is determined from the second target queue. The total replay time of any queue is the total time required for all unreplayed transactions in that queue to be replayed. The transaction to be replayed is retrieved from the current first target queue and inserted into the third target queue.

8. The method according to any one of claims 1 to 5, wherein obtaining the transaction to be replayed comprises: Obtain the snapshot timestamp of the target object and the database log of the target object; The database logs are parsed to obtain transactions whose commit timestamps are greater than or equal to the snapshot timestamps, which are then used as the transactions to be replayed.

9. The method according to claim 8, wherein each transaction corresponds to a transaction identifier; further comprising: During the process of parsing the database logs of the target object, if abort information is obtained, the transaction identifier corresponding to the abort information is acquired. Delete the transaction corresponding to the transaction identifier from the cache.

10. A transaction playback device, comprising: The data acquisition module is configured to acquire the transaction to be replayed and the start timestamp of the transaction to be replayed; The queue determination module is configured to determine the first target queue into which the transaction to be replayed is to be inserted, wherein the transactions recorded in the first target queue have a serial replay execution relationship with the transaction to be replayed; The transaction replay module is configured to insert the transaction to be replayed into the first target queue for replay if the start timestamp of the transaction to be replayed is not greater than the specified commit timestamp of the second target queue. The specified commit timestamp refers to the commit timestamp of the transaction in the second target queue that has not been replayed. The second target queue and the first target queue respectively record the transaction to be replayed and the commit timestamp of the transaction. Transactions between the second target queue and the first target queue are replayed in parallel.

11. A computing device, comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, which, when executed by the processor, implement the steps of the transaction replay method according to any one of claims 1 to 9.

12. A computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the transaction replay method according to any one of claims 1 to 9.

13. A computer program product, wherein, When the computer program is executed in the computer, it causes the computer to perform the steps of the transaction replay method according to any one of claims 1 to 9.

Images