A multi-version concurrency control method for openGauss database in a distributed multi-write architecture

Abstract

The present invention relates to a multi-version concurrency control method for an openGauss database under a distributed multi-write architecture. The method comprises: generating an xid when creating a tuple, and recording xmin and xmax information in the tuple; calculating the segment_id, timestamp, and auto-increment id triple information through the xid, and determining the unique storage location of the transaction status in the cluster; generating a transaction snapshot, which contains oldest_xid and timestamp information; obtaining the global oldest_xid; updating a linked list by querying historical tuples, and combining the transaction snapshot, the xmin and xmax information in the tuple, and the transaction status information to determine whether the tuple is visible to the current transaction; and regularly performing dead tuple cleanup and tuple freezing. The method solves the problem that the existing MVCC technology is not applicable to 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.

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, single-node databases can easily reach system bottlenecks.

[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 achieving data isolation and consistency in databases. openGuass is a single-node database, and existing MVCC technology is not suitable for a distributed multi-write architecture. Expanding to a distributed multi-write architecture requires adjustments and improvements to MVCC technology. 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 distributed multi-write architectures, 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 globally unique transaction IDs.

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

[0009] Data node: Also known as a segment. Horizontally scale a database cluster by adding segments. Segments are connected to each other via an interconnect. Each client can 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 includes the following steps:

[0012] S1. When creating a tuple, the segment requests a new transaction id from the master, generates an xid, and records the following information in the tuple: xmin, which indicates the transaction that created the tuple; xmax, which indicates the transaction that updated or deleted the tuple; and data, which indicates the data to be stored in the tuple.

[0013] S2. Calculate the segment_id, timestamp, and auto-increment id triple from the xid. Use this triple to determine the unique storage location for the transaction status in the cluster.

[0014] S3. The segment node generates a transaction snapshot, which 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. Each segment's background thread 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. Determine whether the tuple is visible to the current transaction by querying the historical tuple update list generated when the tuple is updated, combining the transaction snapshot, the xmin and xmax information in the tuple, and the transaction status information.

[0017] S6. Perform dead tuple cleanup and tuple freezing. When a tuple is not visible to all active transactions in the database, it is defined as a dead tuple and is cleaned up regularly to free up 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 the dead tuple cleanup and tuple freezing are completed, clean up the transaction status and transaction commit time that are less than oldest_xmin to free up 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 marked deletion. 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 performs a tuple update, 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 performs the update operation on 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 timestamps 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 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 further comprises:

[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 there is a local cache, there is no need to perform a remote query. If there is no local cache, 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 in the next query.

[0032] Furthermore, the visibility judgment rule for determining 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 of rules (2) and (3), the xid is visible in other cases; the visibility of the tuple is obtained based on the visibility of the xid corresponding to xmin and xmax in the tuple;

[0037] (5) If xmin in the history tuple is not visible, it means that the transaction that created the tuple has not been committed or rolled back, and the tuple is not visible;

[0038] (6) If xmax in the history 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 of 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 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, it means that the tuple is a dead tuple and is deleted;

[0043] (3) If the tuple's xmax is less than oldest_xmin and the transaction status is committed, 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 concurrency control system of an openGauss database under a distributed multi-write architecture. When this system is running, the steps of the multi-version concurrency 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, which stores a computer program. When the program is executed by a processor, it implements the steps of the multi-version concurrency control method of the above-mentioned openGauss database under the distributed multi-write architecture.

[0047] In summary, the multi-version concurrency control method of the openGauss database under a distributed multi-write architecture of the present invention solves the problem that the existing MVCC technology is not applicable under 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 is a brief introduction to 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 This 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 This is an example diagram of tuple deletion according to an embodiment of the present invention.

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

[0053] Figure 5 Schematic diagram of the XID composition structure according to an embodiment of the present invention.

[0054] Figure 6 FIG. 1 is a schematic diagram of an update chain of history tuples according to an embodiment of the present invention.

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

[0056] Figure 8 4 is an implementation flow chart of the method of the present invention. DETAILED DESCRIPTION

[0057] To make the objectives, technical solutions, and advantages of the present invention more clearly apparent, the technical solutions 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 some, not all, of the embodiments of the present invention. The present invention may also be implemented or applied through different specific implementation methods, and the details in this specification may 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 scope of protection 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 scope of protection of the present invention.

[0059] Example: A multi-version concurrency control method for the openGauss database in a distributed multi-write architecture

[0060] (1) 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 creation transaction of 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] (2) Tuple deletion

[0066] like Figure 3As shown, when deleting a tuple, 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] (3) Tuple Update

[0068] like Figure 4 As shown in the figure, a tuple is created by transaction xid1, and then updated by transaction xid3. At this point, the database does not immediately delete the old tuple data. Instead, it marks xmax with xid3 in the old tuple and creates a new tuple with xid3. Tuple updates can be understood as first deleting the tuple and then creating a new tuple, forming a linked list of historical tuple updates.

[0069] (4) Status of the transaction

[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 transaction, the segment updates the xid status to aborted.

[0074] (5) Tuple query

[0075] When querying a tuple, a transaction snapshot is requested from the segment. The segment traverses the history 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 explained in detail later.

[0077] The following describes the implementation process of this method by way of example:

[0078] (1) 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, and the cluster can be expanded to a maximum of 256 segments.

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

[0082] (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. 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 less than 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 applied for the xid. This will not be repeated later when comparing xid sizes).

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

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

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

[0087] For example:

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

[0089] Timestamp = 1722674053, then the transaction status is stored in the 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 third and fourth bits (calculated based on the fact that 1 byte can store four 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 another node, a network request must be sent to the segment to which the xid belongs for query. To reduce the overhead of network requests, we adopt the following strategy to avoid network requests for every query and improve query efficiency:

[0092] (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.

[0093] (2) When querying the xid status, first query the xid status in the current segment. If there is a local cache, there is no need to perform a remote query. If there is no local cache, 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 in the next query.

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

[0095] (3) Transaction snapshot

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

[0097] oldest_xid: The smallest xid in the database cluster that was still active when the snapshot was 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 using the above method will be smaller than the actual oldest_xid of the database. Therefore, transactions with a value smaller than the oldest_xid must be in the committed or aborted state.

[0101] (4) 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 cleared, but marked for deletion; when a tuple is updated, an update list of historical tuples will be generated. The update list of historical tuples is as follows: 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, indicating that the transaction has not been committed when the snapshot is applied, and the xid is not visible.

[0107] 4. If either of rules 2 or 3 is true, the xid is invisible. Otherwise, the xid is visible. Then, the visibility of the tuple can be determined based on the visibility of the xid corresponding to xmin and xmax in the tuple.

[0108] 5. The xmin in the history 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 met, the tuple is not visible; otherwise, the tuple is visible.

[0111] (5) Dead tuple cleaning 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 no longer visible 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 continuously appends transaction status and transaction commit time, which will occupy a large amount of disk space. The database freezes the xid by setting the xid of 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, then the tuple does not need to be cleaned up or frozen.

[0116] (2) If the xmin of a tuple is less than oldest_xmin and the transaction status is not committed, it means 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 regularly cleans up dead tuples and freezes them for all tuples. After this process is complete, transactions with states and commit times less than oldest_xmin are no longer needed and can be safely cleaned up, freeing up disk space. Dead tuple cleaning and freezing are performed independently on 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 content disclosed above without departing from the scope of the technical solution of the present invention to obtain equivalent embodiments with equivalent changes. However, any simple modifications, 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 requests a new transaction id from the master, generates an xid, and records the following information in the tuple: xmin, which indicates the transaction that created the tuple; xmax, which indicates the transaction that updated or deleted the tuple; and data, which indicates the data to be stored in the tuple. S2. Calculate the segment_id, timestamp, and auto-increment id triple from the xid. Use this triple to determine the unique storage location for the transaction status in the cluster. S3. The segment node generates a transaction snapshot, which 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. Each segment's background thread 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. Determine whether the tuple is visible to the current transaction by querying the historical tuple update list generated when the tuple is updated, combining the transaction snapshot, the xmin and xmax information in the tuple, and the transaction status information. S6. Clean up dead tuples and freeze tuples. 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 free up hard disk space. XIDs are frozen to set the xids in the committed state to a special value, indicating that the xid is visible to all transactions. After the dead tuple cleanup and tuple freezing are completed, the transaction states and transaction commit times that are less than oldest_xmin are cleaned up to free up hard disk space.

2. The multi-version concurrency control method of the openGauss database under a distributed multi-write architecture according to claim 1 is characterized in that: When deleting a tuple, the method does not directly clean up the old tuple and its data, but adopts marked deletion. 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. The multi-version concurrency control method of the openGauss database under a distributed multi-write architecture according to claim 1 is characterized in that: When the method 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, then creates a new tuple with the new xid and generates a historical tuple update linked list.

4. The multi-version concurrency control method of the openGauss database under a distributed multi-write architecture according to claim 1 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 timestamps in seconds; (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.

5. The multi-version concurrency control method of the openGauss database under a distributed multi-write architecture according to claim 1 is characterized in that: The transaction status 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. The multi-version concurrency control method of the openGauss database under a distributed multi-write architecture according to claim 1 is characterized in that: The method further comprises: (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 there is a local cache, there is no need to perform a remote query. If there is no local cache, 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 in the next query.

7. The multi-version concurrency control method of the openGauss database under a distributed multi-write architecture according to claim 1 is characterized in that: In step S5, the visibility judgment rules for determining whether the tuple is visible to the current transaction are 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 of rules (2) and (3), the xid is visible in other cases; the visibility of the tuple is obtained based on the visibility of the xid corresponding to xmin and xmax in the tuple; (5) If xmin in the history tuple is not visible, it means that the transaction that created the tuple has not been committed or rolled back, and the tuple is not visible; (6) If xmax in the history 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 of rules (5) and (6), all other tuples are visible.

8. The multi-version concurrency control method of the openGauss database in a distributed multi-write architecture according to claim 1 is characterized in that: The dead tuple cleaning and tuple freezing described in step S6 are carried out according to the following rules: (1) When the xmin or xmax of a tuple is greater than oldest_xmin, the tuple does not need to be cleaned or frozen; (2) If the xmin of the tuple is less than oldest_xmin and the transaction status is not committed, it means that the tuple is a dead tuple and is deleted; (3) If the tuple's xmax is less than oldest_xmin and the transaction status is committed, 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 the openGauss database under a distributed multi-write architecture, characterized in that: The system is run to implement 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.

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

Images