Write-Write Conflict Detection in a Multi-Master Shared Storage Database

Abstract

The present application provides systems and methods that can generate an efficient architecture and method for multiple database engines to write to a shared data store to eliminate global locks during the write process. The systems and methods can use a common log layer between the shared data store and the compute database nodes, where write conflict detection is implemented using write-ahead logging and log sequence numbers. The write-write conflict check for the write-ahead log records received from the database engines of multiple database engines can be performed by comparing the log sequence numbers received from the database engines together with the write-ahead log records with the global log sequence numbers in the hash table in the common log. After the write-ahead log record passes the write-write conflict check, the write-ahead log record can be sent to the shared data store.

Description

Technical Field

[0001] The present invention relates to data communication, and more particularly, to storing data in a shared storage database. Background Art

[0002] Some enterprise-level multi-master database systems can allow multiple database instances to access a shared storage for reading and writing to the shared storage and generating write-ahead log (WAL) records. Multiple database instances can generate write-ahead log records so that when any one of these database instances fails, the system can still perform read and write access through other instances. When multiple database instances perform read and write access to shared data, conflicts that occur need to be detected and resolved to maintain data consistency. For example, in terms of database technology, a write-write conflict is a computational event associated with the interleaved execution of transactions. This interleaved execution can come from write operations on the same data from different write sources. A write-write conflict can be referred to as overwriting uncommitted data, where the act of committing data makes a set of temporary changes permanent.

[0003] Centralized or distributed global locks are typically used to avoid conflicting access to shared data. The operations of acquiring and releasing locks need to communicate with a global lock manager. These lock acquisition and release operations have a critical impact on transaction execution, increasing latency and resulting in low throughput. Summary of the Invention

[0004] The object of various embodiments is to provide an efficient architecture and method for multiple database engines to write to a shared data storage, to eliminate global locks in the process of writing to the shared data storage by multiple master nodes, and to provide the benefits of optimistic concurrency control for a multi-master shared storage database system. Optimistic concurrency control (OCC) is a concurrency control method that is typically applied to transaction systems such as relational database management systems and software transaction memory, where the concurrency control method is a method of ensuring correct results for concurrent operations while obtaining results as quickly as possible. OCC assumes that multiple transactions can be completed frequently without interfering with each other. In OCC, when running an operation, data resources are used in a transaction without acquiring a lock on the resources, and before committing, each transaction can be verified so that no other transaction has modified the data read by that transaction. This object is achieved by the features of the independent claims. Other embodiments of the present invention will be apparent from the dependent claims, the description, and the drawings.

[0005] An embodiment is based on using a common log layer between a shared data store and computing nodes, where write conflict detection is implemented using write-ahead logging and log sequence numbers. Detection of write conflicts is generated by a write conflict check. The write conflict check (write conflict detection) may be referred to as a write-write conflict check (write-write conflict detection) because it is a check for conflicts from different write operations. In an architecture providing high availability, the common log layer may be arranged together with other common log layers between the storage node and the computing nodes. The conflict check may be implemented as a page-level check or a tuple-level conflict check. The locks used in the conflict check are local in the common log and no global locks are used. The locks provided by the common log do not require any network communication related to lock acquisition or release.

[0006] According to a first aspect, an embodiment relates to a computer-implemented method for writing to a data store shared between multiple database engines, the computer-implemented method comprising: using one or more processors to perform a write conflict check on write-ahead log records received from a database engine of the multiple database engines in a common log, wherein the write conflict check comprises: comparing a log sequence number received from the database engine together with the write-ahead log record with a global log sequence number in a hash table in the common log; after the write-ahead log record passes the write conflict check, sending the write-ahead log record to the data store shared between the multiple database engines. In this way, network communication related to lock acquisition and release can be eliminated.

[0007] This method eliminates the main bottleneck of the conflict resolution solution based on global locks. It essentially provides the benefits of optimistic concurrency control (OCC) for a multi-master shared data system. In the way of OCC, each master node runs transactions on the data in its local buffer pool without waiting for the transactions in other master nodes to hold locks. During group commit, the master nodes can flush the log records to the common log, and the common log can perform verification. The term "flush to an entity" means storing to the entity.

[0008] According to the first aspect, in a first implementation of the computer-implemented method, performing the comparison comprises using a tuple identifier or a page identifier as a key in the hash table, the key being associated with an entry represented in the form of a master node identifier and a global log sequence number value, the master node identifier being the identifier of the database engine of the multiple database engines.

[0009] According to the first aspect or any of the above implementation manners of the first aspect, in the second implementation manner of the computer-implemented method, the write conflict check includes that the log sequence number is greater than the global log sequence number.

[0010] According to the first aspect or any of the above implementation manners of the first aspect, in the third implementation manner of the computer-implemented method, the method includes: after passing the write conflict check, updating the global log sequence number to be equal to the log sequence number.

[0011] According to the first aspect or any of the above implementation manners of the first aspect, in the fourth implementation manner of the computer-implemented method, the method includes, after passing the write conflict check: inserting the write-ahead log record into a group flush write-ahead log buffer; saving all the write-ahead log records in the group flush write-ahead log buffer to a persistent log in the common log.

[0012] According to the first aspect or any of the above implementation manners of the first aspect, in the fifth implementation manner of the computer-implemented method, the method includes: copying the write-ahead log record to one or more follower common logs, and the one or more follower common logs are constructed as backups of the common log.

[0013] According to the first aspect or any of the above implementation manners of the first aspect, in the sixth implementation manner of the computer-implemented method, the write-ahead log record received from the database engine is extracted from a batch of write-ahead log records received from the database engine, and the batch of write-ahead log records has the log sequence number of one or more transactions between the database engine and the data store.

[0014] According to the first aspect or any of the above implementation manners of the first aspect, in the seventh implementation manner of the computer-implemented method, the method includes: extracting another write-ahead log record from another batch of write-ahead log records received from another database engine of the plurality of database engines, and the another batch of write-ahead log records has another log sequence number of one or more other transactions between the another database engine and the data store.

[0015] According to the first aspect or any of the above implementation manners of the first aspect, in the eighth implementation manner of the computer-implemented method, the method includes: maintaining all operations and commands for modifying the internal state of the common log in a command log.

[0016] According to a second aspect, an embodiment relates to a system, comprising: a memory including instructions; one or more processors communicatively coupled to the memory, wherein the one or more processors execute the instructions to: perform a write conflict check on write-ahead log records received from a database engine of a plurality of database engines in a common log, wherein the write conflict check includes: comparing a log sequence number received from the database engine together with the write-ahead log record with a global log sequence number in a hash table in the common log; after the write-ahead log record passes the write conflict check, sending the write-ahead log record to a data store shared among the plurality of database engines. With this system, network communication related to lock acquisition / release can be eliminated.

[0017] According to the second aspect, in a first implementation of the system, the comparison includes using a tuple identifier or a page identifier as a key in the hash table, the key being associated with an entry in the form of a master node identifier and a global log sequence number value, the master node identifier being an identifier of the database engine of the plurality of database engines.

[0018] According to the second aspect or any of the above implementations of the second aspect, in a second implementation of the system, passing the write conflict check includes the log sequence number being greater than the global log sequence number.

[0019] According to the second aspect or any of the above implementations of the second aspect, in a third implementation of the system, after passing the write conflict check, the one or more processors update the global log sequence number to be equal to the log sequence number.

[0020] According to the second aspect or any of the above implementations of the second aspect, in a fourth implementation of the system, after passing the write conflict check, the one or more processors: insert the write-ahead log record into a group flush write-ahead log buffer; save all write-ahead log records in the group flush write-ahead log buffer to a persistent log in the common log.

[0021] According to the second aspect or any of the above implementations of the second aspect, in a fifth implementation of the system, the one or more processors copy the write-ahead log record to one or more follower common logs, the one or more follower common logs being constructed as a backup of the common log.

[0022] According to the second aspect or any of the above implementation manners of the second aspect, in a sixth implementation manner of the system, the one or more processors extract the write-ahead log records from a batch of write-ahead log records, the batch of write-ahead log records being received from the database engine and having log sequence numbers of one or more transactions between the database engine and the data store.

[0023] According to the second aspect or any of the above implementation manners of the second aspect, in a seventh implementation manner of the system, the one or more processors extract another write-ahead log record from another batch of write-ahead log records, the another batch of write-ahead log records being received from another database engine of the plurality of database engines and having another log sequence number of one or more other transactions between the another database engine and the data store.

[0024] According to the second aspect or any of the above implementation manners of the second aspect, in an eighth implementation manner of the system, the one or more processors maintain, in a command log, all operations and commands that modify the internal state of the common log.

[0025] According to the eighth implementation manner of the second aspect, in a ninth implementation manner of the system, the system includes the plurality of database engines, the data store shared between the plurality of database engines, and one or more follower common logs in addition to the common log.

[0026] The computer-implemented method may be executed by the system. Other features of the computer-implemented method directly result from the functions of the system.

[0027] The explanations provided for the first aspect and its implementation manners are equally applicable to the second aspect and the corresponding implementation manners.

[0028] According to a third aspect, an embodiment relates to a non-transitory computer-readable medium storing computer instructions, wherein when the computer instructions are executed by one or more processors, when executed on a computer, the one or more processors are caused to perform the steps of any of the computer-implemented methods provided by the first aspect or any of its implementation manners. Thus, the computer-implemented method can be automatically and repeatedly executed.

[0029] The computer instructions stored by the non-transitory computer-readable medium may be executed by the system. The system may be programmably arranged to execute the computer instructions.

[0030] According to a fourth aspect, an embodiment relates to a system, the system comprising: means for performing a write conflict check on write-ahead log records received from a database engine of a plurality of database engines, wherein the write conflict check includes comparing a log sequence number received from the database engine together with the write-ahead log record with a global log sequence number in a hash table in a common log, wherein the means for performing the write conflict check includes the common log and is operatively arranged between the plurality of database engines and a shared data store, the shared data store being shared among the plurality of database engines; means for sending the write-ahead log record to the shared data store after the write-ahead log record passes the write conflict check.

[0031] According to the fourth aspect, in a first implementation of the system, the comparison includes using a tuple identifier or a page identifier as a key in the hash table, the key being associated with an entry represented in the form of a master node identifier and a global log sequence number value, the master node identifier being an identifier of the database engine of the plurality of database engines.

[0032] According to the fourth aspect or any of the above implementations of the fourth aspect, in a second implementation of the system, passing the write conflict check includes the log sequence number being greater than the global log sequence number.

[0033] According to the fourth aspect or any of the above implementations of the fourth aspect, in a third implementation of the system, after passing the write conflict check, the means for performing the write conflict check updates the global log sequence number to be equal to the log sequence number.

[0034] According to the fourth aspect or any of the above implementations of the fourth aspect, in a fourth implementation of the system, after passing the write conflict check, the means for performing the write conflict check performs: inserting the write-ahead log record into a group flush write-ahead log buffer; saving all write-ahead log records in the group flush write-ahead log buffer to a persistent log in the common log.

[0035] According to the fourth aspect or any of the above implementations of the fourth aspect, in a fifth implementation of the system, the means for performing the write conflict check copies the write-ahead log record to one or more follower common logs, the one or more follower common logs being constructed as a backup of the common log.

[0036] According to the fourth aspect or any of the above implementation manners of the fourth aspect, in the sixth implementation manner of the system, the device for performing the write conflict check extracts the pre-write log records from a batch of pre-write log records, the batch of pre-write log records is received from the database engine, and has the log sequence numbers of one or more transactions between the database engine and the data storage.

[0037] According to the fourth aspect or any of the above implementation manners of the fourth aspect, in the seventh implementation manner of the system, the device for performing the write conflict check extracts another pre-write log record from another batch of pre-write log records, the another batch of pre-write log records is received from another database engine of the multiple database engines, and has another log sequence number of one or more other transactions between the another database engine and the data storage.

[0038] According to the fourth aspect or any of the above implementation manners of the fourth aspect, in the eighth implementation manner of the system, the device for performing the write conflict check maintains all operations and commands that modify the internal state of the common log in the command log.

[0039] According to the eighth implementation manner of the fourth aspect, in the ninth implementation manner of the system, in addition to the device for performing the write conflict check and the device for sending the pre-write log records to the shared data storage, the system further includes the multiple database engines, the data storage shared between the multiple database engines, and one or more follower common logs.

[0040] The explanations provided for the first aspect and its implementation manners are equally applicable to the fourth aspect and the corresponding implementation manners.

[0041] Embodiments of the present invention can be implemented in hardware, software, or any combination thereof. Any one of the foregoing examples can be combined with any one or more of the foregoing other examples to generate new embodiments within the scope of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 is a block diagram of an exemplary system with an architecture provided by an exemplary embodiment, the architecture having a multi-master database with compute-storage separation.

[0043] Figure 2 Describes the exemplary operation components in the Figure 1 common log provided by the exemplary embodiment, and these operation components can facilitate write-write conflict detection.

[0044] Figure 3It is a flowchart of an exemplary period of a write-write conflict detection thread provided by an exemplary embodiment.

[0045] Figures 4 - 10 It shows the challenges of write conflicts in the PostgreSQL system provided by an exemplary embodiment and specific solutions. For example, the PostgreSQL system is an object-relational database management system.

[0046] Figure 11 It is a flowchart of the features of an exemplary method for writing to a data store shared among multiple database engines provided by an exemplary embodiment.

[0047] Figure 12 It is a block diagram of a circuit of a device for implementing an algorithm for providing write-write conflict detection for a multi-master shared storage database and a method for performing write-write conflict detection for a multi-master shared storage database. Detailed implementation

[0048] The following is a detailed description with reference to the accompanying drawings, which are a part of the description and illustrate specific embodiments in which the present invention can be practiced by way of illustration. These embodiments are described in sufficient detail to enable those skilled in the art to practice these embodiments. It should be understood that other embodiments can be utilized and structural, logical, and electrical changes can be made. Therefore, the following description of the exemplary embodiments should not be taken in a limiting sense.

[0049] In one embodiment, the functions or algorithms described herein can be implemented in software. The software may include computer-executable instructions stored in a computer-readable medium or a computer-readable storage device (such as one or more non-transitory memories or other types of hardware-based local or network storage devices). In addition, these functions correspond to modules, which can be software, hardware, firmware, or any combination thereof. Multiple functions can be executed in one or more modules as needed, and the described embodiments are merely examples. The software can be executed in a digital signal processor, an ASIC, a microprocessor, or other types of processors running in a computer system, such as a personal computer, a server, or other computer systems, thereby converting such a computer system into a specially programmed machine.

[0050] Non-transitory computer-readable media include all types of computer-readable media, including magnetic storage media, optical storage media, and solid-state storage media, specifically excluding signals. It should be understood that software can be installed in a device and sold with the device, such devices as taught herein to process event streams. Alternatively, the software can be obtained and loaded into such devices, including obtaining the software through optical disc media or from any form of network or distribution system, including for example obtaining the software from a server owned by the software creator or from a server not owned but used by the software creator. For example, the software can be stored in a server for distribution over the Internet.

[0051] In various embodiments, the system can be implemented with an architecture that operates a common log between a master node and a data storage layer. The master node can be implemented as a database node. The common log can be arranged as a write-write detection layer. Write-write detection can also be referred to as write-write conflict checking, where it is determined whether a write transaction from one source conflicts with a related write transaction from another source. The system can be a multi-master database system, designed with an architecture where database instances write log records to storage. Storage nodes can replay the log records, i.e., apply the log records to build data pages.

[0052] In such an architecture, the master database can flush log records to the common log, where the common log can perform page-level or tuple-level conflict checking. A database table can be divided into multiple pages. Each page can have a certain number of records. A tuple is a single record of a database table. A table can be divided into smaller units, such as pages, and each page can have multiple tuples. All locks used for conflict checking can be local locks in the common log, such that there are no global locks. The common log persists, and only log records that pass the conflict check are forwarded from the common log to the storage nodes. The architecture can allow for a high-availability (HA) common log layer between the storage nodes and the compute nodes, where the compute nodes can be databases. The HA can be provided by having multiple common logs at the conflict detection layer between the storage nodes and the compute nodes, where one of the multiple common logs is the primary common log and the other common logs of the multiple common logs are replicas of the primary common log. This replication defines the HA of the common log layer.

[0053] An architecture with a common log layer can be implemented using novel write-write conflict detection algorithms based on WAL and log sequence number (LSN), which can be performed for each log record. The log sequence number is the identification number of a given WAL record, indicating the position of the WAL record in the record sequence of a transaction. Write-write detection can be page-level conflict detection or tuple-level conflict detection. Such methods of handling conflicts at the tuple level or page level can provide fine-grained locks to achieve good parallelism, because in a common log, conflict checking runs in parallel on multiple worker threads. A thread is a sequence of instructions that can be executed in parallel with another sequence of instructions. The associated locks do not require any network communication. In addition, read operations do not participate in write-write conflict detection, which improves the overall system throughput. These write-write conflict detection techniques can eliminate conflict prevention based on global locks and can provide the benefits of OCC for a multi-master shared data / storage database system.

[0054] Figure 1is a block diagram of an embodiment of an exemplary system 100 having an architecture with a compute-storage separated multi-master database. System 100 may include multiple databases that communicate with a common log 110 to write data to a shared storage layer 120. In this figure, there are three databases with database engines 105-1, 105-2, and 105-3. Although three database engines for three databases are shown, system 100 may have fewer or more than three databases and thus may have fewer or more than three database engines. Each database engine may include one or more processors and a storage device storing instructions executable by the one or more processors to perform operations of the database as a component. Such operations of each database may include storing data generated by communicating with clients of the respective database in the shared storage layer 120 through operations of the common log 110. Each database represented by a database engine may be arranged as a database node acting as a master node that receives structured query language (SQL) queries or update / insert / delete / create requests for the database from users such as client devices. Data from the user to the database nodes managed by database engines 105-1, 105-2, and 105-3 may be served respectively through buffer pools 109-1, 109-2, 109-3 of database engines 105-1, 105-2, and 105-3, or may also be served through persistent storage nodes if the buffer pool in the database is unavailable or lost. When a transaction modifies a tuple, it creates a log record and flushes the log record of the modified tuple to the common log 110. The common log 110 performs a conflict check on the log record, and if the log record has no conflict, it distributes the log record to the shared storage layer 120, where a new version of the data is created by performing a log application operation.

[0055] Each database instance is a master node in the architecture of system 100. Each of the database engines 105-1, 105-2, and 105-3 can receive SQL queries from clients and can initiate transactions. Each of the database engines 105-1, 105-2, and 105-3 can flush WAL records to the common log 110. After successful completion of conflict checking, the common log 110 controls the loading of data pages from the database engines 105-1, 105-2, and 105-3 that initiate transactions into the shared storage layer 120. However, data pages from the shared storage layer 120 can be loaded by each of the database engines 105-1, 105-2, and 105-3. For example, a data page can be loaded by database engine 105-1 from the shared storage layer along path 132. Appropriate data can be loaded into each of the database engines 105-2 and 105-3 in a similar manner.

[0056] The common log 110 can include one or more processors and a storage device storing instructions executable by the one or more processors to perform the operations of the common log 110. The common log 110 can perform multiple functions. The common log can receive different WAL records from the database engines 105-1, 105-2, and 105-3 operating as master nodes via paths 106-1, 106-2, and 106-3 respectively. It can perform write-write conflict detection and can send the WAL records that pass its conflict checking to the shared storage layer 120. In the architecture of system 100, the common log 110 operates as the master common log node in an HA arrangement. As the master common log node, the common log 110 is the leader common log node that replicates the WAL records that pass conflict checking to the follower common logs 115-1 and 115-2. The WAL records can be sent to the follower common log 115-1 along path 113-1, and the WAL records can be sent to the follower common log 115-2 along path 113-2. The common log 110, as the leader common log node of system 100, can replicate its internal state to the follower common log 115-1 and the follower common log 115-2 by sending the command log to these follower common logs. The command log can be sent to the follower common log 115-1 along path 119-1, and the command log can be sent to the follower common log 115-2 along path 119-2. The command log can retain all operations that modify the internal state of the common log 110, and these operations can be identified as commands.

[0057] Although Figure 1Two follower common logs are shown, but system 100 may have fewer or more than two follower common logs in the common log layer between the master node and the shared storage layer. The common log 110 provides the architecture of the HA common log layer between the storage node and the computing node along with the implementation of the follower common logs. The HA feature of this architecture of the system increases as the number of follower common logs set in the common log layer of the system increases. When the leader common log fails, the follower common logs in the HA common log layer become the leader common log. The order in which the follower common logs become the leader common log can be predefined or implemented using traditional techniques for selecting a leader node among a group of peer nodes when the leader common log fails.

[0058] The common log 110 may include a global transaction manager (GTM) 112 residing in the common log 110. The GTM 112 may generate transaction identification (ID). These transaction IDs may be generated in ascending order. The GTM 112 may maintain a snapshot of the active transactions to the database engine, such as the path 133 to the database engine 105-1. The snapshot may be implemented as a list of active transactions. To enable the follower common logs 115-1 and 115-2 to replace the common log 110, the follower common logs 115-1 and 115-2 respectively include GTMs 117-1 and 117-2 that can perform the functions of the GTM 112.

[0059] The shared storage layer 120 may be implemented as a shared storage server having storage nodes 125-1, 125-2, 125-3, 125-4, and 125-5. The shared storage server may include one or more processes that control the operation of the shared storage server by executing instructions stored in the shared storage layer 120. Although five storage nodes are shown, the shared storage layer 120 may include fewer or more than five storage nodes. Each storage node may include one or more storage devices. The storage nodes 125-1, 125-2, 125-3, 125-4, and 125-5 may be structured as distributed storage nodes. The shared storage layer 120 may receive different WAL records from the common log 110 along multiple paths such as paths 123-1, 123-2, and 123-3.

[0060] Figure 2 is described Figure 1Examples of exemplary operation components within the common log 110 that can facilitate write-write conflict detection. Similar or identical operation components are provided in follower common logs 115-1 and 115-2 so that when a selected follower common log changes to a leader common log, operations are performed as the common log leader. The operation components can be implemented using storage devices controlled by one or more processors of the common log 110. In Figure 2 the example shown, these operation components residing in the common log 110 can be implemented as buffers 252 and 254 for write-write conflict detection threads, hash table 255, group flush WAL buffer (GFWB) 256, and persistent log 258. For ease of presentation, the common log 110 is shown receiving a batch of write transaction log records from only two primary nodes 105-1 and 105-2. The shown components can be extended to handle communication of the common log 110 with more than two primary nodes.

[0061] The write-write conflict detection threads in buffers 252 and 254 can be dedicated worker threads that perform write-write conflict detection in parallel on the buffers of transaction log records. The dedicated threads in buffers 252 and 254 can concurrently run conflict checks on each batch of WAL records. In Figure 2 it, regarding threads 1 and 2 associated with buffers 252 and 254 respectively, W ij (x) represents a write transaction log record, where W ij represents the jth write operation (write transaction log) record from the ith transaction (T i ). The parameter x is a tuple ID or a page ID, depending on whether the conflict detection is tuple-level or page-level conflict detection. In the case where each write transaction log record passing the write-write conflict check is assigned a global LSN in the common log 110, the term "reader LSN" represents the latest global LSN known to the transaction. In Figure 2 the example, the data for thread 1 includes a reader LSN equal to 7 for a batch of write transaction records with committed transactions C2 and C1 for transactions 1 and 2. The committed transactions are from the perspective of the primary node, and the primary node does not perceive any inconsistency with the execution of a given committed transaction. The data is received in chronological order, starting from the left and proceeding to the right. In this example, the commit of transaction 2 occurs before the commit of transaction 1, although the write transaction log record of transaction 1 is received before the record of transaction 2. The data for thread 2 includes a reader LSN equal to 7 for a batch of write transaction records with committed transactions C3 and C4 for transactions 3 and 4. Different from the data of thread 1, the commit of transaction 3 occurs before the commit of transaction 4, and the write transaction log record of transaction 3 is received before the record of transaction 4.

[0062] The hash table 255 is a write-write conflict detection hash table 255 with entries of tuple ID or page ID 261, primary node ID, and LSN 262, and bucket (also called slot) number 263. For tuple-level conflict checking, the key of the write-write conflict detection hash table 255 is the tuple ID; for page-level conflict checking, the key is the page ID. The value form of the key is {primary node ID, LSN}, including the latest global LSN of the WAL record that modifies the tuple or page. The primary node ID is the ID of the primary node that sends the WAL record. Whenever a log record passes the conflict check in the common log 110, a new global LSN is assigned to this log record. The LSN in {primary node ID, LSN} represents this global LSN, and the primary node ID is the primary node that sends the log record to the common log 110. The global LSN is only generated for WAL records that pass the conflict check. For N primary nodes, the primary node ID can be an integer from 1 to 10, and each integer is assigned to one of the N primary nodes, which is different from the other primary nodes of the N primary nodes. The write-write conflict detection hash table 255 has a fixed number of buckets, and each bucket has its own lock. The bucket lock is a tuple lock or a page lock, depending on whether the conflict check is tuple-level or page-level.

[0063] In the common log 110, when a WAL record passes the conflict check, the WAL record is inserted into the GFWB 256. Once the WAL record enters the GFWB 256, a new global LSN is assigned to this WAL record. When the GFWB 256 is full or the timer expires, all the log records in the GFWB 256 are flushed to the persistent log 258 of the common log 110. The persistent log 258 can be implemented as a disk. All log records that pass the conflict check are eventually flushed to the persistent log 258 and are also sent to Figure 1 the storage nodes 125-1, 125-2, 125-3, 125-4, and 125-5 of the shared storage layer 120. The components of the common log 110 are used as shown in Figure 3 shown.

[0064] Figure 3 is a flowchart 300 of an exemplary cycle of the write-write conflict detection thread. This cycle can be implemented in the common log (such as the common log 110 of Figure 1 and Figure 2 ), using one or more processors to execute instructions stored in the memory, such as implemented in the common log layer of the system. In 305, a batch of WAL records is received at the common log. For example, the WAL records of the write-write conflict detection thread 1 can be received in a buffer (such as buffer 252). The buffer 252 can include many log records and is not limited to four log records. In 310, the WAL record W is extracted from the bufferij (x). In the sequence of processing WAL records, the extracted W ij (x) is the next WAL record in the buffer to be conflict-checked. In 315, the transaction ID is extracted from W ij (x). In 320, it is determined whether W ij (x) is a write operation record, an abort record, or a commit record. In 325, if W ij (x) is an abort record, the transaction ID is aborted, and the operation to go to 310 is executed to extract the next WAL record.

[0065] In 330, if W ij (x) is a commit record, it is determined whether the transaction ID is marked as "conflicted" or by other means of identifying a conflict. In 335, if the transaction ID is marked as having a conflict, the transaction ID is aborted, and the operation to go to 310 is executed to extract the next WAL record. In 340, if the transaction ID is not marked as having a conflict, the transaction ID is committed, and the process goes to 310 to extract the next WAL record.

[0066] In 345, if it is determined in 320 that W ij (x) is a write operation record, the page ID or tuple ID is extracted from W ij (x), and the reader LSN is extracted from W ij (x). In 350, a lookup is performed in a hash table (such as Figure 2 the write-write conflict detection hash table 255) by the extracted page ID or the extracted tuple ID, and an entry with the extracted page ID or the extracted tuple ID is obtained. In 355, it is determined whether the primary node ID of the extracted entry is not equal to the primary node ID of the sender of W ij (x), and whether the LSN of the entry extracted from the hash table is greater than the reader LSN extracted from W ij (x). In 360, if the conditions in 355 are met, the transaction ID is marked as "conflicted" or other equivalent identifier, and the process goes to 310 to extract the next WAL record. The current condition occurs because the received W ij (x) identifies the latest global LSN known to the transaction, represented by the reader LSN, which is less than the current global LSN identifying other write operations that have occurred, such that the data is not in the expected state.

[0067] In 365, if no conflict is found in 355, several actions are taken. W ij (x) is inserted into GFWB, with the first LSN following the current WAL record in GFWB. The LSN of the hash table entry is updated to the one from W ij(x)Insert the LSN at which GFWB starts. Update the primary node ID of the hash table entry to be equal to the primary node ID of (x). Then, if GFWB is full or the timer reaches the set time, flush GFWB. The internal state changes are retained in the command log, which is also transmitted to the follower public logs, such as ij the follower public logs 115-1 and 115-2. Each write-write conflict detection thread can continuously run the above conflict detection algorithm on each batch of WAL records. Figure 1 Multiple write-write conflict detection threads work concurrently to provide parallelism to the system. Each thread can access the write-write conflict detection hash table of the public log using a bucket-level lock (close to a tuple-level lock or a page-level lock, depending on whether the write-write conflict detection is performed at the page level or the tuple level). A fixed number of buckets can be pre-allocated for the write-write conflict detection hash table. Each bucket can have its own lock, where the lock can be derived from the index of the bucket.

[0068] To provide public log HA, all log records that pass the conflict check can be propagated to the follower public logs. The follower public logs can be referred to as the standby public logs. Additionally, the state of the write-write conflict detection hash table and GFWB can be copied to the standby public logs by transmitting the command log to each standby public log. The command log stores all the operations / commands that modify the write-write conflict detection hash table and GFWB.

[0069] Compared with page-level write-write conflict checking, tuple-level write-write conflict checking can reduce the number of conflicts and can yield better throughput. At the same time, tuple-level write-write conflict detection poses more challenges to implementation. In terms of

[0070] Figures 4 - 10 ​In the next section, as an example, the challenges and specific solutions of PostgreSQL page and tuple layout are described. PostgreSQL is an object-relational database management system (ORDBMS), where an ORDBMS is a database management system (DBMS) similar to a relational database but with an object-oriented database model in which the database schema and query language directly support objects, classes, and inheritance. PostgreSQL is open source and complies with the atomicity, consistency, isolation, and durability (ACID) principles, which are a set of properties of database transactions designed to ensure validity even in the event of errors, power failures, etc. PostgreSQL manages concurrency through a system called multi-version concurrency control (MVCC), which provides a snapshot of the database for each transaction, allowing changes to be made invisibly to other transactions until the changes are committed.

[0071] In PostgreSQL, the data file can be referred to as a heap, where the heap can be associated with heap tuples (HTUP), pages with page numbers (PAGE_NO), and line pointers (LP) with line pointer numbers (LP_NO). Also associated with the data file (heap) are indexes. An index is a specific structure that organizes references to data to make lookups easier. In PostgreSQL, an index can be a copy of an item that combines a reference index to the actual data location. Associated with the index are index tuples (ITUP) and LP_NO. In Figures 4 - 10 it, the reference labels with H, I, and HI refer to the heap, index, and heap or index respectively, and tup refers to a tuple.

[0072] Inserts should not conflict with each other. However, the heap insert and index insert implementations in PostgreSQL can cause conflicts between inserts in a multi-master system. Figure 4An example of an inserted log record that causes a conflict. If the common log receives log records from primary node 405-1 and primary node 405-2, only the log records from one primary node can win. This can lead to a large number of insert conflicts. Primary node 405-1 submits a transaction log (XLOG) record 1 to insert an HTUP labeled HTUP1. XLOG record 1 includes the content of HTUP1, with information that PAGE_NO is equal to HX and LP_NO is equal to 1. Primary node 405-1 also submits XLOG record 2 to insert an ITUP labeled ITUP1. XLOG record 2 includes the content of ITUP1, with information that PAGE_NO of XLOG record 2 is equal to IY and LP_NO is equal to 1. The content of ITUP 1 is PAGE_NO = HX and LP_NO = 1. Primary node 405-2 submits a transaction log (XLOG) record 1 to insert an HTUP labeled HTUP2. XLOG record 1 includes the content of HTUP2, with information that PAGE_NO is equal to HX and LP_NO is equal to 1. Primary node 405-2 also submits XLOG record 2 to insert an ITUP labeled ITUP2. XLOG record 2 includes the content of ITUP2, with information that PAGE_NO of XLOG record 2 is equal to IY and LP_NO is equal to 1. The content of ITUP 2 is PAGE_NO = HX and LP_NO = 1, which causes a conflict in XLOG record 2 from primary node 405-1.

[0073] The following are the methods to eliminate such conflicts. First, when inserting a heap tuple, the primary node checks to determine whether the LP_NO can be equal to its own primary node ID, rather than simply selecting an unused LP. In Figure 4 the example, primary node 405-1 (ID = 1) can select LP1 on page HX, and primary node 405-2 (ID = 2) can select LP2 on page HX. Second, when inserting an index tuple, each primary node can simply select the next unused LP. However, the LP_NO should not appear in the log record. In this way, when the log record is applied to the storage node, the overall next LP can be calculated, where the LPS of the index tuples are sorted according to the order of the index keys.

[0074] Figure 5 Shows these operating principles using a common log to provide modified log records for inserts to eliminate conflicts associated with Figure 4 as Figure 5As shown, the XLOG record 1 of the primary node 405-1 from the primary node with ID = 1 has LP_NO = 1 for inserting HTUP1, while the XLOG record 2 from the primary node 405-1 has LP_NO = Ф (the next unused LP), and the XLOG record 1 of the primary node 405-2 from the primary node with ID = 2 has LP_NO = 2, and the XLOG record 2 from the primary node 405-2 has LP_NO = Ф (the next unused LP). The associated common logs of the two primary nodes can allow the two primary nodes to commit, where different LP_NO do not conflict.

[0075] When a heap or index (hereinafter referred to as HI) page is nearly full, insertions from different writers may also conflict with each other.

[0076] Figure 6 An example of an insertion relative to a full page is shown. For example, the primary node 605-1 finds that there is space for one tuple in the page heap or index X (HIX), so it inserts the heap or index tuple (HITUP) 6 (HITUP6) with the unused LP_NO = 5 or the next unused LP_NO = Ф. The associated common log receives the XLOG record of the heap or index tuple 6 (HITUP6) from the primary node 605-1. The XLOG record has the PAGE_NO of the heap or index, PAGE_NO = X, LP_NO = 5 (heap) or the next unused LP_NO = Ф (index), and the content of tuple 6 (heap or index). The primary node 605-2 also finds that there is space for one tuple in the page HIX, so the primary node 605-2 inserts HITUP7 with LP_NO = 6 or the next unused LP_NO = Ф. The associated common log receives the XLOG record of the heap or index tuple 7 (HITUP7) from the primary node 605-2. The XLOG record has the PAGE_NO of the heap or index, PAGE_NO = X, LP_NO = 6 (heap) or the next unused LP_NO = Ф (index), and the content of tuple 7 (heap or index). When the common log receives the two log records of HITUP6 and HITUP7, it does not find a conflict and commits these two log records. However, when applying these two log records, the storage finds that there is no space on the page HIX, but the transaction has been committed. To detect page full conflicts, the common log maintains a freespace map (FSM) page. Each heap and index relation can have an FSM to track the available space in the relation. When the log records related to the insertion have no conflict and are ready to be committed, the common log also checks whether the increase will cause the page size to overflow. If so, the common log aborts the transaction. Updates that add a new version of a tuple are handled similarly.

[0077] Insertions may cause index page splits. When one writer splits an index page and another writer inserts an index tuple into the same page, the split or the insertion should abort. Figure 7 is an example of index page splitting. In Figure 7 , the master node 705-1 inserts ITUP5, filling the index page IX. Then, the master node 705-1 attempts to insert ITUP6 into page IX. Page IX splits, where the first half of the ITUPs stays in page IX and the second half goes into a new page INEW. ITUP5 and ITUP6 both go to INEW because their index keys are larger. The master node 705-2 inserts ITUP7 into page IX, assuming that ITUP7 has the largest key.

[0078] Figure 8 roughly shows Figure 7 the log records generated by two master nodes from an index page split. The master node 705-1 generates XLOG 1 for the index tuple ITUP5, which includes PAGE_NO = IX (index page X), LP_NO = Ф, and the content of ITUP5 (e.g., PAGE_NO = HX and LP_NO = 1). The master node 705-1 generates XLOG 1 for the index tuple ITUP6 and the split of page IX, which includes the LP_NO at the split point, the new PAGE_NO of the new page, and the content of the new page containing ITUP5 and ITUP6. The master node 705-2 generates XLOG 1 for the index tuple TUP7, which includes PAGE_NO = IX (index page X), LP_NO = Ф, and the content of ITUP7 (e.g., PAGE_NO = HX and LP_NO = 2).

[0079] The common log maintains one or more PAGE_NO of the most recently split index pages and their latest committed LSNs in the write-write conflict detection hash table of the common log. Assuming the common log commits the changes of the master node 705-1 first, the common log receives the log record from the master node 705-2 about inserting ITUP7 on page IX. The common log finds that only PAGE_NO = IX has split, the split commit LSN is later than the reader LSN of the log record of the master node 705-2, and it aborts the changes of the master node 705-2. Similarly, assuming the common log commits the changes of the master node 705-2 first, the common log receives the log record from the master node 705-1 about the split of page IX. The split reader LSN is earlier than the commit LSN of the master node 705-2 inserted on page IX, and the common log aborts the split of page IX.

[0080] Figure 9Illustrates handling update-update conflicts. Handling updates can be relatively straightforward. Assume that primary node 905-1 and primary node 905-2 attempt to update HTUP0 at {PAGE_NO = HX, LP_NO = 0}. The newer version on primary node 905-1 is HTUP0' at {PAGE_NO = HX, LP_NO = 1}, with content HTUP0', and the maximum page (XMAX) equal to the transaction ID (TID1) of primary node 905-1. The newer version on primary node 905-2 is HTUP0'' at {PAGE_NO = HX, LP_NO = 2}, with content HTUP0'', and the maximum page (XMAX) equal to the transaction ID (TID2) of primary node 905-2. The LP_NO selected on the heap page satisfies LP_NO = primary node ID. If the common log first commits the log record of primary node 905-1, then when the common log discovers that the latest committed LSN of HTUP0 at {PAGE_NO = HX, LP_NO = 0} is greater than the reader LSN of the log record of primary node 905-2 that also contains HTUP0 at {PAGE_NO = HX, LP_NO = 0}, the log record will reject the change of primary node 905-2. The same reasoning applies when the common log first commits the log record of primary node 905-2.

[0081] Figure 10 Illustrates handling update-delete conflicts. Assume that primary node 1005-1 deletes HTUP0 at {PAGE_NO = HX, LP_NO = 0}, and primary node 1005-2 updates HTUP0 to HTUP0'. Primary node 1005-2 places HTUP0' at {PAGE_NO = HX, LP_NO = 2}. If the associated common log first commits the log record of primary node 1005-1, then when the common log discovers that the latest committed LSN of HTUP0 at {PAGE_NO = HX, LP_NO = 0} is greater than the reader LSN of the log record of primary node 1005-2 that also contains HTUP0 at {PAGE_NO = HX, LP_NO = 0}, the log record will reject the change of primary node 1005-2. Similar reasoning applies when the common log first commits the log record of primary node 1005-2.

[0082] Figure 11It is a flowchart of the features of an exemplary method 1100 for writing to a data store shared among multiple database engines. Method 1100 can be implemented as a computer-implemented method. In 1110, using one or more processors, a write-write conflict check is performed on the write-ahead log records received from the database engines of the multiple database engines in a common log, wherein the write-write conflict check includes: comparing the log sequence number received from the database engine together with the write-ahead log record with the global log sequence number in a hash table in the common log. Performing the comparison may include using a tuple identifier or a page identifier as the key in the hash table, and the key is associated with an entry represented in the form of a master node identifier and a global log sequence number value, wherein the master node identifier may be the identifier of the database engine of the multiple database engines.

[0083] In 1120, after the write-ahead log record passes the write-write conflict check, the write-ahead log record is sent to the data store shared among the multiple database engines. Passing the write conflict check may include that the log sequence number is greater than the global log sequence number. After passing the write conflict check, method 1100 or a method similar to method 1100 may include updating the global log sequence number to be equal to the log sequence number. After passing the write conflict check, method 1100 or a method similar to method 1100 may include: inserting the write-ahead log record into a group flush write-ahead log buffer; saving all the write-ahead log records in the group flush write-ahead log buffer to a persistent log in the common log.

[0084] Variations of method 1100 or a method similar to method 1100 may include many different embodiments, and these embodiments can be combined according to the application of such methods and / or the architecture of the systems implementing such methods. Such methods may include copying the write-ahead log record to one or more follower common logs, and the one or more follower common logs are constructed as backups of the common log. Such methods may include maintaining all operations and commands for modifying the internal state of the common log in a command log.

[0085] In method 1100 or a method similar to method 1100, the write-ahead log record received from the database engine may be extracted from a batch of write-ahead log records received from the database engine, and the batch of write-ahead log records has the log sequence number of one or more transactions between the database engine and the data store. Another write-ahead log record may be extracted from another batch of write-ahead log records received from another database engine of the multiple database engines, and the another batch of write-ahead log records has another log sequence number of one or more other transactions between the another database engine and the data store.

[0086] In various embodiments, a non-transitory machine-readable storage device (such as a computer-readable non-transitory medium) may include instructions stored thereon that, when executed by components of a machine, cause the machine to perform operations, where the operations include one or more features that are similar or identical to the features of the methods and techniques described with respect to method 1100, flowchart 300, its variations, and / or the features of other methods taught herein (such as those Figures 1 - 11 associated). The physical structure of such instructions may be operated on by one or more processors. For example, executing these physical structures may cause the machine to perform operations including: using one or more processors to perform a write-write conflict check on write-ahead log records received from database engines of a plurality of database engines in a common log, where the write-write conflict check includes: comparing a log sequence number received from the database engine together with the write-ahead log record with a global log sequence number in a hash table in the common log; after the write-ahead log record passes the write-write conflict check, sending the write-ahead log record to the data store shared among the plurality of database engines. Performing the comparison may include using a tuple identifier or a page identifier as a key in the hash table, where the key is associated with an entry in the form of a master node identifier and a global log sequence number value, and the master node identifier is an identifier of the database engine of the plurality of database engines.

[0087] Using one or more processors to execute instructions stored in a machine-readable storage device may include the following operations: The write-write conflict check may include that the log sequence number is greater than the global log sequence number. After passing the write-write conflict check, the executable operation may include updating the global log sequence number to be equal to the log sequence number. After passing the write-write conflict check, the executable operation may include: inserting the write-ahead log record into a group flush write-ahead log buffer; saving all write-ahead log records in the group flush write-ahead log buffer to a persistent log in the common log.

[0088] The operations may include: extracting the write-ahead log record received from the database engine from a batch of write-ahead log records, the batch of write-ahead log records received from the database engine having the log sequence number of one or more transactions between the database engine and the data store. The operations may include: extracting another write-ahead log record from another batch of write-ahead log records, the other batch of write-ahead log records received from another database engine of the plurality of database engines having another log sequence number of one or more other transactions between the other database engine and the data store.

[0089] The operation may include copying the write-ahead log record to one or more follower common logs, where the one or more follower common logs are constructed as a backup of the common log. The operation may include maintaining, in the command log, all operations and commands that modify the internal state of the common log.

[0090] Figure 12 is a block diagram of a circuit of a device for implementing an algorithm for providing write-write conflict detection for a multi-master shared storage database and for implementing a method for providing write-write conflict detection for a multi-master shared storage database according to the teachings herein. Figure 12 Depicts a device 1200 having a non-transitory memory 1201 for storing instructions, a cache 1207, and a processing unit 1202 coupled to a bus 1220. The processing unit 1202 may include one or more processors operatively communicating with the non-transitory memory 1201 and the cache 1207. According to any method taught herein, the one or more processors may be configured to execute instructions to operate the device 1200 as a database engine, a common log, or a shared data store.

[0091] The device 1200 may include a communication interface 1216 that can be used to communicate between devices and systems associated with an architecture such as Figure 1 the architecture). One or more of a plurality of databases, common logs, and shared data stores may be implemented in a cloud that may be associated with the device 1200. Generally, the term "cloud" refers to data processing being performed in many virtual servers rather than directly in a physical machine. The cloud may span a wide area network (WAN). A WAN generally also refers to the public Internet and sometimes also refers to a network of leased fiber optic links interconnecting multiple branches of an enterprise. Alternatively, the cloud may reside entirely within a private data center within an internal local area network. A cloud data center, i.e., a data center that hosts virtual computing or services, may also provide services for network traffic management from one location on the network to another location on the network, or for network traffic management of a network spanning remote locations via a WAN (or the Internet). Additionally, the term "cloud computing" refers to the software and services that these servers perform for users in a virtual manner (via a hypervisor), and generally, the user is unaware of the physical location of the server or data center. Additionally, a data center may be a distributed entity. Cloud computing can provide shared computer processing resources and data to computers and other devices on demand via an associated network. The communication interface 1216 may be part of a data bus that can be used to receive data traffic for processing.

[0092] The non-transitory memory 1201 can be implemented as a machine-readable medium, such as a computer-readable medium, and can include volatile memory 1214 or non-volatile memory 1208. The device 1200 can include or can access a computing environment that includes various machine-readable media, such as computer-readable media including volatile memory 1214, non-volatile memory 1208, removable memory 1211, and non-removable memory 1222. Such machine-readable media can be used with the instructions in one or more programs 1218 executed by the device 1200. The cache 1207 can be implemented as a separate memory component or a part of one or more of volatile memory 1214, non-volatile memory 1208, removable memory 1211, or non-removable memory 1222. The memory can include random access memory (RAM), read only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, or other memory technologies, compact disc read-only memory (CD ROM), digital versatile disc (DVD), or other optical disc memory, magnetic tape cartridges, tapes, magnetic disk storage, or any other medium capable of storing computer-readable instructions.

[0093] The device 1200 can include or can access a computing environment that includes an input interface 1226 and an output interface 1224. The output interface 1224 can include a display device (such as a touch screen), which can also be used as an input device. The input interface 1226 can include one or more of the following: a touch screen, a touchpad, a mouse, a keyboard, a camera, one or more device-specific buttons, one or more sensors integrated within the device 1200 or coupled to the device 1200 via a wired or wireless data connection, and other input devices.

[0094] Device 1200 can operate in a networked environment using a communication connection to connect to one or more other remote devices. Such remote devices can be the same as or similar to Device 1200, or can be different types of devices having characteristics similar to or the same as those of Device 1200 or other characteristics taught herein, to process, in accordance with the techniques herein, processes associated with providing write-write conflict detection for a multi-master shared storage database. The remote devices can include computers, such as database servers. Such remote computers can include personal computers (PCs), servers, routers, network PCs, peer devices, or other common network nodes, etc. The communication connection can include a Local Area Network (LAN), a Wide Area Network (WAN), a cellular network, WiFi, Bluetooth, or other networks.

[0095] Machine-readable instructions, such as computer-readable instructions stored in a computer-readable medium, can be executed by the processing unit 1202 of Device 1200. Hard disk drives, CD-ROMs, and RAM are some examples of articles of manufacture that include non-transitory computer-readable media, such as storage devices. The terms "machine-readable medium", "computer-readable medium", and "storage device" do not include carrier waves because carrier waves are too transient. The memory can also include networked memory, such as a storage area network (SAN).

[0096] Device 1200 can be implemented as a computing device that can take different forms in different embodiments, as part of a network such as an SDN / IoT network. For example, Device 1200 can be a smart phone, a tablet computer, a smart watch, other computing devices, or other types of devices having wireless communication capabilities, where such devices include components for participating in the distribution and storage of content items, as taught herein. Devices such as smart phones, tablet computers, smart watches, and other types of devices having wireless communication capabilities are generally collectively referred to as mobile devices or user devices. In addition, some of these devices can be considered as systems that implement their functions and / or applications. Further, although various data storage elements are illustrated as part of Device 1200, the memory can also or alternatively include cloud-based memory accessible via a network, such as the Internet or server-based memory.

[0097] In an exemplary embodiment, device 1200 includes: a conflict checking module for performing write-write conflict checking on write-ahead log records received from database engines of multiple database engines in a common log using one or more processors, wherein the write-write conflict checking includes: comparing a log sequence number received from the database engine together with the write-ahead log record with a global log sequence number in a hash table in the common log; a sending module for sending the write-ahead log record to the data store shared among the multiple database engines after the write-ahead log record passes the write-write conflict checking. In some embodiments, device 1200 may include other modules or additional modules for performing any one or a combination of the steps described in the embodiments. In addition, any additional or alternative embodiments or aspects of the method shown in any of the figures or recited in any of the claims may also be expected to include similar devices.

[0098] In addition, a machine-readable storage device, such as a computer-readable non-transitory medium, is a physical device that stores data represented by a physical structure within a corresponding device. Such a physical device is a non-transitory device. Examples of machine-readable storage devices may include, but are not limited to, read only memory (ROM), random access memory (RAM), disk storage devices, optical storage devices, flash memory or other electrical storage devices, magnetic storage devices, and / or optical storage devices. A machine-readable device may be such as Figure 12Machine-readable media such as the memory 1201. Terms such as "memory", "memory module", "machine-readable media", "machine-readable device" and similar terms shall be considered to include all forms of storage media, whether in the form of a single medium (or device) or multiple media (or devices), including all forms. For example, such a structure can be implemented as one or more centralized databases, one or more distributed databases, associated caches and servers; one or more storage devices, such as storage drives (including but not limited to electronic, magnetic, optical drives and storage mechanisms), and one or more instances of storage devices or modules (whether main memory; cache memory internal or external to the processor; or buffers). Terms such as "memory", "memory module", "machine-readable media" and "machine-readable device" shall be considered to include any tangible non-transitory medium that can store or encode a sequence of instructions executable by a machine and that causes the machine to perform any of the methods taught herein. The term "non-transitory" when used in conjunction with "machine-readable device", "media", "storage media", "device" or "storage device" expressly includes all forms of storage drives (optical, magnetic, electrical, etc.) and all forms of storage devices (such as DRAM, Flash (all storage designs), SRAM, MRAM, phase change storage devices, etc., and all other structures designed to store any type of data for later retrieval).

[0099] In various embodiments, a system can be implemented to enable write-write conflict detection for a multi-master shared storage database. Such a system can include a memory having instructions and one or more processors in communication with the memory. The one or more processors can execute the instructions to: perform a write conflict check on pre-write log records received from database engines of multiple database engines in a common log, wherein the write conflict check includes: comparing a log sequence number received from the database engine together with the pre-write log record with a global log sequence number in a hash table in the common log; after the pre-write log record passes the write conflict check, sending the pre-write log record to a data store shared among the multiple database engines. The comparison can include using a tuple identifier or a page identifier as a key in the hash table, wherein the key is associated with an entry in the form of a master node identifier and a global log sequence number value, and the master node identifier is an identifier of the database engine of the multiple database engines.

[0100] Variations of such a system or similar systems can include many different embodiments, which can be combined according to the applications of such systems and / or the architectures implementing such systems. A write conflict check can include that the log sequence number is greater than the global log sequence number. After passing the write conflict check, one or more processors can update the global log sequence number to be equal to the log sequence number. After passing the write conflict check, one or more processors can insert the write-ahead log record into the group flush write-ahead log buffer and save all the write-ahead log records in the group flush write-ahead log buffer to the persistent log in the common log.

[0101] Such a system can include one or more processors for executing instructions to copy write-ahead log records to one or more follower common logs, wherein the one or more follower common logs are constructed as a backup of the common log. One or more processors can extract write-ahead log records from a batch of write-ahead log records received from a database engine and having a log sequence number of one or more transactions between the database engine and a data store. One or more processors can extract another write-ahead log record from another batch of write-ahead log records received from another database engine of a plurality of database engines and having another log sequence number of one or more other transactions between the other database engine and the data store. One or more processors can maintain all operations and commands modifying the internal state of the common log in a command log.

[0102] Such a system or similar systems can include multiple database engines, a data store shared among the multiple database engines, and one or more follower common logs in addition to the common log. The multiple database engines can be independent structural units, separate from the common log and the shared data store. The multiple database engines can communicate with the leader common log of the follower common logs and the shared data store to transmit data using conventional communication technologies (such as but not limited to Transmission Control Protocol (TCP) and Internet Protocol (IP)). Such a system or similar systems can be constructed according to any permutation of the features for write-write conflict detection for a multi-master shared storage database taught herein.

[0103] In various embodiments, a system can be implemented to enable write-write conflict detection for a multi-master shared storage database. Such a system can include: means for performing a write conflict check on pre-write log records received from a database engine of a plurality of database engines, wherein the write conflict check includes comparing a log sequence number received from the database engine together with the pre-write log record with a global log sequence number in a hash table in a common log, wherein the means for performing the write conflict check includes the common log and is operatively arranged between the plurality of database engines and a shared data store, the shared data store being shared among the plurality of database engines; means for sending the pre-write log record to the shared data store after the pre-write log record passes the write conflict check. The comparison can include using a tuple identifier or a page identifier as a key in the hash table, the key being associated with an entry in the form of a master node identifier and a global log sequence number value, the master node identifier being an identifier of the database engine of the plurality of database engines.

[0104] Variations of such a system or similar systems having means for performing a write conflict check on pre-write log records received from a database engine of a plurality of database engines can include many different embodiments, which can be combined according to the application of such systems and / or the architecture implementing such systems. A write conflict check can include a log sequence number being greater than the global log sequence number. After passing the write conflict check, the means for performing the write conflict check can update the global log sequence number to be equal to the log sequence number. After passing the write conflict check, the system means for performing the write conflict check can insert the pre-write log record into a group flush pre-write log buffer and save all pre-write log records in the group flush pre-write log buffer to a persistent log in the common log. Such a system or similar systems can include means for performing a write conflict check, the means being configured to copy the pre-write log record to one or more follower common logs, the one or more follower common logs being configured to be a backup of the common log.

[0105] The means for performing the write conflict check can extract a pre-write log record from a batch of pre-write log records received from a database engine, the batch of pre-write log records having a log sequence number of one or more transactions between the database engine and a data store. The means for performing the write conflict check can extract another pre-write log record from another batch of pre-write log records received from another database engine of the plurality of database engines, the another batch of pre-write log records having another log sequence number of one or more other transactions between the another database engine and the data store. The means for performing the write conflict check can maintain all operations and commands modifying the internal state of the common log in a command log.

[0106] In addition to the means for performing write conflict checking and the means for sending write-ahead log records to a shared data store, a system or similar system having means for performing write conflict checking on write-ahead log records may further include a plurality of database engines, a data store shared among the plurality of database engines, and one or more follower common logs. Such a system or a similar system may be constructed according to any arrangement of the features for write-write conflict detection for a multi-master shared storage database taught herein.

[0107] Conflict prevention based on global locks results in a large amount of network traffic and blocking, leading to low performance and low throughput. The methods and structures taught herein use WAL records to determine the presence of conflicts. This method eliminates global locks and brings the benefits of optimistic concurrency control to a multi-master shared storage database system. This method can become a key technology for constructing multi-master systems on a large-scale cloud.

[0108] Although the invention has been described with reference to specific features and embodiments of the invention, it is obvious that various modifications and combinations of the invention can be made without departing from the invention. Therefore, the specification and drawings are to be regarded only as an illustration of the invention as defined by the appended claims, and it is contemplated to cover any and all modifications, variations, combinations, or equivalents falling within the scope of the invention.

Claims

1. A computer-implemented method for writing to a data store shared among multiple database engines, characterized in that, The computer-implemented method includes: Using one or more processors to perform a write-write conflict check on the write-ahead log records received from the database engines of the multiple database engines in a common log, wherein the write-write conflict check includes: comparing the log sequence number received from the database engine together with the write-ahead log record with the global log sequence number in a hash table in the common log; When the log sequence number is greater than the global log sequence number, the write-ahead log record passes the write-write conflict check, and then the global log sequence number is updated to be equal to the log sequence number, and the write-ahead log record is sent to the data store shared among the multiple database engines.

2. The computer-implemented method according to claim 1, wherein Performing the comparison includes using a tuple identifier or a page identifier as a key in the hash table, and the key is associated with an entry represented in the form of a master node identifier and a global log sequence number value, and the master node identifier is the identifier of the database engine of the multiple database engines.

3. The computer-implemented method according to claim 1, wherein It further includes: After passing the write-write conflict check, Inserting the write-ahead log record into a group flush write-ahead log buffer; Saving all the write-ahead log records in the group flush write-ahead log buffer to a persistent log in the common log.

4. The computer-implemented method according to claim 1, wherein It further includes: Copying the write-ahead log record to one or more follower common logs, and the one or more follower common logs are constructed as a backup of the common log.

5. The computer-implemented method according to claim 1, wherein The write-ahead log record received from the database engine is extracted from a batch of write-ahead log records received from the database engine, and the batch of write-ahead log records has the log sequence numbers of one or more transactions between the database engine and the data store.

6. The computer-implemented method according to claim 5, wherein It further includes: Extracting another write-ahead log record from another batch of write-ahead log records received from another database engine of the multiple database engines, and the another batch of write-ahead log records has another log sequence number of one or more other transactions between the another database engine and the data store.

7. The computer-implemented method according to claim 1, wherein It further includes maintaining all operations and commands that modify the internal state of the common log in a command log.

8. A non-transitory computer-readable medium storing computer instructions, characterized in that, When the computer instructions are executed by one or more processors, the one or more processors execute the steps according to any one of claims 1 to 7.

9. A system, characterized in that, It includes: A memory including instructions; One or more processors communicating with the memory, wherein the one or more processors execute the instructions to: In a common log, perform a write-write conflict check on the write-ahead log records received from the database engines of the multiple database engines, wherein the write-write conflict check includes: comparing the log sequence number received from the database engine together with the write-ahead log record with the global log sequence number in a hash table in the common log; When the log sequence number is greater than the global log sequence number, the write-ahead log record passes the write-write conflict check, and then the global log sequence number is updated to be equal to the log sequence number, and the write-ahead log record is sent to the data store shared among the multiple database engines.

10. The system according to claim 9, wherein The comparison includes using a tuple identifier or a page identifier as a key in the hash table, the key being associated with an entry represented in the form of a master node identifier and a global log sequence number value, the master node identifier being an identifier of a database engine of the plurality of database engines.

11. The system according to claim 9, wherein After performing the write-write conflict check, the one or more processors perform: Insert the write-ahead log record into a group flush write-ahead log buffer; An operation of saving all the write-ahead log records in the group flush write-ahead log buffer to a persistent log in the common log.

12. The system according to claim 9, wherein The one or more processors copy the write-ahead log record to one or more follower common logs, the one or more follower common logs being constructed as a backup of the common log.

13. The system according to claim 9, wherein The one or more processors extract the write-ahead log record from a batch of write-ahead log records, the batch of write-ahead log records being received from the database engine and having a log sequence number of one or more transactions between the database engine and the data store.

14. The system according to claim 13, wherein, The one or more processors extract another write-ahead log record from another batch of write-ahead log records, the another batch of write-ahead log records being received from another database engine of the plurality of database engines and having another log sequence number of one or more other transactions between the another database engine and the data store.

15. The system according to claim 9, wherein The one or more processors maintain all operations and commands that modify the internal state of the common log in a command log.

16. The system according to claim 9, characterized in that, The system includes the plurality of database engines, a data store shared between the plurality of database engines, and one or more follower common logs in addition to the common log.

17. A system, characterized in that, Comprising: Means for performing a write conflict check on write-ahead log records received from a database engine of a plurality of database engines, wherein the write conflict check includes comparing a log sequence number received from the database engine together with the write-ahead log record with a global log sequence number in a hash table in a common log, wherein the means for performing the write conflict check includes the common log and is operably arranged between the plurality of database engines and a shared data store, the shared data store being shared between the plurality of database engines; Means for, when the log sequence number is greater than the global log sequence number and the write-ahead log record passes the write conflict check, updating the global log sequence number to be equal to the log sequence number and sending the write-ahead log record to the shared data store.

18. The system according to claim 17, wherein The comparison includes using a tuple identifier or a page identifier as a key in the hash table, the key being associated with an entry represented in the form of a master node identifier and a global log sequence number value, the master node identifier being an identifier of a database engine of the plurality of database engines.

19. The system according to claim 17, wherein After performing the write conflict check, the means for performing the write conflict check performs: Insert the write-ahead log record into a group flush write-ahead log buffer; An operation of saving all the write-ahead log records in the group flush write-ahead log buffer to a persistent log in the common log.

20. The system according to claim 17, wherein The apparatus for performing the write conflict check copies the write-ahead log record to one or more follower public logs, and the one or more follower public logs are constructed as a backup of the public log.

21. The system according to claim 17, wherein The apparatus for performing the write conflict check extracts the write-ahead log record from a batch of write-ahead log records, the batch of write-ahead log records being received from the database engine and having the log sequence numbers of one or more transactions between the database engine and the data store.

22. The system according to claim 21, wherein The apparatus for performing the write conflict check extracts another write-ahead log record from another batch of write-ahead log records, the another batch of write-ahead log records being received from another database engine of the plurality of database engines and having another log sequence number of one or more other transactions between the another database engine and the data store.

23. The system according to claim 17, wherein The apparatus for performing the write conflict check maintains in the command log all operations and commands that modify the internal state of the public log.

24. The system according to claim 17, wherein In addition to the apparatus for performing the write conflict check and the apparatus for sending the write-ahead log record to the shared data store, the system further includes the plurality of database engines, the data store shared among the plurality of database engines, and one or more follower public logs.

Images