Global vector CSN transaction snapshot generation device of shared storage multi-Master cluster database system

Abstract

The invention relates to a global vector CSN transaction snapshot generation device and method of a shared storage multi-Master cluster database system. The device comprises a multi-Master CSN generation module which is used for generating a multi-Master cluster mode CSN serial number with a node identifier when a transaction is submitted and binding a transaction number to a CSN LOG; the CSN BOC sending module asynchronously broadcasts the packaged transaction number and CSN serial number message packet to other nodes of the cluster; the CSN BOC receiving module is used for receiving the message packet, recording the message packet to a local CSN LOG and maintaining a global CSN vector (storing the latest CSN of each node according to the node number); and the vector CSN snapshot generation module generates a snapshot by copying a global CSN vector and updating the CSN of the node, and is used for data line snapshot isolation visibility check. According to the method, the limitation of a traditional CSN single node is broken through, the problem of unified description of a multi-Master cluster cross-node transaction sequence is solved, synchronous network IO loss is avoided through asynchronous message and memory operation, and cluster transaction visibility check efficiency and service concurrency performance are remarkably improved.

Description

Technical Field

[0001] This application belongs to the field of database operation technology, and specifically relates to a global vector CSN transaction snapshot generation device and method for a shared storage multi-master cluster database system. Background Technology

[0002] In the openGauss database, CSN (Commit Sequence Number) is a technical mechanism used for managing the transaction commit order and is one of the core technologies for achieving transaction visibility, consistency, and parallel control. As a globally unique, incrementing sequence number, CSN identifies the commit order of transactions. Each transaction is assigned a CSN upon commit; the smaller the CSN value, the earlier the transaction was committed. In the openGauss database, the CSN LOG records the CSN sequence number corresponding to each committed transaction Xid. This mechanism supports commit status checks and snapshot isolation checks for internal database tables.

[0003] Snapshot Isolation (SI) is a mainstream Multi-Version Concurrency Control (MVCC) implementation technology that allows transactions to access a consistent snapshot of the database during execution, avoiding read / write blocking issues caused by traditional locking mechanisms. In the openGauss database, background business processing threads use the latest CSN (Transaction Sequence Number) as the baseline CSN for snapshot isolation. During visibility checks, if the transaction CSN of the target data row is greater than or equal to the snapshot CSN, the data row is determined to be invisible to the current transaction.

[0004] However, the existing CSN technology in the openGauss database is only applicable to single-machine database systems or master-slave database systems, and cannot be directly applied to shared storage multi-write multi-read cluster database systems (hereinafter referred to as multi-master clusters). A typical example of a multi-master cluster in the industry is the Oracle RAC cluster database system, whose architecture allows each node to independently start transactions and perform data row insertion, modification, and deletion operations. However, openGauss's CSN technology can only describe the sequential state of transaction commits within a single node, and cannot uniformly describe the transaction commit order across nodes in a multi-master cluster environment. Therefore, it cannot implement snapshot isolation visibility checks for multi-master clusters based on CSN.

[0005] Therefore, developing a device and method for snapshot isolation visibility inspection of multi-Master clusters based on CSN has become an urgent need in the industry. Summary of the Invention

[0006] To address the aforementioned issues, this application proposes a novel global vector CSN transaction snapshot generation device and method for shared storage multi-master cluster database systems.

[0007] In summary, this invention aims to provide a global vector CSN transaction snapshot generation device for a shared storage multi-master cluster database system. This device addresses the problem that CSN technology in a single-machine OpenGauss database system cannot be applied to a multi-master cluster database system. It enables the multi-master cluster database system to use the global vector CSN snapshot method in this solution to describe the transaction commit status of each node globally. Furthermore, it enables the use of global vector CSN snapshots to perform visibility checks on shared data, thereby achieving global, real-time, and consistent database read / write concurrency control.

[0008] In a shared storage multi-Master cluster database system, the present invention constructs a global vector CSN on each database node through the BOC mechanism during transaction commit. Each node can construct a global vector CSN snapshot under the multi-Master cluster architecture simply by accessing the CSN sequence number and the global CSN vector in its local memory. This global vector CSN snapshot can then be used to perform a globally consistent visibility check on the shared data.

[0009] The device of this invention includes a multi-Master CSN generation module, a CSN BOC sending module (Boardcast OnCommit, transaction commit synchronization), a CSN BOC receiving module, and a vector CSN snapshot generation module. In this embodiment, both the multi-Master CSN generation module and the vector CSN snapshot generation module operate using node memory data, without needing to request global data from other nodes using synchronous network I / O. The CSN BOC sending and receiving in this embodiment uses an asynchronous network message mode instead of a synchronous network I / O mode. By constructing a CSN BOC synchronization and vector CSN mechanism under a multi-Master database architecture, this embodiment achieves visibility checks for multi-Master clusters. This allows database business threads to access only the node memory CSN-related data when performing database visibility checks using this solution, without needing to request CSN data or other data from other nodes via network I / O. This does not impose additional system burden on the database background process and ensures the concurrent operation efficiency of the visibility check process.

[0010] To achieve the above objectives, this application provides the following technical solution: A first aspect of this application provides a global vector CSN transaction snapshot generation apparatus for a shared storage multi-master cluster database system, the apparatus comprising: The multi-Master CSN generation module is used to generate CSN sequence numbers in multi-Master cluster mode when a transaction is committed. After binding the transaction number with the CSN sequence number, it is recorded in the CSN LOG. The CSN sequence number in multi-Master cluster mode generates the node number of the CSN through the high-order identifier. The CSN BOC sending module is used to encapsulate the transaction number and CSN sequence number into a message packet when a transaction is committed, and broadcast it to other nodes in the multi-Master cluster. The CSN BOC receiving module is used to receive message packets from other nodes sent by the CSN BOC sending module, record the transaction number and CSN sequence number in the message packet in the local CSN LOG, and update the global CSN vector in the local memory with the CSN sequence number in the message packet. The vector CSN snapshot generation module is used to copy the global CSN vector and update the latest CSN sequence number of the local node, generate a global vector CSN snapshot, and perform snapshot isolation visibility checks on data rows in the multi-Master cluster database based on the snapshot.

[0011] Furthermore, in the device of this application, the CSN sequence number generated by the multi-Master CSN generation module is a 64-bit unsigned integer, of which the high 4 bits are used to identify the node number that generated the CSN, supporting a maximum of 16 nodes, and the remaining low bits are a globally increasing sequence; the CSN increment of each node is only related to the local transaction commit of that node and is not affected by the transaction commit of other nodes.

[0012] Furthermore, in the device of this application, the CSN BOC sending module broadcasts message packets using an asynchronous network sending method, and transaction submission does not require waiting for confirmation from other nodes; after receiving the message packet, the CSN BOC receiving module parses the CSN sequence number in it, extracts the node number information, and atomically updates the CSN sequence number to the array slot of the corresponding node number in the global CSN vector.

[0013] Furthermore, in the device of this application, the vector CSN snapshot generation module maintains the global CSN vector through atomic variable update and performs a one-time copy operation at the beginning of a transaction to generate the global vector CSN snapshot.

[0014] Furthermore, in the device of this application, the global CSN vector is an array with a maximum length of 16 indexed by node number, each array element stores the latest CSN sequence number sent by the corresponding node, and the global CSN vector is maintained by the node's local memory.

[0015] Furthermore, in the device of this application, the global CSN vector is initialized as an array of all zeros; when the CSN BOC receiving module receives a new CSN ​​sequence number, it parses the node number of its high 4 bits and updates the CSN sequence number to the array slot corresponding to the node number in the global CSN vector, so as to record the latest transaction commit status of each node.

[0016] A second aspect of this application provides a method for generating global vector CSN transaction snapshots in a shared storage multi-master cluster database system, characterized in that the method includes: S1: When a transaction is committed, the multi-Master CSN generation module of this node generates a multi-Master cluster mode CSN sequence number with node identifier (this CSN sequence number is a monotonically increasing sequence number), and records the transaction number and CSN sequence number in the local CSNLOG after binding them. S2: The CSN BOC sending module encapsulates the transaction number and CSN sequence number into a message packet and asynchronously broadcasts it to other nodes in the multi-Master cluster; S3: After receiving a message packet from another node, the CSN BOC receiving module records the transaction number and CSN sequence number in the local CSN LOG, and updates the array slot of the corresponding node number in the global CSN vector to the CSN sequence number. S4: The vector CSN snapshot generation module copies the current global CSN vector, updates the latest CSN sequence number of this node to the slot corresponding to this node number in the copied array, and generates a global vector CSN snapshot.

[0017] Furthermore, the method of this application also includes: S5: When it is necessary to check the snapshot isolation visibility of a data row, obtain the transaction number Xid corresponding to the data row, and query the local CSN LOG through Xid to obtain its CSN sequence number; parse the high 4 bits of the CSN sequence number to obtain the node number Node_id, and compare the CSN sequence number with the value of the array element corresponding to Node_id in the global vector CSN snapshot: if the CSN sequence number is less than the value, it is determined that the modified content of Xid is visible to this transaction; otherwise, the modified content of Xid is not visible to this transaction.

[0018] Furthermore, in the method of this application, the comparison logic used in step S5 is as follows: if the node number Node_id corresponding to the high 4 bits of the CSN sequence number is consistent with the array index of the global vector CSN snapshot, and the low part of the CSN sequence number (bits 1-58) is less than the low part of the array element corresponding to Node_id in the global vector CSN snapshot, then it is determined that the modified content of Xid is visible to this transaction; otherwise, the modified content of Xid is not visible to this transaction.

[0019] Furthermore, in the method of this application, the CSN sequence number in the multi-Master cluster mode described in step S1 is 64 bits, of which the high 4 bits (bits 59-62) are used to identify the node number that generated the CSN, and the remaining low bits (bits 1-58) are a globally increasing sequence; when the CSN sequence number is 0 or 1, it indicates that the transaction has not been committed or has been rolled back, and when the CSN sequence number is greater than or equal to 2, it indicates that the transaction has been committed.

[0020] Furthermore, in the method of this application, the asynchronous broadcast transmission in step S2 does not wait for confirmation from other nodes; The update of the global CSN vector in step S3 uses atomic variable update operations to ensure data consistency when multiple threads receive messages concurrently.

[0021] A third aspect of this application provides an electronic device, including: a memory and a processor; Memory: Used to store computer programs; Processor: Used to execute the computer program to implement the steps of the aforementioned global vector CSN transaction snapshot generation method for a shared storage multi-master cluster database system.

[0022] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, it implements the steps of the aforementioned global vector CSN transaction snapshot generation method for a shared storage multi-master cluster database system.

[0023] In summary, this invention addresses the cross-node transaction management requirements of shared storage multi-Master cluster database systems by proposing a transaction snapshot generation scheme based on a global vector CSN. This scheme achieves unified identification of multi-node CSNs by extending the CSN format (the high 4 bits identify the node number), maintains a global CSN vector (recording the latest CSN of each node) using an asynchronous BOC message broadcast mechanism, and generates a global vector CSN snapshot based on local memory copying. This scheme overcomes the limitation of traditional CSNs being applicable only to single nodes, solves the problem of inconsistent description of cross-node transaction commit order in multi-Master clusters, and avoids the performance overhead of synchronous network I / O through asynchronous messages and memory operations. It also achieves efficient transaction visibility checks (requiring only local memory data access), significantly improving the concurrent operation efficiency and transaction processing performance of database services in multi-Master cluster architectures.

[0024] Other features and advantages of the present invention will be set forth in detail in the following description, or may be learned by practicing the relevant technical solutions of this application. The objectives and other advantages of this application can be achieved by the technical features and means clearly pointed out in the description, claims and drawings, and obtained through the implementation of these technical contents. Attached Figure Description

[0025] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings involved in the description of the embodiments will be briefly introduced below. It should be noted that the accompanying drawings only show some embodiments of this application. For those skilled in the art, other related drawings can be derived from these drawings without creative effort.

[0026] Figure 1 This is a structural diagram of the global vector CSN transaction snapshot generation device for the shared storage multi-master cluster database system of this application.

[0027] Figure 2 The flowchart illustrates the processing of the CSN BOC receiving module provided in this embodiment of the invention.

[0028] Figure 3 This is a flowchart illustrating the process of determining the visibility of a global CSN vector snapshot provided in an embodiment of the present invention.

[0029] Figure 4 This is a flowchart illustrating the overall implementation of the global vector CSN transaction snapshot generation method for the shared storage multi-master cluster database system described in this application.

[0030] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0031] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be noted that the described embodiments are only some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the protection scope of this application.

[0032] In this document, the term "comprising" and any variations thereof (such as "including," "including," etc.) are open-ended expressions and should be understood as "including but not limited to," meaning that the listed content is not exhaustive and may include other content not explicitly mentioned. The term "based on" should be understood as "at least partially based on," meaning that the basis or condition referred to may not be the only factor and may involve other relevant factors. The term "one embodiment" should be understood as "at least one embodiment," meaning that the described embodiment is not the only possible implementation, and other similar embodiments may exist.

[0033] In this application, the terms "a" and "a plurality of" are used to modify related elements or features, and their expression is illustrative rather than restrictive. Unless otherwise expressly stated in the context, "a" should be understood as "at least one," and "a plurality of" should be understood as "at least two." Those skilled in the art should reasonably interpret these terms based on the semantic and logical relationships of the context to ensure that they cover the possibility of "one or more."

[0034] Figure 1 The image shows a global vector CSN transaction snapshot generation device for a shared storage multi-master cluster database system proposed in this application. The device includes: The multi-Master CSN generation module is used to generate CSN sequence numbers in multi-Master cluster mode when a transaction is committed. After binding the transaction number with the CSN sequence number, it is recorded in the CSN LOG. The CSN sequence number in multi-Master cluster mode generates the node number of the CSN through the high-order identifier. The CSN BOC sending module is used to encapsulate the transaction number and CSN sequence number into a message packet when a transaction is committed, and broadcast it to other nodes in the multi-Master cluster. The CSN BOC receiving module is used to receive message packets from other nodes sent by the CSN BOC sending module, record the transaction number and CSN sequence number in the message packet in the local CSN LOG, and update the global CSN vector in the local memory with the CSN sequence number in the message packet. The vector CSN snapshot generation module is used to copy the global CSN vector and update the latest CSN sequence number of the local node, generate a global vector CSN snapshot, and perform snapshot isolation visibility checks on data rows in the multi-Master cluster database based on the snapshot.

[0035] To more clearly illustrate the technical solution of this application, the following will provide further explanation through specific scenario embodiments.

[0036] This embodiment provides a method and apparatus for generating global vector CSN transaction snapshots in a shared storage multi-master cluster database system. The apparatus includes: Multi-Master CSN generation module, CSN BOC sending module, CSN BOC receiving module, and vector CSN snapshot generation module.

[0037] The multi-Master CSN generation module is used to generate CSN sequence numbers in multi-Master cluster mode when a transaction is committed, and bind the transaction number with the CSN sequence number and record it in the CSN LOG.

[0038] In this embodiment, the main differences between the CSN sequence number in the multi-Master cluster mode and the CSN sequence number in the openGauss database system are as follows: In the multi-Master cluster mode, the CSN sequence number uses the high 4 bits of the 64-bit CSN to identify the node number (note: a maximum of 16 nodes are supported). Each node must mark the RAC node number at this position when generating the CSN upon commit. More specifically, in the definition of the high bits of the CSN, bits 63 and 64 are already occupied; this embodiment uses bits 59-62 of the CSN to record the RAC node number that generated the CSN. The increment of each node's CSN is only related to the commit of the transaction of that node; the commit of transactions of other nodes has no effect on the CSN of that node.

[0039] When a transaction is committed, the transaction thread atomically retrieves the incrementing CSN sequence number from the local node's memory, marks the node number with bits 59-62 of the CSN, records the Xid-CSN in the local node's CSN LOG, and then transmits the Xid-CSN information to the CSN BOC sending module. In this embodiment, the generation and recording of CSNs, except that the CSN recorded in the CSN LOG needs to be marked with the RAC node number in bits 59-62, are maintained and used in the same way as the openGauss database system.

[0040] The CSN BOC sending module is used to update the Xid-CSN to the CSN LOG of the local node when a transaction is committed, encapsulate the transaction number and CSN sequence number related to the transaction commit into a message packet, and broadcast the message packet to other nodes in the multi-Master cluster.

[0041] In this embodiment, the CSN BOC sending module uses asynchronous network sending, and the transaction submission does not require waiting for other nodes in the multi-Master cluster to receive the BOC message.

[0042] The CSN BOC receiving module is used to receive BOC message packets sent by the CSN BOC sending module, record the transaction number and CSN recorded in the message packet into the local CSN LOG, and maintain the global CSN vector.

[0043] In this embodiment, the global CSN vector is an array with a maximum length of 16, where each element represents the latest CSN sequence number sent by a database node. The CSN BOC receiving module updates the global CSN vector after receiving the BOC message by parsing the 59th-62nd bits of the CSN sequence number (Node_id) and then updating the CSN sequence number to the array slot in the global CSN vector with the Node_id index.

[0044] The vector CSN snapshot generation module is used to generate a global CSN vector snapshot and use the global CSN vector snapshot to perform snapshot isolation visibility checks on data rows in the multi-Master cluster database.

[0045] In this embodiment, the method by which the vector CSN snapshot generation module generates a global snapshot is as follows: copy the global CSN vector array, update the latest CSN sequence number of the current node to the slot of the copied array with the index of the current node number, and use the copied array as a global vector CSN snapshot.

[0046] When checking the snapshot isolation visibility of a data row, first obtain the transaction number Xid of the data row being operated on, then obtain the corresponding CSN' sequence number through Xid, parse the high 4 bits of the CSN' sequence number Node_id, and then compare the size relationship between the global vector CSN snapshot array [Node_id] and CSN': if CSN' < global vector CSN snapshot [Node_id], then it is determined that the content modified by Xid has passed the snapshot isolation check of this transaction, and the content modified by Xid is visible to this transaction; otherwise, the content modified by Xid is not visible to this transaction.

[0047] In this embodiment, both the multi-Master CSN generation module and the vector CSN snapshot generation module operate using node memory data, without needing to request global data from other nodes using synchronous network I / O. While using synchronous network I / O to request global data from other nodes strictly ensures the commit order, it also lengthens the execution time of each database transaction, impacting the efficiency of database operations. In this embodiment, CSN BOC sending and receiving use an asynchronous network message mode instead of a synchronous network I / O mode. This embodiment, by constructing a multi-Master CSN mechanism and pairing it with a CSN BOC sending module, a CSN BOC receiving module, and a global vector CSN snapshot generation module, implements a visibility check mechanism for the multi-Master cluster. This allows database business threads to access node memory data only when performing database visibility checks using this solution, without needing to request data information from other nodes via network I / O. This does not impose additional system burden on the database background process, effectively ensuring the concurrent operation efficiency of visibility checks using CSN in a multi-Master cluster architecture.

[0048] The following details the method for maintaining the global CSN vector. Figure 2 This is a flowchart of the CSN BOC receiving module provided in this embodiment.

[0049] Specifically, Figure 201 shows that the CSN BOC receiving module receives a BOC message, which is generated by a transaction commit and broadcast from a node in a multi-Master cluster.

[0050] In Figure 202, the CSN BOC receiving module extracts the transaction number Xid and the corresponding CSN sequence number from the BOC message packet, and updates the Xid-CSN to the CSN LOG of this node.

[0051] In Figure 203, the CSN BOC receiving module parses bits 59-62 of the CSN sequence number to obtain the node number Node_id that generated the CSN sequence number.

[0052] In Figure 204, the CSN BOC receiving module updates the received CSN sequence number into the global vector CSN array, with the array index being Node_id. The update method is atomic variable update. In this embodiment, the global CSN vector is an array with a maximum length of 16, and each element in the array represents the latest CSN sequence number sent by a database node. The method by which the CSN BOC receiving module updates the global CSN vector after receiving the BOC message is as follows: parse the 59th to 62nd bits of the CSN sequence number (Node_id), and update the CSN sequence number into the array slot of the global CSN vector with the index Node_id.

[0053] exist Figure 2 In the processing flow of the CSN BOC receiving module shown, the CSN BOC receiving module maintains a global CSN vector, the dimension of which is the maximum number of nodes. The global CSN vector indicates the transaction completion status of all nodes globally that the current node can know. During the execution of the database business SQL, the global CSN vector is copied first at the beginning of SQL statement execution, serving as a snapshot of the global CSN vector at the start of the SQL statement. The database business will use this global CSN vector snapshot as a visibility check method in the multi-Master cluster.

[0054] To more clearly illustrate how global CSN vector snapshots are used in the data visibility inspection process, Figure 3 This embodiment demonstrates the process flow for visibility determination using a global CSN vector snapshot.

[0055] Specifically, Figure 301 shows that the database business scan hit a data row, and the database business needs to check whether the operation of the Xid transaction is visible to this transaction.

[0056] In Figure 302, the database business thread queries the CSN LOG to obtain the CSN sequence number corresponding to the Xid.

[0057] In Figure 303, the database business thread determines whether the Xid transaction has been committed based on the CSN sequence number. Specifically, the first 58 bits of the CSN sequence number are temporarily denoted as CSN'. If CSN' is equal to 0 or equal to 1, it means that the Xid transaction has not yet ended and has been rolled back, respectively. The Xid transaction operation content is not visible to the basic transaction, as shown in Figure 304. If CSN' is greater than 2, it means that the Xid transaction has been committed. At this time, further snapshot isolation checks are required, as shown in Figure 305.

[0058] In Figure 305, the database business thread parses bits 59-62 of the CSN sequence number to obtain the Node_id that generated the transaction commit. It then compares the CSN sequence number with the global vector CSN snapshot [Node_id]. In Figure 306, if the CSN sequence number < the global vector CSN snapshot [Node_id], it indicates that the Xid transaction committed earlier than the start of the SQL query in this transaction, and the process proceeds to Figure 307; if the CSN is greater than or equal to the global vector CSN snapshot [Node_id], it indicates that the Xid transaction committed later than the start of the SQL query in this transaction, and the process proceeds to Figure 308.

[0059] In Figure 307, the Xid transaction has been committed and passed the global vector CSN snapshot check of this transaction. In this case, the result of the Xid transaction operation is visible to this transaction.

[0060] In Figure 308, although the Xid transaction has been committed, it failed the global vector CSN snapshot check of this transaction, indicating that the Xid transaction was committed after the SQL statement query of this transaction started execution. In this case, the operation result of the Xid transaction is not visible to this transaction.

[0061] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the embodiments of the present invention, and are not intended to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the present invention.

[0062] Figure 4 The diagram illustrates the overall implementation flow of the global vector CSN transaction snapshot generation method for a shared storage multi-master cluster database system provided in this application, including the following steps: S1: When a transaction is committed, the multi-Master CSN generation module of this node generates a multi-Master cluster mode CSN sequence number with node identifier (this CSN sequence number is a monotonically increasing sequence number), and records the transaction number and CSN sequence number in the local CSNLOG after binding them. S2: The CSN BOC sending module encapsulates the transaction number and CSN sequence number into a message packet and asynchronously broadcasts it to other nodes in the multi-Master cluster; S3: After receiving a message packet from another node, the CSN BOC receiving module records the transaction number and CSN sequence number in the local CSN LOG, and updates the array slot of the corresponding node number in the global CSN vector to the CSN sequence number. S4: The vector CSN snapshot generation module copies the current global CSN vector, updates the latest CSN sequence number of this node to the slot corresponding to the node number in the copied array, and generates a global vector CSN snapshot. S5: When it is necessary to check the snapshot isolation visibility of a data row, obtain the transaction number Xid corresponding to the data row, and query the local CSN LOG through Xid to obtain its CSN sequence number; parse the high 4 bits of the CSN sequence number to obtain the node number Node_id, and compare the CSN sequence number with the value of the array element corresponding to Node_id in the global vector CSN snapshot: if the CSN sequence number is less than the value, it is determined that the modified content of Xid is visible to this transaction; otherwise, the modified content of Xid is not visible to this transaction.

[0063] The flowcharts and block diagrams in the accompanying drawings illustrate possible implementations of apparatus, methods, and computer program products according to various embodiments of this application, including architecture, functionality, and operation. In these figures, each block may represent a module, program segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should be noted that each block in the block diagrams and / or flowcharts, and combinations thereof, can be implemented using either a dedicated hardware-based system or a combination of dedicated hardware and computer instructions to achieve the specified function or operation.

[0064] like Figure 5 As shown, embodiments of this application also disclose an electronic device, including: a processor 310, a communication interface 320, a memory 330 for storing a processor-executable computer program, and a communication bus 340. The processor 310, communication interface 320, and memory 330 communicate with each other via the communication bus 340. The processor 310 executes the executable computer program to implement the steps of the aforementioned global vector CSN transaction snapshot generation method for a shared storage multi-master cluster database system.

[0065] It is understood that, in addition to memory and a processor, this electronic device may also include input devices (such as a keyboard), output devices (such as a display), and other communication modules. These input devices, output devices, and other communication modules all communicate with the processor through I / O interfaces (i.e., input / output interfaces).

[0066] The operations described in this application can be implemented by writing computer program code using one or more programming languages ​​or a combination thereof. The programming languages ​​include, but are not limited to, the following types: Object-oriented programming languages, such as Java, Smalltalk, C++, etc. Conventional procedural programming languages, such as "C" or similar programming languages.

[0067] The execution methods of program code include, but are not limited to: It runs entirely on the user's computer; Part of it executes on the user's computer, and part of it executes on a remote computer; Execute as a standalone software package; It is executed entirely on a remote computer or server.

[0068] In scenarios involving remote computers, the remote computer can connect to the user's computer via any type of network, including but not limited to local area networks (LANs) or wide area networks (WANs). Furthermore, the remote computer can also connect to external computers through an internet service provider, for example, by utilizing the internet for connection.

[0069] Furthermore, this application also discloses a computer-readable storage medium, wherein when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is able to perform the various steps of the global vector CSN transaction snapshot generation method for a shared storage multi-master cluster database system disclosed in this application.

[0070] In the context of this application, a computer-readable storage medium refers to a tangible medium capable of storing computer program code and related data. Specific examples include, but are not limited to, the following: (1) Portable computer disk: such as floppy disks and other removable magnetic storage media.

[0071] (2) Hard disk: including mechanical hard disks and solid-state hard disks and other fixed storage devices.

[0072] (3) Random Access Memory (RAM): A volatile storage medium used for temporary storage of data and program code.

[0073] (4) Read-only memory (ROM): a non-volatile storage medium used to store fixed programs and data.

[0074] (5) Erasable programmable read-only memory (EPROM) or flash memory: non-volatile storage media that supports multiple erasures and reprogrammings.

[0075] (6) Fiber optic storage devices: storage media based on fiber optic technology.

[0076] (7) Portable compact disc read-only memory (CD-ROM): a read-only medium that stores data in the form of an optical disc.

[0077] (8) Optical storage devices: such as DVDs, Blu-ray discs and other storage media based on optical principles.

[0078] (9) Magnetic storage devices: such as magnetic tapes, disks and other storage media based on magnetic principles.

[0079] (10) Any suitable combination of the above: for example, combining multiple storage media to meet different storage needs.

[0080] These computer-readable storage media can be used to store the program code and related data described in this application to support program execution and persistent data storage.

[0081] Specifically, according to embodiments of this application, the processes described in the flowcharts can be implemented as computer software programs. For example, embodiments of this application relate to a computer program product comprising a computer program carried on a non-transitory computer-readable medium. This computer program includes program code for executing the global vector CSN transaction snapshot generation method for a shared storage multi-master cluster database system disclosed in this application. When this computer program is executed by a processing device, it can achieve the functions defined in the embodiments of this application.

[0082] While the foregoing discussion contains several specific implementation details, these details should not be construed as limiting the scope of this application. The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this application is not limited to technical solutions formed by specific combinations of the above-described technical features. Furthermore, this application should also cover other technical solutions formed by any combination of the above-described technical features or their equivalents without departing from the foregoing disclosed concept.

[0083] Those skilled in the art should also understand that modifications can be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features, without departing from the spirit and scope of the technical solutions of the embodiments of this application. These modifications or substitutions will not cause the essence of the corresponding technical solutions to deviate from the core spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A global vector CSN transaction snapshot generation device for a shared storage multi-master cluster database system, characterized in that, The device includes: The multi-Master CSN generation module is used to generate CSN sequence numbers in multi-Master cluster mode when a transaction is committed. After binding the transaction number with the CSN sequence number, it is recorded in the CSN LOG. The CSN sequence number in multi-Master cluster mode generates the node number of the CSN through the high-order identifier. The CSN BOC sending module is used to encapsulate the transaction number and CSN sequence number into a message packet when a transaction is committed, and broadcast it to other nodes in the multi-Master cluster. The CSN BOC receiving module is used to receive message packets from other nodes sent by the CSN BOC sending module, record the transaction number and CSN sequence number in the message packet in the local CSN LOG, and update the global CSN vector in the local memory with the CSN sequence number in the message packet. The vector CSN snapshot generation module is used to copy the global CSN vector and update the latest CSN sequence number of the local node, generate a global vector CSN snapshot, and perform snapshot isolation visibility checks on data rows in the multi-Master cluster database based on the snapshot.

2. The apparatus according to claim 1, characterized in that, The CSN generated by the multi-Master CSN generation module is a 64-bit unsigned integer, where the high 4 bits are used to identify the node number that generated the CSN, supporting a maximum of 16 nodes, and the remaining low bits are a globally increasing sequence; the CSN increment of each node is only related to the local transaction commit of that node and is not affected by the transaction commits of other nodes.

3. The apparatus according to claim 1, characterized in that, The CSN BOC sending module broadcasts message packets using an asynchronous network sending method, and transaction commits do not require waiting for confirmation from other nodes; After receiving the message packet, the CSN BOC receiving module parses the CSN sequence number, extracts the node number information, and atomically updates the CSN sequence number to the array slot of the corresponding node number in the global CSN vector.

4. The apparatus according to claim 1, characterized in that, The vector CSN snapshot generation module maintains the global CSN vector through atomic variable updates and performs a one-time copy operation at the start of a transaction to generate the global vector CSN snapshot.

5. The apparatus according to claim 1, characterized in that, The global CSN vector is an array with a maximum length of 16 indexed by node number. Each array element stores the latest CSN sequence number sent by the corresponding node, and the global CSN vector is maintained by the node's local memory. The global CSN vector is initialized as an array of all zeros; When the CSN BOC receiving module receives a new CSN ​​sequence number, it parses the node number of its high 4 bits and updates the CSN sequence number to the array slot corresponding to that node number in the global CSN vector to record the latest transaction commit status of each node.

6. A method for generating global vector CSN transaction snapshots in a shared storage multi-master cluster database system, characterized in that, The method includes: S1: When a transaction is committed, the multi-Master CSN generation module of this node generates a multi-Master cluster mode CSN sequence number with node identifier, binds the transaction number with the CSN sequence number and records it in the local CSN LOG; S2: The CSN BOC sending module encapsulates the transaction number and CSN sequence number into a message packet and asynchronously broadcasts it to other nodes in the multi-Master cluster; S3: After receiving a message packet from another node, the CSN BOC receiving module records the transaction number and CSN sequence number in the local CSN LOG, and updates the array slot of the corresponding node number in the global CSN vector to the CSN sequence number. S4: The vector CSN snapshot generation module copies the current global CSN vector, updates the latest CSN sequence number of this node to the slot corresponding to this node number in the copied array, and generates a global vector CSN snapshot.

7. The method according to claim 6, characterized in that, The method also includes: S5: When it is necessary to check the snapshot isolation visibility of a data row, obtain the transaction number Xid corresponding to the data row, and query the local CSN LOG through Xid to obtain its CSN sequence number; parse the high 4 bits of the CSN sequence number to obtain the node number Node_id, and compare the CSN sequence number with the value of the array element corresponding to Node_id in the global vector CSN snapshot: if the CSN sequence number is less than the value, it is determined that the modified content of Xid is visible to this transaction; otherwise, the modified content of Xid is not visible to this transaction.

8. The method according to claim 7, characterized in that, The comparison logic used in step S5 is as follows: if the node number Node_id corresponding to the high 4 bits of the CSN sequence number is consistent with the array index of the global vector CSN snapshot, and the low part of the CSN sequence number is less than the low part of the array element corresponding to Node_id in the global vector CSN snapshot, then it is determined that the modified content of Xid is visible to this transaction; otherwise, the modified content of Xid is not visible to this transaction.

9. The method according to claim 6, characterized in that, The CSN sequence number in the multi-Master cluster mode described in step S1 is 64 bits, of which the high 4 bits are used to identify the node number that generated the CSN, and the remaining low bits are a globally increasing sequence. A CSN of 0 or 1 indicates that the transaction has not been committed or has been rolled back, while a CSN of 2 or greater indicates that the transaction has been committed.

10. The method according to claim 6, characterized in that, The asynchronous broadcast transmission described in step S2 does not wait for confirmation from other nodes; The update of the global CSN vector in step S3 uses atomic variable update operations to ensure data consistency when multiple threads receive messages concurrently.

Images