Distributed database consistency snapshot optimization generation method and system

Abstract

A method and system for optimizing the generation of consistent snapshots in a distributed database are disclosed. For distributed databases comprising multiple database nodes, the system periodically checks the freshness of the local consistent snapshots on each database node. When a transaction is found blocking snapshot advancement on a node, the system notifies the database node acting as the transaction coordinator to initiate a timestamp update operation for all participating nodes. After the update is completed, a new consistent snapshot and its corresponding secure timestamp are generated. This invention enables stable updates to consistent snapshots, thereby avoiding the inability to guarantee the upper limit of blocking time when snapshot reads are blocked.

Description

Technical Field

[0001] This invention relates to a technology in the field of distributed data processing, specifically a method and system for optimizing and generating consistent snapshots of distributed databases. Background Technology

[0002] Distributed databases typically replicate data multiple times to improve system availability and increase database read throughput. However, due to the latency of write operations during master-slave replication, reading from replicas may result in outdated data, leading to data consistency issues. Therefore, replica reading is usually implemented through snapshot reading. This involves setting a timestamp during reading; if the latest consistent snapshot on the corresponding replica satisfies the read timestamp, the snapshot data corresponding to that timestamp can be returned. Existing consistent snapshot generation technologies suffer from several drawbacks. These include the loss of requests from participating nodes when the distributed transaction coordinator node ends, transaction deadlocks, and long-running transactions. In such cases, some transactions may remain in a "preparing to complete but not committed" phase for an extended period. The safe timestamps on the replicas involved in these transactions cannot be updated, thus blocking consistent snapshots. Consequently, snapshot reads with timestamps later than the safe timestamps are blocked until the corresponding transaction ends. Summary of the Invention

[0003] This invention addresses the problem of deadlock in distributed transactions and snapshot read blocking in long transaction execution scenarios, which cannot be solved by existing technologies. It proposes a method and system for optimizing the generation of consistent snapshots in distributed databases, which can achieve stable updates of consistent snapshots and thus avoid the inability to guarantee the upper limit of blocking time when snapshot read is blocked.

[0004] This invention is achieved through the following technical solution:

[0005] This invention relates to a method for optimizing the generation of consistent snapshots in a distributed database. For a distributed database comprising multiple database nodes, the method periodically checks the freshness of the local consistent snapshots of the database nodes and notifies the database node acting as the transaction coordinator to initiate a transaction timestamp update operation for all participating nodes when there are transactions blocking snapshot advancement on the nodes. After the update is completed, a new consistent snapshot and a corresponding secure timestamp are generated.

[0006] The distributed database includes multiple database nodes, each storing a portion of data locally. When executing a distributed transaction involving reading and writing data on multiple database nodes, one of the database nodes containing the data is selected as the coordinator node for the transaction, and the other nodes are selected as participants in the transaction.

[0007] The method specifically includes:

[0008] Step 1: Using any database node in the distributed database as the current processing node, obtain the current timestamp TS and calculate the local secure timestamp TS. safe Then calculate the local consistent snapshot freshness T. fresh Specifically: T fresh =TS-TS safe ,in: The value is the minimum of the preparation timestamps of all prepared but uncommitted transactions on the current processing node.

[0009] When there are no prepared but uncommitted transactions It is positive infinity.

[0010] Step 2: If the freshness of the consistent snapshot of the current processing node in Step 1 does not meet the threshold, execute Step 3; otherwise, after a delay, start executing from Step 1 again.

[0011] Step 3: The current processing node in Step 1 obtains the abnormal transactions that block the consistency snapshot freshness from the local transaction manager, that is, the set T = {txn1, ..., txn} of all prepared but uncommitted distributed transactions whose preparation timestamps do not meet the threshold. n}, where: txn is a distributed transaction that has been prepared but not yet committed on this node, and the local transaction manager contains the preparation timestamp and coordinator node information of the transaction on the current processing node.

[0012] Step 4: For each prepared but uncommitted transaction txn in the transaction set T i The current processing node notifies the corresponding coordinator node. Transaction txn i The preparation timestamp is outdated.

[0013] Step 5: For set T, prepare uncommitted transactions txn i coordinator node After receiving the notification, calculate the lower limit of the submission timestamp. And send a refresh request to all participant nodes in the transaction.

[0014] The aforementioned "preparation refresh request" refers to a request sent to a participant node of a transaction to refresh the transaction preparation timestamp when the coordinator node has not yet determined the final state of the transaction. When sending the preparation refresh request, the coordinator node adds the transaction information to be refreshed and the lower limit t of the transaction's commit timestamp. min-commit When a participant node receives a prepare refresh request, it refreshes the prepare timestamp of the prepared but uncommitted transaction to t. min-commit This updates the secure timestamp T on the participant node.safe This drives the generation of consistent snapshots.

[0015] Step 6, all received requests for txn i The database node that is preparing to refresh the request will have txn i The preparation timestamp has been updated to After receiving the refresh request from all coordinator nodes in step 4, the current processing node recalculates the security timestamp and provides a consistent snapshot below the security timestamp. After a delay, it resumes execution from step 1.

[0016] Technical effect

[0017] This invention adds a refresh preparation step to the existing secure timestamp scheme. By periodically detecting abnormal transactions that block the generation of consistent snapshots and notifying the corresponding coordinator node to send a refresh preparation request, the transaction preparation timestamps on participant nodes are updated in a timely manner, thereby achieving stable updates of secure timestamps. Compared to existing consistent snapshot generation schemes where the freshness of consistent snapshots is affected by long transactions and deadlocked transactions, this invention can guarantee the stability of consistent snapshot freshness within the configured time without affecting the normal operation of transactions. Attached Figure Description

[0018] Figure 1 This is a flowchart of the present invention;

[0019] Figure 2 This is a schematic diagram of the participant node process in this invention;

[0020] Figure 3 This is a schematic diagram of the coordinator node process in this invention;

[0021] Figure 4 This is a schematic diagram of the process executed in a transaction deadlock scenario in the embodiment;

[0022] Figure 5 This is a rendering of an example.

[0023] Figure 6 This is a schematic diagram of the system of the present invention;

[0024] Figure 7 This is an application flowchart for an example. Detailed Implementation

[0025] like Figure 1 As shown, this embodiment illustrates a distributed database consistency snapshot optimization generation method, which includes:

[0026] Step 1: For a database node, obtain the current timestamp TS and calculate the local secure timestamp TS. safeThen, the local consistent snapshot freshness is calculated, where: security timestamp The value is the minimum of the preparation timestamps of all currently prepared but uncommitted transactions on this database node. If there are no prepared but uncommitted transactions, then... It is positive infinity. Consistent snapshot freshness T fresh =TS-TS safe .

[0027] Step 2: If the freshness of the consistent snapshot of the database node does not meet the threshold, execute Step 3; otherwise, after a delay, start executing from Step 1 again.

[0028] Step 3: The database node retrieves the abnormal transactions that block the consistency snapshot freshness from the local transaction manager, i.e., the set T = {txn1, ..., txn} of all prepared but uncommitted transactions whose preparation timestamps do not meet the threshold. n}, where: txn is a distributed transaction executed on this node, and the local transaction manager contains the preparation timestamp and coordinator node information of the transaction on this node.

[0029] Step 4: For each prepared but uncommitted transaction txn in the transaction set T i The database node notifies the corresponding coordinator node. Transaction txn i The preparation timestamp is outdated.

[0030] Step 5: For set T, prepare uncommitted transactions txn i coordinator node After receiving the notification, calculate the lower limit of the submission timestamp. And send a refresh request to all participating nodes in the transaction.

[0031] Step 6: The database node receives the request for txn i The prepare refresh request will be txn i The preparation timestamp has been updated to After receiving the refresh request from all coordinator nodes in step 4, the node recalculates the security timestamp and provides a consistent snapshot below the security timestamp, and then resumes execution from step 1 again after a delay.

[0032] like Figure 2As shown, upon receiving a prepare request, a participant node locally acquires the resources required for transaction commit, obtains a timestamp as the preparation completion timestamp, and returns the preparation timestamp and the successful preparation result to the coordinator node. If a participant node encounters an unresolved transaction causing the consistency snapshot freshness to exceed a threshold, it proactively notifies the coordinator node for that transaction. When a prepare refresh request is received from the coordinator node, the participant node updates the corresponding transaction's preparation timestamp based on the timestamp carried in the request and notifies the participant node to update the consistency snapshot. When a commit or rollback request is received from the coordinator node, the participant node releases the resources occupied by the corresponding transaction and cleans up the transaction's local records. Subsequent prepare refresh requests for that transaction are no longer processed and are directly rejected.

[0033] The preparation timestamp ensures that the commit timestamp is greater than or equal to the timestamp when the transaction is finally committed.

[0034] like Figure 3 As shown, after receiving a transaction commit request from a client node, the coordinator node sends a preparation request to the corresponding participant node. Before receiving preparation results from all participant nodes, and after the transaction pending time exceeds a threshold, the coordinator node proactively sends a preparation refresh request to the corresponding participant node. Upon receiving notification from a participant node, the coordinator node sends a preparation refresh request to that participant node. After receiving the results of all participant node preparation requests, the coordinator node decides whether to commit the transaction. If a commit is required, it obtains the latest timestamp until the timestamp is greater than the lower limit of the commit timestamp on the coordinator node. After the final result of the transaction is determined, the coordinator node cleans up the transactions on all participant nodes. After determining the commit timestamp on the coordinator node, upon receiving notification from a participant node, it no longer sends a preparation refresh request, but instead sends a transaction commit or rollback request. After receiving responses from all participant nodes, the coordinator node notifies the client node of the final result of the transaction.

[0035] The prepared refresh request includes the lower limit of the commit timestamp that can be determined for the transaction, such as the maximum timestamp already obtained on the current node, the current timestamp, or the maximum prepared timestamp already received, etc., which is used to update the prepared timestamp of the transaction on the participant nodes. The coordinator node can configure the timeout threshold for pending transactions according to actual application needs, and will periodically send prepared refresh requests until the transaction has a final result.

[0036] The conditions for triggering the refresh request include:

[0037] 1) When the pending time of a transaction on the coordinator node exceeds the configured threshold, the lower limit of the commit timestamp is periodically calculated and a refresh request is sent to all participant nodes until the transaction is committed or rolled back on the coordinator node.

[0038] 2) If the consistency snapshot freshness on a participant node does not meet the configuration, the participant node shall check whether all reasons for blocking are caused by... Too low a temperature. If the value is too low, retrieve the maximum value from all transaction read timestamps that exceed the configured time. Check all prepared but uncommitted transactions on this node, for those with a preparation timestamp less than [time stamp value missing]. For a transaction, the coordinator node of the transaction is requested to send a readiness refresh request to update the readiness timestamp of the transaction on the participant node.

[0039] Among the two triggering conditions for preparing a refresh request, the triggering threshold can be configured independently to adapt to different business needs. For example, for data ranges that require lower read blocking time, a higher consistency snapshot freshness can be configured on the corresponding database node to ensure lower snapshot read blocking time.

[0040] The method for calculating the lower limit of the submission timestamp is as follows: first, obtain the largest timestamp that has been received locally. If it can meet the freshness requirements of the participant nodes, use this timestamp as the lower limit of the submission timestamp. If the largest timestamp that has been received locally does not meet the freshness requirements, obtain the latest timestamp as the lower limit of the submission timestamp.

[0041] When the coordinator node sends a refresh preparation request to the participant node, it can use aggregation to gather all refresh preparation requests with the same destination address within a certain period into a batch and then send them to the corresponding node for unified processing, thereby reducing communication overhead. Similarly, when a participant node sends a notification to the coordinator node when its transaction preparation timestamp is too old, it can aggregate requests with the same destination address within a certain period into a batch and then send them to the corresponding node for unified processing, further reducing communication overhead.

[0042] In the scenario of a distributed database deployed across regions with multiple replicas, once the freshness of the consistency snapshot on a participant node exceeds the configured threshold, the participant node can request the corresponding transaction coordinator node's replica within its region to obtain the known lower limit of the commit timestamp for the corresponding transaction, thereby avoiding the high latency overhead of cross-regional communication.

[0043] like Figure 6 As shown, the distributed database system implementing the above method in this embodiment includes: a cluster management unit, a timestamp service unit, and several data service units. The cluster management unit stores and manages metadata and node information and performs routing processing on requests. The timestamp service unit calculates and allocates monotonically increasing timestamps. The data service units parse SQL requests and implement data storage, data addition, deletion, modification, querying, and transaction processing.

[0044] The data service unit includes: an SQL parsing subunit, a refresh preparation subunit, a data storage subunit, and a transaction management subunit. Specifically: the SQL parsing subunit analyzes SQL statements and converts them into an internal representation, ensuring syntactic correctness and generating an execution plan to optimize database operations; the refresh preparation subunit handles outdated consistency snapshots from the transaction management subunit, queries transactions that have blocked local consistency snapshots, and notifies the corresponding data service units; it handles local transaction timeouts and consistency snapshot blocking notifications from other data service units, calculates the lower limit of the transaction commit timestamp based on the local transaction status, and sends refresh preparation requests to the relevant data service units; the data storage subunit receives and processes data change and query requests from the transaction management subunit, and manages all committed data version information on the data service units; the transaction management subunit executes transactions and manages temporary version data and transaction status information of uncommitted transactions on the data service units, maintains the security timestamp on the data service units, periodically calculates and updates the security timestamp, and checks the freshness of the consistency snapshot and the pending duration of local transaction coordination records.

[0045] The data service unit stores data from one or more data tables. Each data table can be divided into one or more logical data partitions. Each data partition includes one or more physical data replicas. One replica serves as the primary replica, receiving writes to the data partition and possessing all the latest data of the data partition. The other replicas serve as secondary replicas, not providing writes but providing reads. Data replicas can be distributed across different data service units as needed.

[0046] When a transaction involves different data partitions, it is considered a distributed transaction. The system runs one or more distributed transactions simultaneously. Each distributed transaction maintains its latest state within that data partition on the primary replica. The primary replica replicates data to the secondary replica, which maintains the transaction's state at a past point in time within that data partition. Interactions between the data service units residing as the primary replicas of the corresponding data partitions implement the standard two-phase commit of distributed transactions. Simultaneously, both the primary and secondary replicas of the corresponding data partitions can use the prepare-to-refresh subunit to advance the generation of a consistent snapshot.

[0047] Based on specific experiments, this embodiment demonstrates... Figure 4 The simulation is performed in the scenario shown, involving two distributed transactions, txn1 and txn2. Both transactions operate on key1 on participant node 1 and key2 on participant node 2. The simulation process is as follows: Figure 7 As shown, it specifically includes:

[0048] Step 1: Client node 1 initiates a transaction execution and commit request (txn1) at timestamp 10s, selecting the coordinator node, participant node 1, and participant node 2 as the execution nodes for this transaction. The coordinator receives the corresponding transaction request at timestamp 10s, and configures the transaction preparation refresh timer threshold to 10s. The database is configured with a lock wait timeout of 30s.

[0049] Step 2: The coordinator node sends the corresponding transaction operation and preparation request to participant node 1 and participant node 2. After receiving the request, participant node 2 acquires the write lock wlock2 and obtains the current timestamp 10s as the preparation timestamp.

[0050] Step 3: Before participant node 1 receives the preparation request from transaction txn1, transaction txn2, which is not fully identified in the diagram due to space limitations, completes the preparation operation on participant node 1 and acquires the write lock wlock1 on key1 on participant node 1. This transaction also involves participant node 2, which is waiting for a write lock wlock2 locked by transaction txn1 to be released.

[0051] Step 4: Participant node 1 receives the preparation request from transaction txn1. Transaction txn1 waits on participant node 1 for the write lock wlock1 to be released starting at timestamp 10s. At this point, transactions txn1 and txn2 are in a circular wait.

[0052] Step 5: Client node 2 sends a snapshot read request txn3 to participant node 2, obtaining the current timestamp 13s as the read timestamp. At this time, participant node 2... safe Blocked by the txn1 preparation timestamp, it remains at 10s.

[0053] Step 6: On the coordinator node of transaction txn1, when the timestamp is 15s, under the scheme provided by this invention, the timer of transaction txn1 times out, and actively sends a preparation refresh request for txn1 to participant node 2, wherein the lower limit of the commit timestamp is the current timestamp of 15s.

[0054] Step 7: Under this method, participant node 2 receives the prepare refresh request from txn1, adjusts the prepare timestamp of transaction txn1 to 18s, and then updates participant node 2's T... safe The update time is 18 seconds. The txn3 snapshot read has ended and is in a blocked state. The read result is then returned.

[0055] Step 8: At timestamp 40s, participant node 1's wait for write lock wlock1 to be released times out, and the coordinator node of txn1 returns a failure message. Upon receiving the failure message, the coordinator node of txn1 rolls back txn1 on participant node 1 and participant node 2.

[0056] Step 9: Participant node 2 receives a rollback request from txn1 at timestamp 40s, releases the resources locked by local txn1, and the participant node 2... safe Updated to the latest write time of 40 seconds. Reply to the coordinator node of txn1. After receiving replies from all participant nodes, the coordinator node of txn1 replies to the client node with the result that the transaction commit failed and was rolled back. Participant node 2 on T... safe After updating to 40 seconds, the snapshot read transaction txn3 ends its blocking and returns the read result.

[0057] Based on the above simulation, running the above method with configuration parameters of 8s for consistent snapshot freshness and transaction pending time threshold, and 30s for lock timeout, the experimental data obtained are as follows: Figure 5 As shown, when long transactions occur due to deadlock or other reasons, compared to the safe timestamp method, this invention can provide a consistent snapshot with a freshness of less than 8 seconds on the database nodes involved in the long transaction without interfering with the normal operation of the transaction. This proves that this method can stably promote the generation of consistent snapshots without being blocked by long transactions. In contrast, the safe timestamp method only generates a new visible consistent snapshot after the long transaction is committed or rolled back. The freshness of the consistent snapshot provided during execution is linearly related to the running time of the long transaction and the lock timeout time. Reducing the lock timeout time can cause some long transactions that can be committed normally to be interrupted.

[0058] Compared with existing technologies, this method can promptly identify the blockage problem in generating consistent snapshots caused by long-pending transactions, and update the transaction preparation timestamps on the participant nodes by notifying the corresponding coordinator node to calculate the lower limit of the transaction commit timestamp and sending a refresh preparation request, thereby periodically promoting the generation of consistent snapshots.

[0059] The above-described specific implementations can be partially adjusted by those skilled in the art in different ways without departing from the principles and purpose of the present invention. The scope of protection of the present invention is defined by the claims and is not limited to the above-described specific implementations. All implementation schemes within the scope of the claims are bound by the present invention.

Claims

1. A method for optimizing the generation of consistent snapshots in a distributed database, characterized in that, For distributed databases with multiple database nodes, the freshness of the local consistent snapshot of the database nodes is checked periodically. When there are transactions on the nodes that block the snapshot advancement, the database node acting as the transaction coordinator is notified to initiate a transaction timestamp update operation for all participating transaction nodes. After the update is completed, a new consistent snapshot and the corresponding security timestamp are generated. The distributed database includes multiple database nodes, each storing a portion of data locally. When executing a distributed transaction involving reading and writing data across multiple database nodes, one of the database nodes containing the data is selected as the coordinator node for the transaction, and the other nodes act as participants. Specifically, this includes: Step 1: Using any node in the distributed database as the current processing node, obtain the current timestamp. And calculate the local secure timestamp Then calculate the local consistent snapshot freshness. Specifically: ,in: The value is the minimum of the preparation timestamps of all prepared but uncommitted transactions on the current processing node; when there are no prepared but uncommitted transactions... It is positive infinity; Step 2: If the freshness of the consistency snapshot of the current processing node in Step 1 does not meet the threshold, execute Step 3; otherwise, after a delay, start executing from Step 1 again. Step 3: The current processing node in Step 1 obtains the abnormal transactions that block the consistency snapshot freshness from the local transaction manager, i.e., the set of all prepared but uncommitted distributed transactions whose preparation timestamps do not meet the threshold. ,in: For a distributed transaction that has been prepared but not yet committed on this node, the local transaction manager contains the preparation timestamp of the transaction on the currently processing node and the coordinator node information; Step 4: For each prepared but uncommitted transaction in the transaction set T The current processing node notifies the corresponding coordinator node. transactions The preparation time stamp is too old; Step 5: For sets T, prepare uncommitted transactions. coordinator node After receiving the notification, calculate the lower limit of the submission timestamp. And send a refresh request to all participating nodes in the transaction; Step 6, all received items targeting The database node that will prepare to refresh the request will The preparation timestamp has been updated to After the current processing node receives the refresh request from all coordinator nodes in step 4, it recalculates the security timestamp and provides a consistent snapshot below the security timestamp. After a delay, it starts executing from step 1 again.

2. The distributed database consistent snapshot optimization generation method according to claim 1, characterized in that, The aforementioned "preparation refresh request" refers to a request sent to the participant nodes of a transaction when the coordinator node has not yet determined the final state of the transaction, in order to refresh the transaction preparation timestamp. When the coordinator node sends the preparation refresh request, it adds the transaction information to be refreshed and the lower limit of the transaction's commit timestamp. When a participant node receives a prepare refresh request, it refreshes the prepare timestamp of the prepared but uncommitted transaction. This updates the secure timestamp on the participant's node. This drives the generation of consistent snapshots.

3. The distributed database consistent snapshot optimization generation method according to claim 1, characterized in that, Upon receiving a preparation request, the participant node locally acquires the resources required for transaction commit, obtains a timestamp as the preparation completion timestamp, and returns the preparation timestamp and the successful preparation result to the coordinator node. When a participant node encounters a transaction that is pending, causing the consistency snapshot freshness to exceed the threshold, it actively notifies the coordinator node of the transaction. When it receives a preparation refresh request from the coordinator node, it updates the preparation timestamp of the corresponding transaction according to the timestamp carried in the request and notifies the participant node to update the consistency snapshot. When it receives a commit or rollback request from the coordinator node, it releases the resources occupied by the corresponding transaction and cleans up the local record of the transaction. Subsequent preparation refresh requests for the transaction are no longer processed and are directly rejected. Prepare a timestamp to ensure that the commit timestamp is greater than or equal to the timestamp when the transaction is finally committed. After receiving a transaction commit request from a client node, the coordinator node sends a preparation request to the corresponding participant node. Before receiving preparation results from all participant nodes, and after the transaction pending time exceeds a threshold, the coordinator node proactively sends a preparation refresh request to the corresponding participant node. Upon receiving notification from a participant node, the coordinator node sends a preparation refresh request to the participant node. After receiving the results of all participant node preparation requests, the coordinator node decides whether to commit the transaction. If a commit is required, it obtains the latest timestamp until the timestamp is greater than the lower limit of the commit timestamp on the coordinator node. After the final result of the transaction is determined, the coordinator node cleans up the transactions on all participant nodes. After the coordinator node decides on the commit timestamp, upon receiving notification from a participant node, it no longer sends a preparation refresh request, but instead sends a transaction commit or rollback request. After receiving responses from all participant nodes, the coordinator node notifies the client node of the final result of the transaction.

4. The distributed database consistent snapshot optimization generation method according to claim 1, characterized in that, The conditions for triggering the refresh request include: 1) When the pending time of a transaction on the coordinator node exceeds the configured threshold, the lower limit of the commit timestamp is periodically calculated and a refresh request is sent to all participant nodes until the transaction is committed or rolled back on the coordinator node. 2) If the consistency snapshot freshness on a participant node does not meet the configuration, the participant node shall check whether all reasons for blocking are caused by... Too low, when If the value is too low, retrieve the maximum value from all transaction read timestamps that exceed the configured time. Check all prepared but uncommitted transactions on this node, and for those with a preparation timestamp less than [timestamp value missing]... For a transaction, the coordinator node of the transaction is requested to send a readiness refresh request to update the readiness timestamp of the transaction on the participant node; The trigger thresholds for the two triggering conditions for preparing a refresh request can be configured independently to adapt to different business needs.

5. The distributed database consistency snapshot optimization generation method according to any one of claims 1-4, characterized in that, The aforementioned submission timestamp lower limit is obtained in the following way: first, obtain the maximum timestamp that has been received locally. If the freshness required by the participant node is met, use this timestamp as the submission timestamp lower limit. If the maximum timestamp that has been received locally does not meet the freshness requirement, obtain the latest timestamp as the submission timestamp lower limit.

6. The distributed database consistent snapshot optimization generation method according to claim 1, characterized in that, When the coordinator node sends a refresh request to the participant node, it uses an aggregation method to aggregate all refresh requests with the same destination address within a certain period of time into a batch and then send them to the corresponding node for unified processing, thereby reducing communication overhead. When a participant node sends a notification to the coordinator node because the transaction preparation timestamp is too old, the node will aggregate requests with the same destination address within a certain period of time into a batch and send them to the corresponding node for unified processing, thereby reducing communication overhead. In a distributed database deployment scenario with multiple replicas across regions, once the freshness of the consistency snapshot on a participant node exceeds the configured threshold, the participant node requests the replica of the coordinator node of the corresponding transaction within its region to obtain the known lower limit of the commit timestamp of the corresponding transaction, thereby avoiding the high latency overhead of cross-regional communication.

7. A distributed database system implementing the method of any one of claims 1-6, characterized in that, include: The system comprises a cluster management unit, a timestamp service unit, and several data service units. The cluster management unit stores and manages metadata and node information and routes requests. The timestamp service unit calculates and allocates monotonically increasing timestamps. The data service units parse SQL requests and perform data storage, data creation, deletion, modification, and querying, and transaction processing. The data service unit stores data from one or more data tables. Each data table is divided into one or more logical data partitions. Each data partition includes one or more physical data replicas. One replica serves as the primary replica, receiving writes to the data partition and possessing all the latest data of the data partition. The other replicas serve as secondary replicas, providing reads but not writes. The data replicas are distributed on different data service units as needed.

8. The distributed database system according to claim 7, characterized in that, The data service unit includes: an SQL parsing subunit, a refresh preparation subunit, a data storage subunit, and a transaction management subunit. Specifically: the SQL parsing subunit analyzes SQL statements and converts them into an internal representation, ensuring syntactic correctness and generating an execution plan to optimize database operations; the refresh preparation subunit handles outdated consistency snapshots from the transaction management subunit, queries transactions that have blocked local consistency snapshots, and notifies the corresponding data service units; it handles local transaction timeouts and consistency snapshot blocking notifications from other data service units, calculates the lower limit of the transaction commit timestamp based on the local transaction status, and sends refresh preparation requests to the relevant data service units; the data storage subunit receives and processes data change and query requests from the transaction management subunit, and manages all committed data version information on the data service units; the transaction management subunit executes transactions and manages temporary version data and transaction status information of uncommitted transactions on the data service units, maintains the security timestamp on the data service units, periodically calculates and updates the security timestamp, and checks the freshness of the consistency snapshot and the pending duration of local transaction coordination records.

Images