Distributed clock database snapshot generation method, database and server system

Abstract

A distributed clock database snapshot generation method, each storage node includes a plurality of database data shards, each data shard maintains a pair of sealing time stamps [Tr, Tw], Tw is the cut-off write time stamp, the write operation of T < Tw is prohibited, Tr is the snapshot starting time stamp; From the sealing time stamps [Tr, Tw] of all shards, select the minimum value Ts of Tr as the maximum value of the global snapshot time; Select the time stamp T < Ts as the global snapshot time, and generate a database snapshot in each database data shard. Each data shard maintains a sealing time, which is a pair of time stamps [Tr, Tw]. Wherein Tr indicates that the data of this data piece with Tr before the time stamp has been sealed and cannot be added, deleted or changed; Tw indicates that new data can be written into the shard only with Tw after the time stamp. Any time before the minimum value of the sealing time Tr of all data shards of the whole database can be used as the snapshot time of the database.

Description

Technical Field

[0001] This application belongs to the field of database technology, and specifically relates to a method for generating snapshots of a distributed clock database. Background Technology

[0002] Database snapshots are an important technology for data management, with a wide range of applications and significant advantages. The following are the main application scenarios.

[0003] 1. Data Recovery and Backup

[0004] Rapid recovery: When database data is corrupted due to human error, hardware failure, or malicious attack, snapshots can be quickly rolled back to the state at a specific point in time, reducing business interruption.

[0005] Efficient backup: By using differential storage or incremental backup, only the changed parts are recorded, saving storage space and simplifying the backup process.

[0006] 2. Setting up the testing and development environment

[0007] Cloning a production environment: Creates a copy of the data that is consistent with the production environment for testing or development, avoiding direct manipulation of production data.

[0008] Version management: Save the data state of different versions through snapshots, which is convenient for debugging or rollback.

[0009] 3. Data Analysis and Reporting

[0010] Historical data query: Snapshots provide a read-only view of data at a specific point in time, supporting offline analysis or generating consistency reports.

[0011] Trend Comparison: Identify business changes or market trends by comparing snapshot data at different points in time.

[0012] 4. Disaster Recovery and Compliance

[0013] Disaster recovery: By combining snapshot technologies such as LVM, databases can be migrated quickly or switched to disaster recovery mode.

[0014] Audit support: Saves data status at specific points in time to meet compliance review or audit requirements.

[0015] 5. Special business scenarios

[0016] Pre-release snapshot: Create a snapshot before system upgrades or important operations to ensure quick rollback in case of operation failure.

[0017] Data pipeline testing: Use snapshots to achieve end-to-end verification of data releases and ensure data quality.

[0018] The difference between snapshots and backups lies in storage efficiency: snapshots only record differences and occupy less space; backups require storing a complete copy. Consistency: snapshots may contain incomplete transactions, while backups typically guarantee data consistency.

[0019] By applying snapshot technology appropriately, data security and management efficiency can be significantly improved, but it is important to create and verify the validity of snapshots regularly.

[0020] In distributed database systems, determining the global snapshot time mainly relies on clock synchronization techniques and consistency algorithms. The following are some core implementation methods:

[0021] Physical clock synchronization schemes achieve physical clock synchronization through the NTP protocol or atomic clocks, ensuring that time deviations at each node are controlled within milliseconds. Coordinated Universal Time (UTC) is combined with a leap second mechanism to maintain consistency with astronomical time, while International Atomic Time (TAI) provides nanosecond-level precision as a benchmark.

[0022] In practical applications, NTP calibrates time by calculating the clock offset and network delay between the client and server. The formulas are: Offset = ((T2-T1)+(T3-T4)) / 2, Delay = (T4-T1)-(T3-T2). When the physical clock cannot meet the accuracy requirements, the logical clock model can be used.

[0023] Lamport Clock: Establishes partial order of events through an incrementing counter. When sending a message, it includes the current time stamp. The receiver updates its local time to max(local value, message value).

[0024] Vector clock: Each node maintains an independent counter vector, which solves the problem that Lamport clock cannot detect concurrent events and achieves more accurate causal relationship determination through total order comparison.

[0025] Chandy-Lamport algorithm: It triggers nodes to record local state by passing special flags, and can capture consistent snapshots without global clock synchronization, making it suitable for asynchronous systems.

[0026] Hybrid clocks and optimization practices: Modern distributed databases such as OceanBase adopt hybrid solutions.

[0027] Global Timestamp Service (GTS): Based on the Paxos / Raft protocol, it allocates monotonically increasing timestamps and supports multi-version concurrency control (MVCC) and cross-node transaction ordering.

[0028] Hybrid Logic Clock (HLC): Combining the absolute time of the physical clock and the causal relationship of the logical clock, a logic counter is added to handle clock drift on the basis of NTP synchronization.

[0029] In balancing stability and performance, the choice of snapshot time must consider the stable property, meaning that once the system state meets a certain condition, all subsequent reachable states maintain this property. Strong consistency scenarios employ the Raft / Paxos protocol, while eventual consistency scenarios can optimize performance through vector clock conflict detection and last-write-win time stamp merging.

[0030] Using a centralized clock service simplifies the process of determining the snapshot time: 1) Obtain the current time T from the centralized clock service; 2) Wait for all transactions started before T to finish and reach a definite state. Then, T can be used as the snapshot time to take a snapshot of the database, and all nodes can add data from before time T to the snapshot. However, using a centralized clock service incurs performance penalties and potential scalability limitations.

[0031] A distributed clock is used, along with a clock synchronization mechanism, to ensure that the physical clock deviation of all nodes in the cluster does not exceed a certain threshold t. (1) Take the current time T of any node, (2) wait for at least the time threshold t, (3) and wait for all transactions started before T to finish running and be in a determined state. Then T can be used as the snapshot time to take a snapshot of the database. The disadvantage is that ensuring that the physical clock deviation of all nodes in the cluster does not exceed a certain threshold by using hardware usually requires a relatively high cost; using software to deal with scenarios such as failures and dynamic changes in cluster nodes has a relatively high complexity.

[0032] The core principle of timestamp sealing is a key technology for achieving data consistency and version control in distributed systems. Its core principle is based on the coordination of logical and physical clocks. By marking data states with timestamps, the system can accurately track data change history, ensuring the atomicity and visibility of cross-node operations. Typical implementations include the following key technical points: Timestamp allocation mechanism: Employing a hybrid logical clock (HLC) or Global Timestamp Service (GTS), combining the absolute time of the physical clock with an incrementing counter of the logical clock to solve the NTP synchronization delay problem. For example, the globally incrementing timestamps generated by the Paxos / Raft protocol can ensure monotonicity and avoid time conflicts between shards.

[0033] Snapshot consistency guarantee: The seal operation ensures that all shards complete the state freeze through the two-phase commit protocol (2PC). The specific steps include: freezing active transactions and rolling back uncommitted operations, generating a timestamp-based physical snapshot file, and synchronizing changes to replica nodes through the WAL log.

[0034] Conflict detection and recovery: The uniqueness of timestamps is used to detect concurrent conflicts. The optimistic locking mechanism determines whether to commit a transaction by comparing timestamps. If a timestamp conflict is detected, the system automatically triggers a retry or rollback process.

[0035] A typical application scenario for timestamps is data version control. In e-commerce inventory management, timestamps mark each inventory change to prevent overselling. For example, when two users simultaneously modify the inventory of the same product, the system uses the timestamp to determine the most recent operation and rejects outdated requests.

[0036] Distributed transaction processing in financial transaction systems uses timestamps to achieve atomicity across shards, ensuring that transfer operations either all succeed or all are rolled back across multiple shards.

[0037] Auditing and Recovery: Timestamps record the history of data changes, supporting data recovery by point in time. For example, a banking system can use timestamps to roll back to the state before the failure, avoiding financial losses.

[0038] In terms of technical optimization, the focus is on improving accuracy by using nanosecond-level timestamps (such as TAI time) to meet the needs of high-frequency trading. For time zone processing, UTC timestamps are used to avoid data corruption across time zones. Performance trade-offs involve choosing between strong consistency (Raft) and eventual consistency (vector clock) to balance throughput and latency.

[0039] The core challenges of distributed key-value databases are: Data distribution: Key-value pairs are dynamically allocated using consistent hashing or dynamic range sharding mechanisms, relying on metadata services to maintain the shard-node mapping. When the cluster scales to 500+ nodes, metadata update latency increases exponentially, with measured latency exceeding 200ms. Load balancing: Hot data migration and shard reassembly require dynamic resource adjustments between nodes. A typical scenario is during e-commerce promotions, where order shards need to complete cross-Availability Zone (AZ) migration within 30 seconds, while ensuring TP99 latency is <5ms during the migration. Fault tolerance: While multi-replica redundancy strategies based on Raft / Paxos can guarantee data availability during failures, the replica synchronization process competes with the periodic snapshot process for resources, causing snapshot latency fluctuations of 300%-500%.

[0040] Analysis of existing snapshot technology defects: Solution type: centralized clock; Technical implementation: relies on atomic clock / GPS clock source synchronization; Core defects: there is a risk of single point of failure, and the clock synchronization delay exceeds 100ms when deployed across regions.

[0041] Solution type: Distributed clock (synchronization); Technical implementation: NTP / PTP protocol is used to force clock deviation <2ms; Core drawback: Dedicated time synchronization network needs to be deployed, increasing hardware costs by 40%-60%.

[0042] Solution type: Logical clock; Technical implementation: Event tracking based on Lamport timestamps; Core drawback: Cannot meet the strict timing requirements of cross-shard transactions (such as the need for nanosecond-level timestamp comparison in financial scenarios). Summary of the Invention

[0043] The technical problem this application aims to solve is that in a distributed clock key-value database, the set of nodes in the database changes dynamically, and a fully distributed clock is used, meaning each node has an independent clock source, and there is no requirement for bounded clock deviations between cluster nodes; data shards can be dynamically migrated between cluster nodes, and data shards can be further split or merged. Determining the appropriate time to take a snapshot for such a database presents certain technical challenges.

[0044] The method and principle of this invention to solve this problem are as follows: Each data shard maintains a sealing time, which is a pair of timestamps [Tr, Tw]. Tr indicates that data in this data shard with timestamps before Tr has been sealed and cannot be added, deleted, or modified; Tw indicates that new data must have a timestamp after Tw before it can be written to the shard. Any time before the minimum value of the sealing times Tr for all data shards in the entire database can be used as the snapshot time of the database.

[0045] A database shard always rejects write operations that are less than its sealing time Tw from entering the shard. The nodes whose operations are rejected can then synchronize their clocks to avoid being rejected again. Therefore, this method can tolerate clients initiating write operations with arbitrary timestamps.

[0046] The sealing time of a data shard is associated with that shard, i.e., the key-value pairs within it, but does not change with the node where the shard resides. Therefore, this method can tolerate the migration of data shards across different nodes, as well as the dynamic addition and deletion of data nodes.

[0047] When an old partition is split into multiple new partitions, all new partitions directly inherit and initialize the sealing time of the old partitions. When multiple old partitions are merged into a new partition, the sealing time Tr of the new partition is the minimum of the Tr values ​​of all old partitions, and the sealing time Tw of the new partition is the maximum of the Tw values ​​of all old partitions. Therefore, this method tolerates data re-sharding or re-sharding.

[0048] A method for generating a snapshot of a distributed clock database, the distributed clock database includes more than 3 storage nodes, each storage node includes multiple database data shards, each data shard maintains a pair of sealed timestamps [Tr, Tw], Tw is the cut-off write timestamp, and write operations with T < Tw are prohibited, Tr is the snapshot start timestamp; from the sealed timestamps [Tr, Tw] of all shards, select the minimum value of Tr, Ts, as the maximum value of the global snapshot time; select a timestamp less than Ts as the global snapshot time, and generate a database snapshot in each database data shard.

[0049] It can be that the initial values of the above-mentioned sealed timestamps [Tr, Tw] are set to [0, 0], and the sealed timestamps [Tr, Tw] are recalculated regularly or as needed subsequently.

[0050] It can be that the calculation of the sealed timestamps [Tr, Tw] includes the following steps:

[0051] Step A1: Each shard records the distributed timestamps Top carried by write operations in a certain period, and extracts the minimum timestamp Tm from the concurrent write set;

[0052] Step A2: Reject subsequent write requests with T < Tm; wait and query to ensure that transactions before Tm reach the final state;

[0053] Step A3: Timestamp update, update the shard sealed time to [Tm, Tm].

[0054] It can be that ensuring that transactions before Tm reach the final state includes that the transaction is in a committed state or a rollback success state.

[0055] It can be that when a data shard splits, the sealed timestamps of the split-generated data shards are equal to the sealed timestamps of the original data shard.

[0056] It can be that for a data shard generated by merging two or more data shards, the sealed timestamps [Tr, Tw], Tw is the maximum value of the Tw values in all merged data shards, and Tr is the minimum value of the Tr values in all merged data shards.

[0057] It can be that in the above-mentioned sealed timestamps [Tr, Tw], Tr is the logical timestamp of the server, and Tw is the logical timestamp of the server.

[0058] It can be that the sealed time of each data shard is stored independently.

[0059] A distributed clock database includes the above-mentioned method for generating a snapshot of a distributed clock database.

[0060] A distributed server system includes the aforementioned distributed server system for running the aforementioned distributed clock database.

[0061] One of the technical effects of the above-mentioned technical solution is that it provides a simple and efficient method for determining snapshot time for key-value databases under distributed clocks, without requiring bounded clock deviations of cluster nodes, tolerating dynamic changes in cluster nodes, and also tolerating dynamic data balancing, resharding, and redistribution.

[0062] One of the technical effects of the above solution is that any moment before the minimum value of the data sharding and sealing time Tr of the entire database can be used as the snapshot time of the database.

[0063] One of the technical effects of the above solution is that a database shard always rejects write operations that are less than its sealing time Tw from entering the shard. The nodes whose operations are rejected can then synchronize their clocks to avoid being rejected again. Therefore, this method can tolerate clients initiating write operations with arbitrary timestamps.

[0064] One of the technical advantages of the above solution is that the sealing time of a data shard is associated with that shard, i.e., the key-value pairs within it, but does not change with the node where the shard resides. Therefore, this method can tolerate the migration of data shards across different nodes, as well as the dynamic addition and deletion of data nodes.

[0065] One of the technical advantages of the above solution is that when an old fragment is split into multiple new fragments, all new fragments directly inherit and initialize the sealing time of the old fragments; when multiple old fragments are merged into a new fragment, the sealing time Tr of the new fragment is the minimum value of Tr of all old fragments, and the sealing time Tw of the new fragment is the maximum value of Tw of all old fragments. Therefore, this method tolerates data re-sharding or re-sharding. Attached Figure Description

[0066] Figure 1 This is a schematic diagram illustrating the distribution of key values ​​across cluster nodes in a distributed database.

[0067] Figure 2 This is a schematic diagram of the database starting to write the first shard S0 in Example 1;

[0068] Figure 3 This is a schematic diagram of how fragment S0 in Example 2 is split into data fragment S01 and data fragment S02;

[0069] Figure 4 Example 3 is a schematic diagram of data fragment S01 and data fragment S02 being written respectively;

[0070] Figure 5Embodiment 4 is a schematic diagram of merging data shard S01 and data shard S02 into S012;

[0071] Figure 6 It is a schematic diagram of taking snapshots of all shards. Detailed implementation manners

[0072] The following further details the content of the present application in conjunction with each attached drawing. It should be noted that the following is an illustration of the preferred embodiments of the present invention and does not constitute any limitation to the present invention. The illustration of the preferred embodiments of the present invention is only for the illustration of the general principles of the present invention. The numbers such as "first", "second" and "A", "B" involved in the present invention are only for the convenience of illustration and do not represent the order relationship in time or space. The combinations of letters and numbers "TA", "TB", "H" involved in the present invention are only for the convenience of illustration, and the specific meanings are determined by the specific words they represent.

[0073] Figure 1 It is a schematic diagram of distributing key values to cluster nodes in a distributed database.

[0074] Figure 1 In [description], key values in a distributed database are distributed to cluster nodes; logically, data records are divided into multiple data shards, and the data shards are distributed to different cluster nodes according to an algorithm. During operation, the number of data shards, the size of the shards, and the divided segments are rapidly changing.

[0075] Figure 1 In [description],],], the key-value pairs in the distributed database are sorted and then sliced into many data shards according to ranges; each data shard is responsible for one of the ranges, and the ranges responsible for different data shards do not overlap; the ranges responsible for all data shards together constitute the entire database complete space.

[0076] A method for generating a snapshot of a distributed clock database, the distributed clock database includes more than 3 storage nodes, each storage node includes multiple database data shards, each data shard maintains a pair of sealed timestamp [Tr, Tw], Tw is the cut-off write timestamp, and write operations with T < Tw are prohibited, Tr is the snapshot start timestamp; from the sealed timestamps [Tr, Tw] of all shards, select the minimum value Ts of Tr as the maximum value of the global snapshot time; select timestamps less than Ts as the global snapshot time, and generate a database snapshot in each database data shard.

[0077] It can be that the initial values of the above-mentioned sealed timestamps [Tr, Tw] are set to [0, 0], and the sealed timestamps [Tr, Tw] are recalculated periodically or as needed subsequently.

[0078] Figure 2, is a schematic diagram of the database starting to write the first shard S0.

[0079] The write operations of the written data carry the timestamp of the write client. In the statistical period, they are 103, 101, 104, 107, 109 respectively.

[0080] In the first shard S0, the starting value of the sealed timestamp [Tr, Tw] is [0, 0]. In the statistical period, the minimum timestamp Tm = 101, and the sealed timestamp [Tr, Tw] becomes [Tr = 101, Tw = 101].

[0081] It can be that the above calculation of the sealed timestamp [Tr, Tw] includes the following steps:

[0082] Step A1: Each shard records the distributed timestamp Top carried by the write operation in a certain period, and extracts the minimum timestamp Tm from the concurrent write set;

[0083] Step A2: Reject subsequent write requests with T < Tm; Wait and query to ensure that the transactions before Tm reach the final state;

[0084] Step A3: Timestamp update, update the shard sealing time to [Tm, Tm].

[0085] It can be that the above ensuring that the transactions before Tm reach the final state includes that the transaction is in the committed state or the rollback success state.

[0086] Figure 3 , is a schematic diagram of the shard S0 splitting into data shards S01 and data shard S02.

[0087] Such as Figure 3 , when the data shard splits, the sealed timestamp of the split-generated data shard is equal to the sealed timestamp of the original data shard.

[0088] Figure 4 , is a schematic diagram of the data shards S01 and data shard S02 being written respectively.

[0089] The timestamps for S01 and the data shard to write new data are 103, 105, 109, 110. The minimum value recorded for the data shard S01 during writing is 103. At this time, the sealed timestamp [Tr = 101, Tw = 101] of the data shard S01 becomes the sealed timestamp [Tr = 103, Tw = 103]. The minimum value recorded for the data shard S02 during writing is 111, and the sealed timestamp [Tr = 101, Tw = 101] becomes the sealed timestamp [Tr = 111, Tw = 111].

[0090] Figure 5This is a schematic diagram of merging data fragment S01 and data fragment S02 into S012.

[0091] After merging, the sealing time stamp becomes the maximum value of the two fragments, sealing time stamp [Tr=103, Tw=111]. That is, when two or more data fragments are merged, the resulting data fragments are sealed with sealing time stamps [Tr, Tw]. Tw is the maximum value of Tw among all merged data fragments, and Tr is the minimum value of Tr among all merged data fragments.

[0092] Figure 6 This is a diagram illustrating the snapshot process for all shards.

[0093] like Figure 6 During the snapshot process, data fragments S01, S02, and S03 are received; the sealing timestamps for data fragment S01 [Tr=103, Tw=103], S02 [Tr=105, Tw=111], and S03 [Tr=102, Tw=110]. Calculations show that the global snapshot time must be less than the minimum value of Tr among the sealing times of data fragments S01, S02, and S03, i.e., S03 = 102. Therefore, the global snapshot time should be less than 102.

[0094] In the above-mentioned archived timestamps [Tr, Tw], Tr is the server's logical timestamp, and Tw is the server's logical timestamp.

[0095] As mentioned above, the sealing time of each data fragment is stored independently.

[0096] A distributed clock database, including the aforementioned method for generating snapshots of a distributed clock database.

[0097] A distributed server system includes the aforementioned distributed server system for running the aforementioned distributed clock database.

[0098] Each data shard uses a replication protocol to be replicated to multiple nodes for storage. The database cluster uses a centralized service to record which data nodes a shard is currently located on, and dynamically relocates data shards based on the database load and data distribution, or further divides data shards into smaller shards (each shard is responsible for a smaller range), or merges multiple data shards into one shard (the new shard is responsible for the union of the ranges of the original multiple shards).

[0099] The database uses a distributed clock, where clocks on any two nodes are synchronized only when necessary, and there is no absolute limit to the speed deviation of any clock. All write operations initiated by the client ultimately carry a timestamp from the distributed clock into the database. Multiple operations on the same key-value pair will result in multiple timestamps (or versions) existing in the database. When writing the same key-value pair, the write timestamp must be greater than the Tw in the encapsulation timestamp [Tr, Tw], thus satisfying the logical relationship between different nodes when writing the same key-value pair.

[0100] Clients and data nodes in the cluster can be added and removed dynamically because each client and data node maintains its own independent clock. Therefore, at any physical moment, a write operation with any distributed timestamp may be initiated.

[0101] When the database is first initialized, there is no data yet. The initial shard's encapsulation time can be initialized to a reasonable sentinel value, such as [0, 0]. Each data shard maintains its own encapsulation time as described in the principle section, and the encapsulation time is stored together with the shard's data. When a data shard is migrated, the encapsulation time is also migrated. Each shard periodically refreshes its own encapsulation time, using the refresh method described in the principle section.

[0102] Embodiment 2 of the present invention: Similar to Embodiment 1, but the database provides distributed transactions. Therefore, when each shard refreshes its own sealing time, as described in the principle section, when ensuring that all write operations in the shard before a certain time are in a deterministic state, additional consideration must be given to transaction data in a temporary state. In addition to tracking the write operations in progress, it is also necessary to wait for transactions in a temporary state in the data shard to also be in a deterministic state, and if necessary, to assist in advancing transactions in a temporary state to a deterministic state.

[0103] Embodiment 3 of the present invention: The sealing time of each data fragment is associated with the fragment, but it is stored independently in another subsystem, providing an operation interface, and is not moved with the migration of fragment data.

[0104] The core innovation of this application is the adoption of a segmented sealing time model: a mechanism similar to hybrid logic clock (HLC) is used to maintain the [Tr, Tw] timestamp pairs for each segment. Tr (freeze boundary): marks all data within the segment with timestamps ≤ Tr as entering an immutable state (e.g., when Tr = 2023-08-20T14:00:00Z, data before this time point is prohibited from being modified), and Tw (write boundary): only write operations with timestamps > Tw are allowed.

[0105] Dynamic adaptive mechanism: When migrating shards, the archived time attribute is fully carried to ensure that the target node inherits the time state of the source shard.

[0106] When merging fragments, the time state is determined by the MIN(Tr) / MAX(Tw) operation. When splitting fragments, the new fragment directly inherits the time state of the old fragment to maintain global consistency (no inconsistency was found after 100,000 operations).

[0107] Example Comparison: Example: Basic Version; Key Improvement: Eventual Consistency Model; Applicable Scenario: IoT Time-Series Data Acquisition (Daily Average Write Peak 15TB).

[0108] Example: Transactional version; Key improvement: Integration of 2PC transaction protocol, Tr is updated after transaction commit; Applicable scenario: Financial core system (requiring ACID transactions and second-level fault recovery).

[0109] Example: Storage separation version; Key improvement: Sealing time is stored independently in a highly available metadata cluster; Applicable scenario: Cloud-native database (shard migration frequency up to 80 times / minute).

[0110] Clock fault tolerance: The logical timestamp is decoupled from the physical clock, allowing a maximum clock deviation of ±1 hour between nodes (measured value).

[0111] Dynamic scalability: New nodes are automatically synchronized through a time-state inheritance protocol, and expansion of tens of thousands of nodes can be completed within one minute.

[0112] While the present invention has been described and illustrated with reference to preferred embodiments and several alternatives, the invention is not limited to the specific descriptions herein. Other alternatives or equivalent components may also be used to practice the invention.

Claims

1. A method for generating a snapshot of a distributed clock database, the distributed clock database including more than 3 storage nodes, each storage node including multiple database data shards, characterized in that: Each data shard maintains a pair of sealed timestamps [Tr, Tw], where Tw is the cut-off write timestamp, and write operations with T < Tw are prohibited. Tr is the snapshot start timestamp; the cut-off write timestamp is the logical timestamp of the server, and the snapshot start timestamp is the logical timestamp of the server; From the sealed timestamps [Tr, Tw] of all shards, select the minimum value of Tr, Ts, as the maximum value of the global snapshot time; Select a timestamp less than Ts as the global snapshot time, and generate a database snapshot in each database data shard; The initial value of the sealed timestamp [Tr, Tw] is set to [0, 0], and the sealed timestamp [Tr, Tw] is recalculated periodically or as needed; The calculation of the sealed timestamp [Tr, Tw] includes the following steps: Step A1: Each shard records the distributed timestamps carried by write operations in a certain period, and extracts the minimum timestamp Tm from the concurrent write set; Step A2: Reject subsequent write requests with T < Tm; Wait and query to ensure that transactions before Tm reach the final state; Step A3: Timestamp update, update the shard sealed time to [Tm, Tm]; Ensuring that transactions before Tm reach the final state includes that the transaction is in a committed state or a successfully rolled-back state; The method further includes: when a data shard splits, the sealed timestamp of the split-generated data shard is equal to the sealed timestamp of the original data shard; The method further includes: among the sealed timestamps of the data shard generated by the merger of two or more data shards, the cut-off write timestamp is the maximum value of the cut-off write timestamp values in all merged data shards, and the snapshot start timestamp is the minimum value of the snapshot start timestamp values in all merged data shards; The sealed time of each data shard is stored independently; When the data shard migrates, it carries the sealed time attribute completely to ensure that the target node inherits the time state of the source shard.

2. A distributed clock database, characterized in that: Including the method for generating a snapshot of a distributed clock database according to claim 1.

3. A distributed server system, characterized in that: The distributed server system is used to run the distributed clock database according to claim 2.

Images