JP2006012142A - Checkpoint method and system utilizing non-disk persistent memory - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a system and method for reducing time required for transaction commitment. <P>SOLUTION: Transaction processing systems 800 comprise a database writer 802 constituted so as to process data according to one or more transactions in the transaction processing systems, a transaction monitor 804 which monitors the transaction in the transaction processing systems, a log writer 802 which holds transaction audit trail data relevant to the transactions in the transaction processing system and one or more non-disk persistent memory units 812, 814 that are used to checkpoint. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a transaction processing system.

(Related application)
This application is a continuation-in-part of US patent application Ser. No. 10 / 797,258, filed Mar. 9, 2004, which is incorporated herein by reference, and claims its priority.
This application is also related to US patent application Ser. Nos. 10 / 351,194 and 10 / 737,374.

A transaction processing system is a computer hardware and software system that supports the parallel execution of multiple transaction programs while ensuring the maintenance of so-called ACID characteristics including atomicity, consistency, isolation, and durability.
A transaction program is a specification of operations that are applied to an application state, including the order in which operations must be applied to correctly execute a transaction and any concurrency control that must be performed.
The most common concurrency control operation is locking, and the process corresponding to the transaction program acquires a shared lock or an exclusive lock for data to be read or written.
A transaction usually refers to a collection of actions on the state of physical and abstract applications represented in a database.
A transaction represents the execution of a transaction program.
The operation includes reading and writing the shared state.

With respect to the ACID property, atomicity refers to a transaction that exhibits all or nothing behavior in that the transaction is either executed completely or not executed at all.
A completed transaction can be said to be committed, an abandoned during execution can be said to have been aborted, and an execution that has started but not committed or aborted can be said to be in flight.

  Consistency refers to the successful completion of a transaction that keeps the application state in a state consistent with any specified integrity constraints.

Isolation, also known as serializability, ensures that correctly executing all transaction streams in parallel is consistent with executing each transaction that makes up the stream in some overall order.
In this sense, for an executed transaction, the effect of any other transaction in the stream is the same if it is executed completely before this transaction, or if it is executed completely later. .
Strong serializability refers to the extent to which concurrent execution of transactions is constrained and creates different isolation levels in a transaction processing system.
Within the context of the present specification, the highest priority is given to transaction processing systems that exhibit the strongest form of isolation in which updates made by a transaction are never lost and the result of a re-read operation within the transaction is the same.

  Durability refers to the property that once a transaction is committed, its changes to the application state can survive failures that affect the transaction processing system.

One problem with transaction processing systems relates to reducing the time required to commit a transaction.
Accordingly, the present invention stems from the problems associated with providing a system and method that reduces the time required to commit a transaction.

(Overview)
Various embodiments described herein utilize non-disk persistent memory in conjunction with a transaction processing system.
Using non-disk persistent memory for transaction commits can reduce the time associated with transaction commits, thus reducing the demand for resources in the transaction processing system and increasing transaction processing throughput. be able to.
Various embodiments provide a unified buffering scheme that utilizes non-disk persistent memory for both the checkpointing process and the write-aside buffering process.

(Exemplary general transaction processing system)
FIG. 1 illustrates an exemplary transaction processing system 100 in which components can be utilized to implement the principles of the invention described herein.
In the described embodiment, the transaction processing system 100 includes a database writer 102, a transaction monitor 104, and a log writer 106.

The database writer 102 is configured to mutate data stored in a data volume (ie, a disk or collection of disks) when performing operations specified by a transaction program.
How to maintain ACID characteristics other than durability has little to do with the discussion herein.

For durability, the database writer ensures that changes made to the database are recorded on the durable medium.
In online transaction processing, data affected by such changes tends to be randomly distributed across each data volume.
Because random access to multiple disk drives is quite inefficient, these changes are not immediately written to disk.
Rather than immediately, the database writer 102 sends each change to the log writer 106 described below, thereby making the change durable in time for the transaction commit.

Transaction monitor 104 tracks transactions as they enter and leave the system.
The transaction monitor tracks the database writer 102 that receives the transaction and mutates the database, and any data volume changes associated with that transaction sent by the database writer 102 to the log writer 106 are permanent before the transaction is committed. Ensure that it is flushed to the media.
Transaction monitor 104 also writes down the state of the transaction (eg, commit or abort) in the transaction log.

The log writer 106 maintains a database audit trail that explicitly records the changes made to the database by each transaction and implicitly records the sequential order in which the transactions are committed.
Again, paying attention to the durability characteristics, changes made by the transaction must be recorded on the durable medium before the transaction can be committed.
The log writer 106 enforces this restriction, receives an audit record describing the state change from the database writer 102, and coordinates the recording operation with the remaining transaction commitment infrastructure described below.

As will be appreciated by those skilled in the art, one or more of the above entities can be implemented using multiple processes or threads for purposes of scalability or fault tolerance.
For example, a database may be divided into multiple disk “volumes” each managed by one or more database writer entities.
Similarly, the task of writing audit trails can also be divided into dedicated log writers, each recording changes made by a particular subset of database writers.
To ensure continuous operation of the transaction processing system, each database writer will “take over” the surviving entities from the set without disturbing the processing of the transaction stream should one entity in the set fail. It can also be implemented using a set of two or more redundant entities whose states are always synchronized.

  FIG. 2 illustrates an overall implementation of the transaction processing system of FIG. 1 at 200 and includes a database writer 202, transaction monitor 204, and log writer 206.

In this example, each of the entities described above is implemented using a pair of processes.
Thus, each process pair includes a primary process (denoted “pri”) and a backup process (denoted “bak”).
In this example, before communicating with any other component of the transaction processing system, each primary process checkpoints the relevant part of its state to the backup process, and if the primary process fails, the backup process Can take over.
The takeover interval is fairly short (lasting from a few milliseconds to a few seconds), during which time the in-flight transaction is aborted and possibly started again.
The processes and libraries that implement each element of the transaction processing architecture in FIG. 2 can be distributed over multiple CPUs.

In this example, the database writer 202 is described as “DP2” (“disk process 2”), and the log writer 206 is described as “ADP” (“audit disk process”).
Transaction monitor 204 is implemented using a collection of distributed process and system libraries called TMF (“Transaction Monitoring Function”).
Transaction monitor 204 is labeled “TMP” (“transaction monitor process”) and coordinates the start and commit of transactions.
TMF uses an operating system function called TMFlib (TMF library) in each CPU in the cluster.
This library allows the DP2 process to register with the TMF when starting and ending each work for any given transaction.
The TMFlib instance communicates between the instances and communicates with the TMP process pair to coordinate transaction commitments as described below in the section titled “Transaction Commit”.

(Commit transaction)
With reference to FIG. 2, the following describes exemplary steps involved in transaction commit when a single log volume (or audit trail disk volume) 208 is present in the transaction processing system.
Typically, the client 210 faces a Begin_Transaction or similar action that indicates the start of a transaction.
The TMFlib on the CPU executing the client process assigns a transaction ID (TID) to the new transaction.
The TID is then propagated to the database writer 202, and in particular to all disk processes DP2 that work in response to the transaction.
In the simple case shown in FIG. 2, only a single database writer (including a pair of DP2 processes) is involved.
In the more general case, multiple DP2 process pairs may be involved in processing a transaction.

When the database writer 202 changes the state of the database, the primary DP2 process 210 first checkpoints the state change to the backup process 212 and then propagates a record of the state change to the log writer 206, particularly the ADP primary process 218.
The ADP primary process is forced to commit (so-called forced write) until the threshold for the amount of buffering audit data is exceeded (becomes so-called courtesy write) or by a message from the transaction monitor process (TMP) 204. If so, buffer state changes in memory sooner.
Just like DP2, ADP primary process 218 also checkpoints state changes to backup process 220 before issuing any disk operations or messages.

At the next moment, the client then encounters End_Transaction or similar action indicating the end of a particular transaction.
Prior to committing a transaction, the transaction monitor process 204 needs to ensure that the database state changes sent to the log writer 206 in response to the transaction are durable, as described above.
To accomplish this, TMP sends a two-phase flush message for that particular transaction to each log writer or ADP in the system, and then from each ADP, the requested state change is written from the non-durable system buffer to the disk drive. Wait for a reply to confirm.
When the transaction monitor 204 receives all reply messages, it sends a transaction commit record to the specifically designated master ADP.
If the master ADP approves that the commit record has been written to the durable medium, the TMP notifies the client that the transaction has been committed.

From the above, it is clear that waiting for state changes and commit records to be flushed to disk accounts for the majority of the delay in committing a TMF transaction, as will be appreciated by those skilled in the art.
Further, checkpointing by the database writer, transaction monitor, and log writer increases the overhead of committing the transaction.
Because the disk is a rotating mechanical medium, disk latency has not improved as quickly as processor and memory speeds.
Furthermore, reliable checkpointing via message passing involves not only data transfer overhead but also the overhead of fully synchronizing a pair of processes.
Due to these factors, the TMF transaction commit time often ranges from several milliseconds to several seconds.

Some applications can withstand slow response times, but many applications cannot withstand slow response times.
If the TMF transaction response time is slow, the average transaction stays longer in the system, which in turn increases the demand for resources in the transaction processing system, which indirectly limits transaction processing throughput under finite resources. This has a secondary adverse effect on transaction processing throughput.
Examples of resources that can exceed capacity if a transaction stays in the system for a long time include database locks, sockets, and other connection resources.

(Permanent memory in general)
According to the embodiments described herein, non-disk persistent memory is employed in conjunction with a transaction processing system to generally reduce transaction response time, particularly transaction commit time and process vs. checkpointing time.
In the various embodiments described below, non-disk persistent memory can be used as both a write-aside buffer for disk writes and a buffer for process status checkpoints.

Persistent memory is a structural concept understood by those skilled in the art.
According to the described embodiment, there are many possible implementations of available non-disk persistent memory.
Thus, the limitation of a non-disk persistent memory to a particular embodiment is not intended herein.

In order to assist readers in understanding the structural principles associated with non-disk persistent memory, in the discussion that follows, non-disk persistent memory systems are used to facilitate the use of non-disk persistent memory systems in the transaction processing system of the present invention. The features that can be possessed are described.
Throughout this discussion, a few non-limiting examples of non-disk persistent memory systems are provided.
It should be appreciated and understood that the principles described herein may be employed in other non-disk persistent memory structures without departing from the spirit and scope of the claimed subject matter.

  A non-disk persistent memory as defined herein should exhibit the following characteristics: durability, connectivity, and access.

Durability refers to non-disk persistent memory that is durable without refreshing and can survive a system power loss.
In addition, durable self-consistent metadata should be provided to ensure continuous access to data stored in non-disk persistent memory after power loss or after a soft failure .

Consider the following regarding connectivity.
Non-disk persistent memory can be connected to available memory controllers using commercially available chipsets.
Dedicated memory controllers can ultimately be designed to take advantage of the durability of non-disk persistent memory uniquely, but they need not be present.
The first level I of non-disk persistent memory, if direct connectivity to the memory controller of the CPU is not desirable, possibly due to fault tolerance, packaging issues, physical slot constraints, or electrical load limits. / O is allowed.
For example, non-disk persistent memory can be attached to PCI and other first level I / O interconnects such as PCI Express, RDMA over IP, InfiniBand, Virtual Interface over Fiber Channel (FC-VI) or ServerNet.
Such interconnects support both memory mapping and memory semantic access.
This embodiment of non-disk persistent memory is called a communication link connected persistent memory unit (CPMU).

  Storage device connectivity (e.g., SCSI) or indeed any other second level I / O connectivity is not desirable for persistent memory due to the performance considerations set forth below.

Regarding access, consider the following.
Non-disk persistent memory, particularly at specified process virtual addresses, can be accessed from a user program like normal virtual memory using CPU memory instructions (Load and Store).
In certain system area networks (ie, SANs) that support memory semantic operations, non-disk persistent memory can be implemented as network resources that are accessed using remote DMA (RDMA) or similar semantics.
For example, FIG. 3 uses network attached non-disk persistent memory that includes a communication link attached non-disk persistent memory unit (CPMU) 310 that is accessible by one or more processor nodes 302 through an RDMA-enabled system area network (SAN) 306. System 300 is shown.
To access the CPMU 310 non-disk persistent memory, software running on the processor node 302 initiates a remote read or write operation through the processor node's network interface (NI) 304.
In this way, a read command or a write command is carried to the CPMU network interface (NI) 308 via the RDMA capable SAN 306.
Thus, after processing, the appropriate data is communicated via the RDMA enabled SAN 306.

In addition to RDMA data movement operations, CPMU 310 can be configured to respond to various management commands.
For example, in a write operation initiated by the processor node 302, once the data is successfully stored in the CPMU, the data becomes durable and will survive a power outage or failure of the processor node 302.
In particular, the memory contents are retained even after the power supply is disconnected for a long period of time or after the operating system on processor node 302 is rebooted, as long as CPMU continues to function properly.
In this example, processor node 302 is a computer system consisting of at least one central processing unit (CPU) and memory, and the CPU is configured to execute an operating system.
The processor node 302 is further configured to execute application software such as a database.
Processor node 302 uses SAN 306 to communicate with other processor nodes 302 and devices such as CPMU 310 and I / O controller (not shown).

In one implementation of this example, the RDMA enabled SAN may notify the CPU of the target processor node 302 between the initiator processor node 302 and the target processor node 302 or between the initiator processor node 302 and the device 310 without A network capable of executing memory operations such as copy operations at the byte level.
In this case, the SAN 306 is configured to perform translation from virtual addresses to physical addresses and to allow mapping from a continuous network virtual address space to a discontinuous physical address space.
This type of address translation allows dynamic management of the CPMU 310.
Commercially available SANs 306 with RDMA capabilities include, but are not limited to, ServerNet, RDMA over IP, InfiniBand, and all SANs compliant with virtual interface architecture.

The processor node 302 is typically connected to the SAN 306 through the NI 304, but many variations are possible.
More generally, however, the processor node only needs to be connected to a device that communicates read and write operations.
For example, in another implementation of this example, the processor node 302 is a variety of CPUs on the motherboard, and instead of using a SAN, an input / output bus, such as a PCI bus, is used.
It should be noted that the present teachings can be scaled up or down as needed to accommodate larger or smaller implementations.

A network interface (NI) 308 is communicatively coupled to the CPMU 310 to allow access to non-disk persistent memory contained within the CPMU 310.
A number of technologies can be used for the various components in FIG. 3, including the type of memory technology used within CPMU 310.
Accordingly, the embodiment of FIG. 3 as well as the other embodiments described herein are not limited to a particular technique for implementing non-disk persistent memory.
Actually, various magnetic random access memory (MRAM), magnetoresistive random access memory (MRRAM), polymer ferroelectric random access memory (PFRAM), OUM (Ovonics unified memory), battery backup dynamic random access memory (BBDRAM) Many memory technologies are suitable, including flash memory.

If SAN 306 is used, the memory should be fast enough for RDMA access.
In this way, RDMA read and write operations are enabled via the SAN 306.
If another type of communication device is used, the access speed of the memory used should also be fast enough to accommodate the communication device.
Note that persistent information is provided to the extent that the non-disk persistent memory in use can hold the data.
For example, in many applications non-disk persistent memory may be required to store data regardless of the amount of time that power is lost, while in other applications it may store data for minutes or hours. Sometimes it's fine.

In conjunction with this approach, a memory management function is provided that creates a single or multiple independent and indirectly addressed memory regions.
In addition, CPMU metadata is provided to restore memory after power is lost or a processor fails.
The metadata or information includes, for example, the contents and layout of the protected memory area in CPMU.
In this way, CPMU stores data and data usage.
When a need arises, the CPMU enables recovery from a power supply or system failure.

In FIG. 4, CPMU 400 comprises a non-disk non-volatile memory 402 and a network interface or NI 404 coupled together via a data communication link such as a bus.
Here, the non-disk nonvolatile memory 402 can be, for example, MRAM or flash memory.
The NI 404 does not initiate an RDMA request by itself, but instead receives a management command from the network and performs the requested management operation.
Specifically, CPMU 400 translates the address on each input memory access request and then initiates the requested memory operation internally via the data communication link between NI 404 and non-volatile memory 402.

In FIG. 5, another embodiment of CPMU 500 uses a combination of non-disk volatile memory 502 with battery 510 and non-volatile auxiliary storage 508.
In this embodiment, when the power is turned off, the data in the non-disk volatile memory 502 is retained using the power source of the battery 510 until such data can be stored in the non-volatile auxiliary storage device 508.
The non-volatile auxiliary storage device can be, for example, a magnetic disk or a low-speed flash memory.
In order for CPMU 500 to operate properly, the transfer of data from volatile memory 502 to non-volatile auxiliary memory storage device 508 should occur without the need for any additional power sources other than external intervention or power from battery 510. It is.
Thus, any requested task should be completed before the battery 510 runs out.
As shown, CPMU 500 includes an optional CPU 504 that runs an embedded operating system.

Thus, the backup task (ie, data transfer from the non-disk volatile memory 502 to the non-volatile auxiliary memory storage device 508) can be performed by software running on the CPU 504.
Software running on the CPU 504 can use the provided NI 506 to initiate RDMA requests or send messages to other entities on the SAN 306.
Again, the CPU 504 receives a management command from the network through the NI 506 and executes the requested management operation.

Any embodiment of CPMU, such as CPMU 400 or 500, must be managed for persistent memory allocation and sharing.
In this example, CPMU management is performed by a persistent memory manager (PMM).
The PMM may be in the CPMU, or may be outside the CPMU, such as one of the processor nodes 302.
When processor node 302 needs to allocate or deallocate non-disk persistent memory in CPMU 310, or when it needs to start or stop using an existing area of non-disk persistent memory, the processor node first begins with the PMM. Communicate and perform the requested administrative tasks.
Since the memory content of CPMU 310 is durable (just like a disk drive), metadata related to non-disk persistent memory areas within that CPMU is also durable and consistent with these areas. Note that it must be stored in the CPMU itself (just like the file system metadata on the disk drive).
Therefore, the PMM must perform administrative tasks to always keep the CPMU 310 metadata consistent with the contents of the non-disk persistent memory.
Thus, data stored in CPMU 310 may be stored even after a possible power loss, system shutdown, or other failure affecting one or more of PMM, CPMU 310, and processor node 302. It is possible to search meaningfully using the metadata that has been created.
When a need for restoration occurs, system 300 using CPMU 310 can thus be restored and resume operation from the memory state where the power failure or operating system crash occurred.

  In a system 300 incapable of directly or indirectly initiating an RDMA data transfer via SAN 306 using processing node 302 Load and Store memory instructions, processing node 302 may read and write the contents of CPMU 310. The application running above needs to initiate RDMA using an application programming interface or API.

As should be apparent, one of the reasons that non-disk persistent memory is attractive is that it provides finer granularity for durable stored data than disk drives (meaning smaller access size). To support read / write operations in
This granularity applies to both access size (number of bytes read or written) and access alignment (offset in the non-disk persistent memory area of the first byte read or written).
Since the data structures in the non-disk persistent memory area can be freely arranged, the capacity can be used more efficiently and effectively than when the disk is used.
Another advantage associated with block-oriented disk storage and flash memory is that when small data is modified and rewritten, there is no need to first read a large block of data first, but instead a write operation makes it simpler. In other words, only the bytes that need to be changed can be changed.
The raw speed of non-disk persistent memory is also attractive.
The access latency is an order of magnitude better than the disk drive access latency.
The relative ease of use of non-disk persistent memory compared to disk drives also means that all pointers need to be first converted to relative byte addresses on write, and then read without relative byte addresses needing to be converted back to original pointers. Is substantial due to the fact that it is possible to store rich data structures in non-disk persistent memory.
The so-called marshalling-unmarshalling overhead can be quite large for complex data structures.
All of the above factors not only allow application programmers to accelerate the access and operation of data structures that have already been made permanent, but also make them persistent in slower storage devices such as disk drives and flash memory. Make it possible to think about making certain data structures that you didn't think about to be persistent.
The higher the degree of permanence in the information processing system, the less loss of information, and the easier and quicker it is to recover from a failure.
Faster restoration implies higher system availability.
Thus, the net benefits of the described embodiments are not just performance, but also increased availability.
In a critical transaction processing system that is costly associated with a lack of system availability, the availability benefits of the described embodiments may actually be of greater value than the performance benefits.
Furthermore, the described embodiments can be used to enable new or improved database functions such as in-memory operations.
Applications other than databases can also take advantage of the improved performance and availability of the system 300 to create new customer functions.
There are too many to list here, but many of these applications will be apparent to those skilled in the art.
One such application is described next.

(Reducing transaction commit time using non-disk persistent memory)
With respect to the transaction processing system 100 of FIG. 1, in the absence of non-disk persistent memory, two things must be done before the transaction monitor 104 can commit a database transaction.
First, the log writer 106 must flush out (ie, completely write) any audit information associated with that transaction received from the database writer 102 to the durable medium.
Thereafter, the transaction monitor 104 must also write a commit record for the transaction on the durable medium.
According to the described embodiment, non-disk persistent memory can be used to allow transactions to be committed after such information items are written only to non-disk persistent memory.
To the extent that non-disk persistent memory exhibits lower latency for write operations than disk storage, transaction latency can be reduced accordingly (and possibly increase TMF transaction throughput).

In one embodiment of transaction processing, persistent memory is used to accelerate transaction commit.
Specifically, in conjunction with FIG. 2, as soon as the primary ADP 218 receives a state change message from DP2 202, it records these state changes synchronously in persistent memory before sending a confirmation message to DP2.
Two-phase flush messages from the TMP 204 can be reduced or eliminated entirely because the ADP 206 is “always flushed”.
Thus, when some inter-process communication steps and disk operations are removed from the transaction commit critical path, TMP 204 will make transactions much faster when ADP 206 uses non-disk persistent memory than when using disk. Can be committed to.
In one experiment conducted by the inventors, it was found that the transaction response time was 3.5 times faster with persistent memory than without persistent memory.

As an example, consider FIG. 6 where the overall transaction processing system according to one embodiment is shown at 600.
The system 600 includes a database writer 602, a transaction monitor 604, and a log writer 606.

According to the described embodiment, the log writer 606 includes a primary audit disk process 608 and a backup disk process 610.
A pair of non-disk persistent memory units is provided, including a primary non-disk persistent memory unit 612 (also referred to as “CPMU”) and a mirrored non-disk persistent memory unit 614 (also referred to as “CPMU”).
The primary audit log disk 616 and the mirror audit disk log 618 are provided for purposes that will become apparent below.

In the illustrated and described embodiment, data is written to both the primary non-disk persistent memory unit 612 and the mirror non-disk persistent memory unit 614.
In some embodiments, data can be written to the primary and mirror units simultaneously.
Alternatively, in some embodiments, it is not necessary to write data to the primary unit and mirror unit simultaneously.
If the system is fully functional, in some embodiments the information is read from the primary non-disk persistent memory unit 612 or the mirrored non-disk persistent memory unit 614.
Should only one of the non-disk persistent memory units (612, 614) fail, data will be read from the surviving non-disk persistent memory unit.
When the failed primary non-disk persistent memory unit is ready to function properly, the contents can be restored from the surviving non-disk persistent memory unit.

In the illustrated and described embodiment, one area for each audit trail is allocated within each non-disk persistent memory unit 612, 614, and the audit disk process pair 608, 610 is assigned a write-aside buffer ("WAB" in each area. ”).
In this example, the write-aside buffer is configured as a circular buffer as understood by those skilled in the art, although any suitable write-aside buffer configuration can be used.
When primary audit disk process 608 receives a set of changes from database writer 602, it uses non-disk persistent memory units 612, 614 to commit these changes very quickly.
Specifically, in the example shown, when the ADP 608 receives a set of changes, it adds the information to the CPMU 612 WAB to the end address of the WAB, and then the last address of the WAB is written most recently. Proceed to point to the end of the information.
The operation is then repeated for the CPMU 614 WAB.
One skilled in the art can change the degree of simultaneity between write operations to CPMUs 612, 614.

According to the described embodiment, if the end of the requested write operation causes the tail pointer to point beyond the head address of the WAB, the write operation to the non-disk persistent memory area is suspended and the WAB is marked full. Is done.
The algorithm for advancing the WAB start and end addresses is, as will be understood by those skilled in the art, both the WAB start and end addresses are stored and updated in the same non-disk persistent memory area containing the WAB circular buffer. Except that it is similar to a typical approach to implementing a circular queue data structure.

When using cost-effective non-disk persistent memory, the slower log I / O is completely removed from the transaction commitment process because the entire log volume is achieved using faster persistent memory devices rather than disks. Can be eliminated.
However, now and in the near future, disk capacity will continue to be much larger than non-disk persistent memory capacity, and the cost per byte of disk storage will continue to be significantly higher than the cost per byte of non-disk persistent memory. It seems to be low.
In that case, a relatively larger capacity disk drive WAB is implemented using a relatively smaller capacity non-disk persistent memory unit.
In such a configuration and in a similar design, the synchronous writing of audit information is asynchronously written to the disk with a delay.
Various techniques for selecting what information to keep in non-disk persistent memory and what information to flush to disk will be apparent to those skilled in the art of memory hierarchy design.
For example, the fuzzy control point system for transaction restore logs information so that in the event of a system crash, all normal restore processes of undoing in-flight transactions and then redoing can be applied from persistent memory. Two “control points” worthy can be kept in persistent memory.

In addition, when using such a cost-constrained non-disk persistent memory technology just described, the ADP 608 can continue to use disk write operations, but prior to doing so, it allows the TMP 604 to commit the transaction. There is no need to wait for the disk operation to complete.
Instead, the ADP 608 writes all audit information received from the database writer 602 to the non-disk persistent memory devices 612, 614 in an ambitious and synchronous manner, but receives a plurality of messages received within an appropriately selected time interval. Exercise the option of combining information from.
Since the disk operation no longer waits for completion as described above, the ADP 608 can now write more data per disk operation, thereby performing the operation performed on the same amount of audit trail data. Therefore, the I / O related overhead generated is small.
As a result, the disk throughput from the audit disks 616 and 618 is improved and the CPU utilization rate of the CPU executing the ADP 608 is improved.
Thus, when the ADP 608 receives an audit trail flush request from the TMP 604, it flushes any pending changes to the WAB in the CPMU 612,614.
ADP 608 also buffers the information so that the information can be written to audit log disks 616, 618 with a so-called delay.
When a predetermined condition is met, for example, when a certain threshold for buffered information is exceeded or the maximum fixed time interval is reached, ADP 608 may write to disk regardless of whether a flush message is received from TMP 604 or not. Issue action.
However, unlike the conventional case, the transaction in the system of the present invention can be committed before the audit information is written to the disks 616 and 618 but after it is written to the CPMU 612 and 614.

When the sequential write operations issued delayed to the audit disks 616, 618 are completed, some of the information stored in the CPMU WAB can be overwritten.
The leading address in the appropriate area of CPMU 612, 614 is then advanced beyond the last byte that was successfully written back.
If a non-disk persistent memory unit is marked “full” before ADP 608 receives completion of disk I / O, the non-disk persistent memory unit is marked “not full”.
The ADP 608 can then resume using WAB once again.
Whenever ADP 608 suspends the use of WAB, it returns to waiting for outstanding disk I / O to log volumes 616, 618 before committing the transaction.
In such situations, the size of the write I / O operation is usually more than the value that results in optimal disk throughput (eg, 128 KB to 1 MB) to limit the impact of disk I / O latency on transaction response time. Set to a small value (eg, 4 KB to 128 KB depending on the amount of audit collected between commit records).
When using non-disk persistent memory, ADP 608 can wait until more audit data is buffered for writing because transactions do not wait for disk I / O to complete.
Thus, a larger disk write I / O size (eg, 512 KB) can be used to obtain near optimal throughput for log volumes 616, 618 and disk I / O overhead for the CPU executing ADP 608. Can be greatly reduced.

  With the same amount of design changes, a write-aside buffer can be created that uses non-disk persistent memory for any other application whose performance is adversely affected by waiting for a disk write operation.

Other variations to the design will be apparent to those skilled in the art.
For example, rather than alternately writing sequentially to the primary non-disk and mirror non-disk persistent memory units, the application can choose to write simultaneously.

(Example method)
FIG. 7 illustrates steps in a method according to one embodiment.
In the illustrated and described embodiment, the method can be implemented in any suitable hardware, software, firmware, or combination thereof.
Further, the method can be implemented using any suitably configured non-disk persistent memory structure.
Specific, non-limiting examples of non-disk persistent memory structures are shown and described throughout this specification.

Step 700 receives data related to a state change induced by a transaction.
Such data can describe database state changes resulting from transactions.
In the illustrated and described embodiment, this data is received from a database writer component such as those described above.
Step 702 writes the data to non-disk persistent memory.
As noted, any suitable non-disk persistent memory structure can be utilized.
For example, in the example of FIG. 6, a primary non-disk persistent memory unit and a mirror non-disk persistent memory unit are utilized.
Step 704 checks to see if a non-disk persistent memory unit threshold has been reached.
If not, the method returns to step 700.
On the other hand, if the non-disk persistent memory unit threshold is reached, step 706 writes the data in the non-disk persistent memory to an audit log disk such as the audit log disk 616 in FIG.
In the example of FIG. 6, it is mentioned that writing the audit log in this way is performed with a delay.

(Use of non-disk persistent memory for log writer checkpointing)
Consider now FIG. 8 which shows the entire transaction processing system at 800 according to one embodiment.
The system 800 includes a database writer 802, a transaction monitor 804, and a log writer 806.
According to at least one embodiment, the system 800 can be utilized in a transaction commit process as described immediately above.
Further, the system 800 can be used for log writer checkpointing as described below.
In this example, the components of system 800 are the same as or similar to the components of FIG.
Therefore, for the sake of brevity, these components will not be described again here.

In the system of FIG. 8, the database writer 802 sends audit records or status changes to the log writer 806.
The log writer 806 receives the audit record, writes it to the permanent memory 812, 814, and buffers the audit data in the memory.
Here, at the time of commit, the transaction monitor 804 indicates to the log writer 806 that the transaction should be committed.
Accordingly, the log writer 806 receives the commit record, writes it to the permanent memory 812, 814, and buffers it in the memory.
The final step in the process of committing a transaction using system 800 is that log writer 806 writes the audit records and commit records “delayed” to audit log disks 816, 818.
In this example, the write operation by the log writer 806 is referred to as “delay” because it is performed asynchronously with the commit process.
In this embodiment, the ADP backup process 810 only needs to read the persistent memory if the ADP primary process fails (indicated by a dotted line from the ADP backup process to the persistent memory 812, 814). .

In this particular example, the same persistent memory unit employed as the write-aside buffer is also employed for log writer checkpointing.
Thus, the exact same circular buffer in persistent memory can be used for both purposes.
Furthermore, an advantage is obtained in that the ADP backup process does not have to read persistent memory checkpoint information until the ADP primary process fails.

As will be appreciated by those skilled in the art, this approach reduces processing overhead as well as data copy.
Specifically, conventionally, to checkpoint to the ADP backup process, it was necessary to send a message to the ADP backup process along with a state change, after which such changes were written to the audit disk logs 816, 818.
For the above approach, the ADP backup process is taken from the checkpointing group, thereby reducing processing overhead.

(Use of non-disk persistent memory for all checkpointing)
According to one embodiment, non-disk persistent memory can be used for transaction commit as described above, and can be used for both database writer checkpointing and log writer checkpointing.
In this approach, the transaction commit process is simplified by eliminating two steps in the data flow, each step that checkpoints into the DP2 backup process and the ADP backup process, respectively.

As an example, consider FIG. 9 where the entire transaction processing system according to one embodiment is shown at 900.
The system 900 includes a database writer 902, a transaction monitor 904, and a log writer 906.
In this example, the components of system 900 are the same as or similar to the components of FIG.
Therefore, for the sake of brevity, these components will not be described again here.

In this embodiment, rather than the database writer sending audit information or state changes to the log writer 906, the audit information or state changes are written to persistent memory 912, 914.
This virtually eliminates checkpointing audit information into the DP2 backup process.
Thus, the DP2 backup process (not specifically shown) only needs to read this information from permanent memory if the DP2 primary process fails.

Subsequently, as audit information is written to persistent memory 912, 914, log writer 906 can read the audit information and buffer it in memory in preparation for committing the information to disk.
When this process phase is complete, the transaction monitor 904 can begin the next phase of the commit process that causes the information to be committed to disk.
For this purpose, the transaction monitor writes the commit record to the persistent memories 912, 914, and the log writer 906 reads the commit record from the persistent memories 912, 914, buffers it in the memory, and writes it to the disk.
Advantageously, each backup process of the database writer (DP2) and log writer (ADP) only needs to read the persistent memory 912, 914 if the respective primary process fails.

According to this embodiment, the log writer 906 can now write audit information and commit records to the disk asynchronously and delayed.
This process effectively decouples the log writer from the commit process.

Advantageously, by using persistent memory for the checkpointing process as well as the transaction commitment process as described above in connection with FIG. 6, the data associated with the transaction can be made much more permanent than before. it can.
Thus, the update is durable when the record is written to persistent memory, and the transaction commit process is much faster because the commit process does not have to wait for any other steps to complete.

(Exemplary computer system)
In one embodiment, the system can be implemented in a computer system 1000 such as that shown in FIG.
The computer system 1000, or various combinations of components that make up the computer system 1000, can be utilized to implement the above system including processor nodes as well as various non-disk persistent memory units.

With reference to FIG. 10, an exemplary computer system 1000 (eg, personal computer, workstation, mainframe, etc.) is configured with a data bus 1014 that communicatively couples various components.
As shown in FIG. 10, processor 1002 is coupled to bus 1014 for processing information and instructions.
Computer readable volatile memory, such as RAM 1004, is also coupled to bus 1014 and stores information and instructions for processor 1002.
In addition, a computer readable read only memory (ROM) 1006 is also coupled to the bus 1014 and stores static information and instructions for the processor 1002.
A data storage device 1008 such as a magnetic disk medium or optical disk medium is also coupled to the bus 1014.
Data storage device 1008 is used to store large amounts of information and instructions.
An alphanumeric input device 1010 with alphanumeric and function keys is coupled to bus 1014 and communicates information and command selections to processor 1002.
A cursor control device 1012 such as a mouse is coupled to the bus 1014 and communicates user input information and command selections to the central processor 1002.
An input / output communication port 1016 is coupled to the bus 1014 and communicates with, for example, a network, other computers, or other processors.
A display 1018 is coupled to the bus 1014 and displays information to the computer user.
Display device 1018 can be a liquid crystal device, a cathode ray tube, or other display device suitable for creating graphic images and alphanumeric characters that can be recognized by the user.
Alphanumeric input 1010 and cursor control device 1012 allow a computer user to dynamically notify the two-dimensional movement of a visible symbol (pointer) on display 1018.
A non-disk persistent memory unit 1020 is provided, and the non-disk persistent memory unit 1020 may comprise any of the above embodiments, as will be understood by those skilled in the art, and other non-disk persistent memory structures exhibiting the above behavior. May be provided.

(Conclusion)
The various embodiments described above utilize non-disk persistent memory in conjunction with a transaction processing system.
By committing the transaction using non-disk persistent memory, the time associated with committing the transaction can be reduced.
Therefore, the demand for resources within the transaction processing system can be reduced, thereby improving the throughput of the transaction processing system.

Although the invention has been described in language specific to structural features and / or method steps, the invention as defined in the appended claims is not necessarily limited to the specific features or steps described. I want you to understand.
Rather, the specific features and steps are disclosed as preferred forms of implementing the claimed invention.

1 illustrates an example transaction processing system in which components may be utilized in conjunction with one or more embodiments. 2 illustrates one embodiment of the transaction processing system of FIG. 3 illustrates an exemplary embodiment of a non-disk persistent memory unit. 3 illustrates an exemplary embodiment of a non-disk persistent memory unit. 4 illustrates another exemplary embodiment of a non-disk persistent memory unit. 1 illustrates an exemplary transaction processing system that utilizes a non-disk persistent memory unit in accordance with one or more embodiments. 3 is a flow diagram that describes steps in a method in accordance with one embodiment. 1 illustrates an exemplary transaction processing system that utilizes a non-disk persistent memory unit in accordance with one or more embodiments. 1 illustrates an exemplary transaction processing system that utilizes a non-disk persistent memory unit in accordance with one or more embodiments. 1 illustrates an example computer system that can be utilized in one or more of the embodiments described herein.

Explanation of symbols

100 ... Transaction processing system,
102 ... Database writer,
104 ... Transaction monitor,
106: Log writer,
202 ... Database writer,
204 ... Transaction monitor,
206: Log writer,
208: Audit log disk,
210 ... Client,
222 ... database disk,
302 ... Processor node,
306 ... RDMA compatible system area network (SAN),
310 ... Communication link connection permanent memory unit (CPMU),
400... Communication link connection permanent memory unit,
402... Non-volatile memory,
500... Communication link connection permanent memory unit,
502 ... volatile memory,
508... Non-volatile auxiliary storage device,
510... Battery
600 ... transaction processing system,
602: Database writer,
604 ... Transaction monitor,
606: Log writer,
608 ... Audit disk process (primary),
610: Audit disk process (backup),
612, 614 ... persistent memory,
616, 618 ... Audit log disk,
800 ... transaction processing system,
802 ... Database writer,
804 ... Transaction monitor,
806: Log writer,
808: Audit disk process (primary),
810: Audit disk process (backup),
812, 814 ... persistent memory,
816, 818 ... audit log disk,
900 ... transaction processing system,
902: Database writer,
904 ... Transaction monitor,
906: Log writer,
912, 914 ... persistent memory,
1002... Processor,
1008 ... Data storage device,
1010 ... Alphanumeric input device,
1012 ... Cursor control device,
1016: Communication port,
1018 ... display,
1020... Non-disk persistent memory unit,

Claims (10)

A transaction processing system (800) comprising:
A database writer (802) configured to process data in accordance with one or more transactions in the transaction processing system;
A transaction monitor (804) for monitoring transactions in the transaction processing system;
A log writer (802) for holding audit trail data relating to transactions in the transaction processing system;
One or more non-disk persistent memory units (812, 814), and
A transaction processing system configured to use the one or more non-disk persistent memory units (812, 814) for checkpointing. The one or more non-disk persistent memory units are:
Primary non-disk persistent memory unit (812) and mirrored non-disk persistent memory unit (814)
The transaction processing system according to claim 1. The transaction processing system of claim 1, wherein the log writer (806) is configured to use the one or more non-disk persistent memory units (812, 814) for checkpointing. The transaction processing system of claim 1, wherein the log writer (906) and the database writer (902) are configured to use the one or more non-disk persistent memory units for checkpointing. The one or more non-disk persistent memory units (812, 814) are:
Including a write-aside buffer configured as a circular buffer,
The transaction processing system of claim 1, wherein the log writer (906) and the database writer (902) are configured to use the circular buffer for checkpointing. Receiving data related to a state change induced by the transaction (700);
Performing a checkpoint by writing the received data to a non-disk persistent memory (702). The computer-implemented method of claim 6, wherein performing the checkpoint is performed by a log writer. The computer-implemented method of claim 6, wherein performing the checkpoint is performed by a database writer. The computer-implemented method of claim 6, wherein performing the checkpoint is performed by at least a log writer and a database writer. Performing the checkpoint is
Writing the received data to first and second non-disk persistent memory units;
The first non-disk persistent memory unit is:
Including a primary non-disk persistent memory unit,
The second non-disk persistent memory unit is
The computer-implemented method of claim 6, comprising a mirror non-disk persistent memory unit.

Images