Multi-version concurrency control method of openGauss database under distributed multi-write architecture

Abstract

The invention relates to a multi-version concurrency control method of an openGauss database under a distributed multi-write architecture. The method comprises the steps that xid is generated when a tuple is created, and xmin and xmax information is recorded in the tuple; calculating triple information of segmental id, timestamp and self-increasing id through xid, and determining a unique storage position of a transaction state in a cluster; generating a transaction snapshot, wherein the transaction snapshot comprises oldestxid and timestamp information; obtaining a global oldestxid (oldestxid); judging whether the tuple is visible to the current transaction or not by querying a historical tuple update linked list and combining a transaction snapshot, xmin and xmax information in the tuple and transaction state information; dead tuple cleaning and tuple freezing are conducted regularly. According to the method, the problem that an existing MVCC technology is not applicable under a distributed multi-write architecture is solved, the application scene of the MVCC technology is expanded, and a feasible multi-version concurrency control solution is provided for a distributed multi-write architecture database.

Description

Technical Field

[0001] The present invention relates to the technical field of multi-version concurrency control methods, and in particular to a multi-version concurrency control method for an openGauss database under a distributed multi-write architecture. Background Art

[0002] openGauss is a single-node, centralized database. As user business pressure increases, due to the limitations of single-node memory, CPU, hard disk, network and other conditions, the single-node database can easily reach a system bottleneck.

[0003] When the traditional single-node database cannot meet user needs, we need to expand the centralized database into a distributed database, improve database performance by increasing the number of database nodes, solve the single-node bottleneck problem, and achieve horizontal expansion of data performance.

[0004] Multi-version concurrency control, also known as MVCC (Multi-Version Concurrency Control), is a key technology for databases to achieve data isolation and consistency. openGuass is a single-node database, and the existing MVCC technology is not applicable in a distributed multi-write architecture. If it needs to be expanded to a distributed multi-write architecture, the MVCC technology needs to be adjusted and improved. Summary of the invention

[0005] In order to solve the problem that the existing MVCC technology is not applicable in a distributed multi-write architecture, the present invention improves and expands the current single-node MVCC technology, and proposes a new multi-version concurrency control method for the openGauss database in a distributed multi-write architecture.

[0006] The MVCC solution proposed in this invention is applicable to the following forms of distributed multi-write architecture, such as Figure 1 As shown, this architecture contains the following nodes:

[0007] Primary node: also known as master. Responsible for the management of the entire node and the generation of a globally unique transaction ID.

[0008] Internal high-speed network: also known as interconnect. The internal network of the cluster, the master and segments are connected and communicated with each other through the interconnect network.

[0009] Data node: also known as segment. Horizontal expansion of the database cluster is achieved by adding segments. Segments are connected to each other through interconnects. Each client can choose to connect to any segment, and each segment can read and write data.

[0010] Storage: Also known as storage. Each storage stores a portion of data.

[0011] Specifically, the present invention provides a multi-version concurrency control method for an openGauss database under a distributed multi-write architecture, such as Figure 8 As shown, the method comprises the following steps:

[0012] S1. When creating a tuple, the segment applies for a new transaction id from the master, generates xid, and records the following information in the tuple: xmin, which indicates the transaction that creates the tuple; xmax, which indicates the transaction that updates or deletes the tuple; data, which indicates the data to be stored in the tuple;

[0013] S2. Calculate the segment_id, timestamp, and auto-increment id triple information through xid, and determine the unique storage location of the transaction status in the cluster based on the triple information;

[0014] S3. The transaction snapshot is generated by the segment node. The transaction snapshot contains the following information: oldest_xid, which indicates the minimum active xid of the database cluster when the transaction snapshot was generated; timestamp, which indicates the timestamp when the transaction snapshot was generated;

[0015] S4. The background thread of each segment continuously traverses all sessions, obtains all active xids, and calculates the minimum active xid of the current segment. The segment broadcasts the local minimum active xid to other nodes. After receiving the broadcast message, other nodes update the global minimum active xid to obtain the oldest_xid.

[0016] S5. By querying the historical tuple update linked list generated when the tuple is updated, combined with the transaction snapshot, the xmin and xmax information in the tuple, and the transaction status information, determine whether the tuple is visible to the current transaction;

[0017] S6. Perform dead tuple cleaning and tuple freezing. When a tuple is not visible to all active transactions in the database, it is defined as a dead tuple. Dead tuples are cleaned up regularly to release hard disk space. Perform xid freezing and set the xid in the committed state to a special value, indicating that the xid is visible to all transactions (no need to query transaction status information and commit time information). After dead tuple cleaning and tuple freezing are completed, clean up transaction status and transaction commit time that are less than oldest_xmin to release hard disk space.

[0018] Furthermore, when deleting a tuple, the method of the present invention does not directly clean up the old tuple and its data, but adopts a marked deletion, where the segment applies for a new xid from the master, and at the same time modifies the xmax in the tuple to the new xid, indicating that the tuple is deleted by the new xid transaction.

[0019] Furthermore, when the method of the present invention updates a tuple, the database does not immediately delete the old tuple data, but instead modifies xmax to a new xid in the old tuple (the new xid refers to the xid transaction that updates the tuple), then creates a new tuple with the new xid, and generates a historical tuple update linked list.

[0020] Furthermore, the xid in step S1 of the method of the present invention is a 64-bit integer, wherein:

[0021] (1) The first 8 bits are segment_id. Each segment has a unique identifier in the cluster. segment_id indicates which segment the xid is assigned to (when comparing xid sizes, segment_id needs to be removed. The role of segment_id is only to mark the segment that applied for the xid).

[0022] (2) The middle 32 bits are the timestamp, in seconds;

[0023] (3) The last 24 bits are the auto-increment ID, which increases monotonically. When the timestamp changes, the auto-increment ID is reset to 0.

[0024] Furthermore, the transaction status described in step S2 of the method of the present invention includes: not_start, in_progress, committed, aborted;

[0025] When the transaction status changes, the segment records the transaction and its status on the storage according to the following rules:

[0026] (1) When a segment requests a new xid from the master, the segment records the xid status as in_progress on its corresponding storage;

[0027] (2) When the client's SQL is executed and the transaction is committed, the segment updates the xid status to committed;

[0028] (3) When an error occurs during SQL execution or the client displays a rollback transaction, the segment updates the xid status to aborted.

[0029] Furthermore, the method of the present invention also includes:

[0030] (1) When updating the xid status, first update the transaction status of the local segment, and then broadcast the transaction status to other nodes. After receiving the broadcast message, other nodes update the xid status in the local segment;

[0031] (2) When querying the xid status, first query the xid status in the current segment. If it is already cached locally, there is no need to perform a remote query. If it is not cached locally, query the segment to which the xid belongs through a network request, and cache the query results locally. The cached results will be used directly the next time the query is made.

[0032] Furthermore, the visibility judgment rule for judging whether the tuple is visible to the current transaction in step S5 of the method of the present invention is as follows:

[0033] (1) If xid is less than oldest_xid, its status must be committed or aborted;

[0034] (2) If the transaction status is not committed, it means that the transaction has not been committed or has been rolled back, and the xid is not visible;

[0035] (3) If the transaction commit time is greater than the transaction snapshot application time, it means that the transaction has not been committed when the snapshot is applied, and the xid is not visible;

[0036] (4) Except for the cases in rules (2) and (3), xid is visible in other cases. The visibility of the tuple is obtained based on the visibility of xid corresponding to xmin and xmax in the tuple.

[0037] (5) The xmin in the historical tuple is not visible, which means that the transaction that created the tuple was not committed or rolled back, so the tuple is not visible;

[0038] (6) If xmax in the historical tuple is visible, it means that the transaction that deleted or updated the tuple has been committed, and the tuple is not visible;

[0039] (7) Except for the cases in rules (5) and (6), all other tuples are visible.

[0040] Furthermore, the dead tuple cleaning and tuple freezing described in step S6 of the method of the present invention are carried out according to the following rules:

[0041] (1) When the xmin or xmax of a tuple is greater than oldest_xmin, there may still be active transactions that are visible to the tuple, and the tuple does not need to be cleaned up or frozen;

[0042] (2) If the xmin of the tuple is less than oldest_xmin and the transaction status is not committed, the tuple is a dead tuple and is deleted.

[0043] (3) The xmax of the tuple is less than oldest_xmin, and the transaction status is committed, indicating that the tuple is a dead tuple and is deleted;

[0044] (4) Freeze the remaining tuples. When freezing, xmin is set to a special value (the engineering implementation value is 1) and xmax is set to 0, indicating that the tuple is visible to any transaction.

[0045] On the other hand, the present invention also provides a multi-version concurrent control system of an openGauss database under a distributed multi-write architecture. When the system is running, the steps of the multi-version concurrent control method of the openGauss database under a distributed multi-write architecture are implemented.

[0046] In addition, the present invention also provides a computer-readable storage medium, on which a computer program is stored. When the program is executed by a processor, the steps of the multi-version concurrency control method of the above-mentioned openGauss database under the distributed multi-write architecture are implemented.

[0047] In summary, the multi-version concurrency control method of the openGauss database in a distributed multi-write architecture of the present invention solves the problem that the existing MVCC technology is not applicable in a distributed multi-write architecture, expands the applicable scenarios of the MVCC technology, and provides a practical multi-version concurrency control solution for a distributed multi-write architecture database. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] In order to more clearly illustrate the technical solution of the present invention, the following briefly introduces the drawings required for use in the description of the present invention. Obviously, the following drawings are only some embodiments recorded in the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without paying any creative work.

[0049] Figure 1 The figure is a schematic diagram of the distributed multi-write architecture applicable to the method of the present invention.

[0050] Figure 2 An example graph is created for tuples according to one embodiment of the present invention.

[0051] Figure 3 The figure is an example diagram of tuple deletion according to an embodiment of the present invention.

[0052] Figure 4 The figure is an example diagram of tuple update according to an embodiment of the present invention.

[0053] Figure 5 FIG. 4 is a schematic diagram of a xid composition structure according to an embodiment of the present invention.

[0054] Figure 6 The update chain diagram of the historical tuples according to one embodiment of the present invention is shown in FIG.

[0055] Figure 7 The figure is a schematic diagram of a tuple visibility determination process according to an embodiment of the present invention.

[0056] Figure 8 It is a flow chart for implementing the method of the present invention. DETAILED DESCRIPTION

[0057] In order to make the purpose, technical solution and advantages of the present invention clearer, the technical solution of the present invention will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. The present invention can also be implemented or applied through other different specific implementation methods. The details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present invention.

[0058] At the same time, it should be understood that the protection scope of the present invention is not limited to the specific embodiments described below; it should also be understood that the terms used in the embodiments of the present invention are for describing specific embodiments rather than for limiting the protection scope of the present invention.

[0059] Embodiment: A multi-version concurrent control method for openGauss database under distributed multi-write architecture

[0060] (I) Tuple creation

[0061] like Figure 2 As shown, when creating a tuple, the segment applies to the master for a new transaction id (hereinafter referred to as xid), corresponding to Figure 2 The xid1 in the tuple records the following information:

[0062] xmin=xid1, indicating that the transaction that created the tuple is xid1;

[0063] xmax=0, indicating that the tuple is in the creation state and has not been updated or deleted by other transactions;

[0064] data is the data that the tuple actually wants to store.

[0065] (II) Tuple deletion

[0066] like Figure 3As shown, when a tuple is deleted, the segment applies to the master for a new xid (corresponding to Figure 3 At the same time, the xmax in the tuple is modified to xid2, indicating that the tuple was deleted by the xid2 transaction.

[0067] (III) Tuple Update

[0068] like Figure 4 As shown in the figure, the tuple is created by transaction xid1, and then transaction xid3 updates the tuple. At this time, the database will not delete the old tuple data immediately, but mark xmax as xid3 in the old tuple and create a new tuple with xid3. The update of the tuple can be understood as deleting the tuple first and then creating a new tuple to form a historical tuple update list.

[0069] (IV) Status of transactions

[0070] When the transaction status changes, the segment records the transaction and its status on the storage.

[0071] (1) When a segment requests a new xid from the master, the segment records the xid status as in_progress on its corresponding storage.

[0072] (2) When the client's SQL execution is completed and the transaction is committed, the segment updates the xid status to committed.

[0073] (3) When an error occurs during SQL execution, or the client displays a rollback of the transaction, the segment updates the xid status to aborted.

[0074] (V) Tuple Query

[0075] When querying a tuple, a transaction snapshot is requested from the segment. The segment traverses the history linked list of the tuple and determines whether the tuple is visible based on the transaction snapshot, the xid of the created tuple (i.e. xmin), the xid of the deleted tuple (i.e. xmax), and the transaction status.

[0076] Transaction snapshots and visibility judgment rules are described in detail later.

[0077] The following is an example of how to implement this method:

[0078] (I) Generation of xid

[0079] xid is a 64-bit integer number, such as Figure 5 As shown, where:

[0080] (1) 8 bits are segment_id. Each segment has a unique identifier in the cluster. Segment_id indicates which segment the xid is assigned to. It can represent up to 256 machines. The cluster can be expanded to a maximum of 256 segments.

[0081] (2) The 32 bits are the timestamp, measured in seconds, starting from the year 2020, representing approximately 68 years.

[0082] (3) The last 24 bits are a monotonically increasing auto-increment ID. When the timestamp changes, the auto-increment ID is reset to 0. A maximum of 16.77 million transactions can be expressed per second.

[0083] Since the number of transactions generated per second in the actual production environment is far from reaching 16.77 million, xid can be guaranteed to increase monotonically (note that when comparing xid sizes, segment_id needs to be removed. The role of segment_id is only to mark the segment that applies for the xid. This will not be repeated later when comparing xid sizes).

[0084] (II) Storage and query of transaction status

[0085] There are four states for a transaction, namely not_start (0b00), in_progress (0b01), committed (0b10), and aborted (0b11). It takes 2 bits to store a transaction state, and 1 byte can store the states of 4 transactions.

[0086] Through xid, calculate the segment_id, timestamp, and auto-increment id triple information, and determine the unique storage location of the transaction status in the cluster based on the triple information.

[0087] Example:

[0088] Taking xid equal to 245074456798560365 as an example, it is calculated that segment_id = 3, then the status of the transaction is saved on the node with segment_id 3.

[0089] Timestamp = 1722674053, then the transaction status is stored in a file named "1722674053.clog".

[0090] If the self-increment id is 109, the transaction status is stored in the "1722674053.clog" file, with an offset of 27 bytes, the 3rd and 4th bits (calculated based on the fact that 1 byte can store 4 transaction statuses).

[0091] Through the above solution, we determine the unique storage location of the transaction status in the database cluster based on the xid. If the queried xid is located on other nodes, it needs to be sent to the segment to which the xid belongs through a network request for query. To reduce the overhead of network requests, we adopt the following strategy to avoid network requests for each query and improve query efficiency:

[0092] (1) When updating the status of xid, first update the transaction status of the local segment, and then broadcast the transaction status to other nodes. After receiving the broadcast message, other nodes update the xid status in the local segment.

[0093] (2) When querying the xid status, first query the xid status in the current segment. If it is already cached locally, there is no need to perform a remote query. If it is not cached locally, query the segment to which the xid belongs through a network request, and cache the query results locally. The cached results will be used directly the next time the query is made.

[0094] In addition, through a similar method, we can record the commit time of each transaction in storage.

[0095] (III) Transaction snapshot

[0096] The transaction snapshot is generated by the segment node and contains the following information:

[0097] oldest_xid: The smallest xid in which the database cluster is still active when the snapshot is generated.

[0098] timestamp: the timestamp when the snapshot was generated.

[0099] Each segment has a background thread that continuously traverses all sessions, obtains all active xids, and calculates the minimum active xid of the current segment. The segment broadcasts the local minimum active xid to other nodes. After receiving the broadcast message, other nodes update the global minimum xid to obtain the oldest_xid.

[0100] Note that the oldest_xid calculated by the above method will be smaller than the actual oldest_xid of the database. Therefore, transactions smaller than the oldest_xid must be in the committed or abrotted state.

[0101] (IV) Historical tuple query and visibility judgment rules

[0102] According to the previous introduction, when a tuple is deleted, the old tuple and its data will not be directly cleaned up, but marked for deletion; when a tuple is updated, an update list of historical tuples will be generated. Figure 6 shown.

[0103] By querying the historical tuple update list, combined with the transaction snapshot, the xmin and xmax information in the tuple, and the transaction status information, it can be determined whether the tuple is visible to the current transaction, such as Figure 7 As shown, the visibility judgment rules are as follows:

[0104] 1. If xid is less than oldest_xid, its status must be committed or aborted.

[0105] 2. If the transaction status is not committed, it means that the transaction has not been committed or has been rolled back, and the xid is not visible.

[0106] 3. The transaction commit time is greater than the snapshot application time, which means that the transaction has not been committed when the snapshot is applied, so the xid is not visible.

[0107] 4. If one of the cases in rules 2 and 3 is true, xid is not visible, otherwise xid is visible. Then, according to the visibility of xid corresponding to xmin and xmax in the tuple, the visibility of the tuple can be finally obtained.

[0108] 5. The xmin in the historical tuple is invisible, which means that the transaction that created the tuple was not committed or rolled back, and the tuple is invisible.

[0109] 6. If xmax in the historical tuple is visible, it means that the transaction that deleted or updated the tuple has been committed, and the tuple is not visible.

[0110] 7. If one of the cases in rules 5 and 6 is true, the tuple is not visible; otherwise, the tuple is visible.

[0111] (V) Dead Tuple Cleanup and Tuple Freezing

[0112] When tuples are updated or deleted, the database will not clean up these historical tuples immediately. At a certain moment, when a tuple is invisible to all active transactions in the database, the historical tuple is called a dead tuple. The database needs to clean up dead tuples regularly to release the hard disk space occupied by the dead tuples.

[0113] As the transaction progresses, the database keeps adding transaction status and transaction commit time, which takes up a lot of disk space. The database freezes the xid by setting the xid in the committed state to a special value, indicating that the xid is visible to all transactions (no need to query transaction status information and commit time information).

[0114] The rules for dead tuple cleanup and tuple freezing are as follows:

[0115] (1) If the xmin or xmax of a tuple is greater than oldest_xmin, and there may be active transactions that are visible to the tuple, the tuple does not need to be cleaned up or frozen.

[0116] (2) The tuple's xmin is less than oldest_xmin and the transaction status is not committed, indicating that the tuple is a dead tuple and can be deleted.

[0117] (3) The tuple's xmax is less than oldest_xmin and the transaction status is committed, indicating that the tuple is a dead tuple and can be deleted.

[0118] (4) The remaining tuples can be frozen. When freezing, xmin is set to a special value (the engineering implementation value is 1) and xmax is set to 0, indicating that the tuple is visible to any transaction.

[0119] The database periodically cleans up dead tuples and freezes tuples for all tuples. After the cleanup and freezing are completed, the transaction status and transaction commit time that are less than oldest_xmin are no longer needed and can be safely cleaned up to free up hard disk space. The cleanup and freezing of dead tuples are completed separately by each segment.

[0120] The above description is only a preferred embodiment of the present invention and does not limit the present invention in any form. Any technician familiar with the profession can make some changes or modifications to the technical contents disclosed above without departing from the scope of the technical solution of the present invention to obtain equivalent embodiments of equivalent changes. However, any simple modification, equivalent changes and modifications made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention should be included in the scope of protection of the claims of the present invention.

Claims

1. A multi-version concurrency control method for an openGauss database in a distributed multi-write architecture, characterized in that: The method comprises: S1. When creating a tuple, the segment applies for a new transaction id from the master, generates xid, and records the following information in the tuple: xmin, which indicates the transaction that creates the tuple; xmax, which indicates the transaction that updates or deletes the tuple; data, which indicates the data to be stored in the tuple; S2. Calculate the segment_id, timestamp, and auto-increment id triple information through xid, and determine the unique storage location of the transaction status in the cluster based on the triple information; S3. The transaction snapshot is generated by the segment node. The transaction snapshot contains the following information: oldest_xid, which indicates the minimum active xid of the database cluster when the transaction snapshot was generated; timestamp, which indicates the timestamp when the transaction snapshot was generated; S4. The background thread of each segment continuously traverses all sessions, obtains all active xids, and calculates the minimum active xid of the current segment. The segment broadcasts the local minimum active xid to other nodes. After receiving the broadcast message, other nodes update the global minimum active xid to obtain the oldest_xid. S5. By querying the historical tuple update linked list generated when the tuple is updated, combined with the transaction snapshot, the xmin and xmax information in the tuple, and the transaction status information, determine whether the tuple is visible to the current transaction; S6. Perform dead tuple cleaning and tuple freezing. When a tuple is not visible to all active transactions in the database, it is defined as a dead tuple. Dead tuples are cleaned up regularly to release hard disk space. Perform xid freezing and set the xid in the committed state to a special value, indicating that the xid is visible to all transactions. After dead tuple cleaning and tuple freezing are completed, clean up the transaction status and transaction commit time that are less than oldest_xmin to release hard disk space.

2. According to claim 1, the multi-version concurrency control method of the openGauss database under the distributed multi-write architecture is characterized in that: When deleting a tuple, the method does not directly clean up the old tuple and its data, but adopts a marked deletion, where the segment applies for a new xid from the master, and at the same time modifies the xmax in the tuple to the new xid, indicating that the tuple is deleted by the new xid transaction.

3. According to claim 1, the multi-version concurrent control method of the openGauss database under the distributed multi-write architecture is characterized in that: When the method updates a tuple, the database does not immediately delete the old tuple data, but modifies xmax to a new xid in the old tuple, then creates a new tuple with the new xid, and generates a historical tuple update linked list.

4. According to claim 1, the multi-version concurrency control method of the openGauss database under the distributed multi-write architecture is characterized in that: The xid in step S1 is a 64-bit integer, where: (1) The first 8 bits are segment_id. Each segment has a unique identifier in the cluster. segment_id indicates which segment the xid is assigned to. (2) The middle 32 bits are the timestamp, in seconds; (3) The last 24 bits are a monotonically increasing auto-increment ID. When the timestamp changes, the auto-increment ID is reset to 0.

5. According to claim 1, the multi-version concurrency control method of the openGauss database under the distributed multi-write architecture is characterized in that: The transaction status described in step S2 includes: not_start, in_progress, committed, aborted; When the transaction status changes, the segment records the transaction and its status on the storage according to the following rules: (1) When a segment requests a new xid from the master, the segment records the xid status as in_progress on its corresponding storage; (2) When the client's SQL is executed and the transaction is committed, the segment updates the xid status to committed; (3) When an error occurs during SQL execution or the client displays a rollback transaction, the segment updates the xid status to aborted.

6. According to claim 1, the multi-version concurrency control method of the openGauss database under the distributed multi-write architecture is characterized in that: The method also includes: (1) When updating the xid status, first update the transaction status of the local segment, and then broadcast the transaction status to other nodes. After receiving the broadcast message, other nodes update the xid status in the local segment; (2) When querying the xid status, first query the xid status in the current segment. If it is already cached locally, there is no need to perform a remote query. If it is not cached locally, query the segment to which the xid belongs through a network request, and cache the query results locally. The cached results will be used directly the next time the query is made.

7. The multi-version concurrent control method of the openGauss database in a distributed multi-write architecture according to claim 1, characterized in that: The visibility judgment rule for judging whether the tuple is visible to the current transaction in step S5 is as follows: (1) If xid is less than oldest_xid, its status must be committed or aborted; (2) If the transaction status is not committed, it means that the transaction has not been committed or has been rolled back, and the xid is not visible; (3) If the transaction commit time is greater than the transaction snapshot application time, it means that the transaction has not been committed when the snapshot is applied, and the xid is not visible; (4) Except for the cases in rules (2) and (3), in other cases, xid is visible; the visibility of the tuple is obtained based on the visibility of xid corresponding to xmin and xmax in the tuple; (5) The xmin in the historical tuple is not visible, which means that the transaction that created the tuple was not committed or rolled back, and the tuple is not visible; (6) If xmax in the historical tuple is visible, it means that the transaction that deleted or updated the tuple has been committed, and the tuple is not visible; (7) Except for the cases in rules (5) and (6), all other tuples are visible.

8. The multi-version concurrent control method of the openGauss database under a distributed multi-write architecture according to claim 1, characterized in that: The dead tuple cleaning and tuple freezing described in step S6, the rules of dead tuple cleaning and tuple freezing are as follows: (1) When the xmin or xmax of a tuple is greater than oldest_xmin, the tuple does not need to be cleaned up or frozen; (2) If the xmin of the tuple is less than oldest_xmin and the transaction status is not committed, the tuple is a dead tuple and is deleted. (3) The xmax of the tuple is less than oldest_xmin, and the transaction status is committed, indicating that the tuple is a dead tuple and is deleted; (4) Freeze the remaining tuples. When freezing, xmin is set to a special value and xmax is set to 0, indicating that the tuple is visible to any transaction.

9. A multi-version concurrent control system of an openGauss database under a distributed multi-write architecture, characterized in that: When the system is running, the steps of the multi-version concurrent control method of the openGauss database under a distributed multi-write architecture described in any one of claims 1 to 8 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, wherein when the program is executed by a processor, the steps of the multi-version concurrency control method of the openGauss database under a distributed multi-write architecture as described in any one of claims 1 to 8 are implemented.

Images