JP4604032B2 - One-stage commit in non-shared database system - Google Patents

Description

FIELD OF THE INVENTION This invention relates to techniques for managing data in a non-shared database system that runs on shared disk hardware.

BACKGROUND OF THE INVENTION Multiprocessing computer systems are generally classified into three categories: all shared systems, shared disk systems, and non-shared systems. In all shared systems, processes on all processors are connected to all volatile memory devices in the system (hereinafter collectively referred to as “memory”) and all non-volatile memory devices (hereinafter collectively referred to as “disks”). Have direct access to. Thus, advanced wiring is required between the various components of the computer to provide fully shared functionality. In addition, all shared architectures have scalability limitations.

  In a shared disk system, processors and memory are grouped into nodes. Each node in the shared disk system may itself constitute an entire shared system including multiple processors and multiple memories. Processes on all processors can access all disks in the system, but only processes on processors that belong to a particular node can directly access memory in a particular node. A shared disk system generally requires less wiring than a full shared system. Shared disk systems are also easily adapted to unbalanced workloads. This is because all nodes can access all data. However, shared disk systems are susceptible to coherence overhead. For example, if a first node changes data and the second node wants to read or change that same data, various to ensure that the correct version of that data is provided to the second node It may be necessary to perform various steps.

  In a non-shared system, all processors, memory, and disks are grouped into nodes. In the non-shared system, like the shared disk system, each node itself can constitute an entire shared system or a shared disk system. Only processes running on a particular node can directly access memory and disk in the particular node. Of the three general types of multiprocessing systems, the amount of wiring required between the various system components is generally the least in non-shared systems. However, non-shared systems are most susceptible to imbalanced workloads. For example, all data to be accessed during a particular task may reside on a particular node's disk. Therefore, only processes running within a node can be used to perform fine-grained work, even though processes on other nodes are idle.

  Databases running on multi-node systems are generally classified into two categories: shared disk databases and non-shared databases.

Shared Disk Database The shared disk database coordinates work based on the assumption that all data managed by the database system is visible to all processing nodes available to the database system. As a result, in a shared disk database, the server can assign any work to a process on any node, regardless of the location of the disk containing the data that will be accessed during the work.

  Since all nodes have access to the same data and each node has its own dedicated cache, multiple versions of the same data item can be cached for any number of nodes in many nodes. It can also exist within. Unfortunately, this means that when one node requests a particular version of a particular data item, that node works with the other nodes to make the requesting node a particular version of that data item. Means that it must be forwarded. Thus, the shared disk database is said to operate on the concept of “data transfer” and the data must be transferred to the node assigned to do the work on that data.

  Such a data transfer request may result in a “ping”. Specifically, ping occurs when a copy of a data item required by one node exists in the cache of another node. Ping may require data items to be read from the disk after being written to the disk. The performance of the disk operation required by ping can significantly reduce the performance of the database system.

  The shared disk database can be run on both non-shared computer systems and shared disk computer systems. To run a shared disk database on a non-shared computer system, add software support to the operating system or provide additional hardware so that processes can have access to remote disks Is possible.

Non-shared database A non-shared database assumes that a process can access the data only if the data belongs to a disk that belongs to the same node as the process. Thus, if a particular node wants an operation on a data item owned by another node to be performed, that particular node will have other nodes perform the operation so that the other node performs the operation. A request must be sent. Thus, a non-shared database is said to perform a “function transfer” instead of transferring data between nodes.

  Since any given piece of data is owned by only one node, only that one node (the “owner” of the data) has a copy of that data in its cache. Therefore, a cache coherence mechanism of the type required in a shared disk database system is not required. Furthermore, the non-shared system does not suffer from the performance penalty associated with ping. This is because the node that owns the data item is not required to save the cached version of the data item to disk so that another node can load the data item into the cache. .

  A non-shared database can be run on either a shared disk multi-processing system or a non-shared multi-processing system. In order to run a non-shared database on a shared disk machine, a mechanism can be provided to segment the database and assign ownership of each partition to a particular node.

The fact that only the owning node can act on a piece of data means that the workload in a non-shared database can be very unbalanced. For example, in a 10 node system, 90% of the total work demand may require data owned by one of those nodes. Therefore, the one node is overused, and the computing resources of the other nodes are not fully utilized. To “rebalance” the workload, the non-shared database can be taken offline and the data (and its ownership) can be redistributed among the nodes. However, this process involves a potentially large amount of data movement and may only temporarily resolve the workload bias.

Distributed transactions in a non-shared database system A distributed transaction can specify updates to data items that reside on different nodes in the non-shared database system. For example, a distributed transaction can specify updates to a first piece of data owned by a first non-shared node and updates to a second piece of data owned by a second non-shared node. . A node that owns data involved in a distributed transaction is referred to herein as a “participating” node or simply “participant”.

  Distributed transactions must either be committed or “rolled back” if an error occurs to maintain data integrity. When a transaction is committed, all changes to the data specified by that transaction are made permanent. On the other hand, when a transaction is rolled back, all changes to the data specified and already made by the transaction are withdrawn or canceled as if no changes were made to the data. In this way, the database is put into a state that either reflects all changes specified within the transaction or does not reflect any changes specified within the transaction.

Two-stage commit One approach for ensuring data consistency during a distributed transaction requires the processing of a distributed transaction using a two-stage commit protocol. Two-phase commit is described in detail, for example, in US Pat. No. 6,493,726, entitled “Performing 2-Phase Commit With Delayed Forget”. Two-phase commit generally requires that a transaction be “prepared” first and then committed. The changes specified by the transaction are made at each participating non-shared node prior to being ready. When the participating node completes all requested operations, it joins these changes and “preparation” records into permanent storage. The participant then reports to the coordinator that the participant is in a “ready” state. If all participants successfully enter the ready state, the coordinator forces a commit record into persistent storage. On the other hand, if any error occurs before the ready state, indicating that at least one of the participating nodes cannot make the changes specified by the transaction, all changes at each of the participating nodes are withdrawn. Each participating database system is restored to the state before the change.

  FIG. 1 illustrates a multi-node non-shared database system that is used to show in more detail the costs associated with a conventional approach for performing a two-phase commit. The multi-node database system 100 includes a coordination node 110 and a participating node 150. Coordination node 110 receives requests for data from database clients 120, including client 122 and client 124. Such a request may take the form of an SQL statement, for example.

The coordination node 110 includes a log such as the log 112. Log 112 is used to record changes made to the database system and other events that affect the state of these changes, such as commits. Log 112 includes various log records.
When these log records are first created, they are first stored in volatile memory and immediately stored permanently in a non-volatile storage device (eg, a non-volatile storage device such as a disk). Once the log record is written to non-volatile storage, changes and other events specified by the log record are referred to as "permanent". These changes and events are “permanent”. This is because if a system failure occurs, after this failure, these permanently stored logs can be used to replay changes and events and restore the database to its pre-failure state. .

  FIG. 2 is a flow diagram illustrating the interaction between a coordinator and a participant according to a conventional approach for performing a two-phase commit. Using the multi-node database system 100 as an example, the state of a transaction is shown. Transaction state 201 is the state of the transaction experienced by the transaction in the coordinating database system (ie, coordinating node 110), and transaction state 202 is experienced by the transaction in the participating database system (ie, participating node 150). State of the transaction to be executed.

  Referring to FIG. 2, inactive states 210, 240, 250, and 290 represent transaction inactive states. In an inactive state, a database operation that is specified by the transaction and that requires some other action (such as committing, undoing, locking resources such as data blocks required to perform operations, or unlocking) Does not exist. The transaction is initially in an inactive state (ie, inactive states 210 and 250) and returns to an inactive state (ie, inactive states 240 and 290) when the transition is complete.

  When the database system receives a “start transaction” request, the transaction transitions from an inactive state to an active state. For example, the client 122 (FIG. 1) may issue a BEGIN TRANSACTION request to the coordination node 110. Alternatively, the “start transaction” directive may be implicit. For example, when a database server receives a statement specifying an operation or change, it can start an active transaction. In step 212, the coordination node 110 receives a transaction start request and enters an active state 220. Next, the coordination node 110 receives a command to change data on the participating node 150. In response, the coordinating node 110 sends a request to start the transaction to the participating node 150 in step 221. In step 222, the coordination node 110 sends one or more requests to the participating node 150 to change data on the participating node 150.

  In step 252, participating node 150 receives a request to initiate a transaction. For participating node 150, the transaction enters an active state 260. Participating node 150 then receives a request to change data.

  Once a transaction in the database system is active, the database system can receive any number of requests to change data as part of the transaction. For example, the client 122 can issue a request to the coordination node 110 to change data on both the coordination node 110 and the participating node 150. The coordinating node 110 transmits a request to change the data on the participating node 150 to the participating node 150 in response to receiving the request to change the data on the participating node 150.

In step 223, the coordination database system receives a request from the client 122 to commit the transaction. In response, the coordination node 110 sends a preparation request to the participating node 150 in step 224. In step 262, participating node 150 receives the request.

  In step 264, participating node 150 flushes log 152 (FIG. 1) to non-volatile storage. “Flush log” means that a log record of a log currently stored only in volatile memory is stored in non-volatile storage. Thus, by flushing the log, changes to participating nodes 150 are permanent. When the change becomes permanent, participating node 150 may ensure that that part of the transaction can be committed. Thus, after step 264, the transaction enters a ready state. In step 266, participating node 150 records the transition to the ready state in log 152 (i.e., stores a log record on disk that records the fact that the ready state has been reached).

  In step 272, the participating node 150 sends a confirmation that it is ready to the coordination node 110. Ready confirmation is a message sent by the participating database system that indicates whether the participating database system is ready to commit the transaction. When the transaction is ready on the participating database system, the participating database system is ready to commit. In step 226, the coordination node 110 receives a confirmation that it is ready.

  In step 228, the coordination node 110 commits and flushes the log 112. Specifically, the coordination node 110 creates a log record in the log 112 and records the commit. When the coordinating node 110 flushes the log, the coordinating node 110 makes the commit permanent. When the commit becomes permanent, the transaction enters the committed state. Thus, after flushing the log, the coordination node 110 transitions to the committed state 230.

  After the transaction has reached the committed state, the coordinating node 110 sends a forgetting request to the participating coordinating node 110 in step 232. Next, the participating node 150 forgets the transaction. The forgetting request is a message transmitted to the participating database system and requesting the participating database system to execute the forgetting process. The term “forget” generally refers to additional actions required to transition a transaction from a ready or committed state to an inactive state (for example, committing a transaction and releasing resources). , Make the transaction inactive).

  In step 274, the participating node 150 receives the forgetting request. In step 276, the participating database system commits (including creating a log record and recording the commit), and then flushes the log 152. At this stage, the transaction enters an inactive state on the participating node 150. In step 282, participating node 150 releases any locks remaining on the resources locked by participating node 150 for the transaction. In step 284, participating node 150 sends a forgetting confirmation to coordination node 110. The forgetting confirmation is a message transmitted by the participating node and notifying that the forgetting process has been completed on the participating node.

  In step 234, the coordination node 110 receives a message notifying completion of the forgetting process. In step 236, the coordination node 110 can delete the state information held by the coordinator for the transaction. Such state information may include, for example, a list of participants in the distributed transaction. At this stage, the transaction enters an inactive state on the coordination node 110.

  The cost per transaction in a two-phase commit can be measured by the number of messages and log flushes sent due to the execution of the two-phase commit. Because four messages are due to a two-phase commit (ie, step 221, step 232, step 272, and step 284), the cost per transaction for the message is 4N, where N is the number of participating nodes be equivalent to. One log flush for the coordinating node (ie, step 228) and two log flushes for each participating node result from a two-phase commit, and the cost for log flush is 2N + 1, where N is the number of participating nodes is there.

  Based on the foregoing, it is clearly desirable to provide a technique that reduces the number of messages, handshakes, and log flushes required to complete a transaction that requires multiple non-shared nodes.

  The invention is illustrated by way of example and not limitation in the accompanying drawings. In these drawings, the same reference numbers refer to the same elements.

DETAILED DESCRIPTION OF THE INVENTION Various techniques for improving the performance of non-shared database systems including shared disk storage systems are described below. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent that the invention may be practiced without such specific details. In some instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.

Functional Overview Various techniques for improving the performance of a non-shared database system where at least two nodes running the non-shared database system have shared access to the disk are described below. Each data piece is still owned by only one node at any given time, as defined by the non-shared architecture of the database system. However, it takes advantage of the fact that at least some nodes running a non-shared database system have shared access to the disk to perform distributed transactions more efficiently. Specifically, the one-stage commit protocol is used by participants who have access to the shared disk containing the co-ordinator process redo log, rather than ensuring the consistency of distributed transactions via the two-stage commit protocol Is done.

Redo Log When a database server updates a data item in volatile memory as part of a transaction, the database server generates a redo record that contains information about the update. Before the transaction is committed, an update redo record is typically stored in a redo log on disk. By storing the redo record on disk before the transaction commits, to ensure that the database reflects the update, even if the database crashes before the updated data item itself is written to disk. To do. Redo records and redo logs are described, for example, in US Pat. No. 5,903,898 entitled “Method And Apparatus For User Selectable Logging”. Yes.

  The redo records generated by a node are generally stored in a redo log dedicated to that node. Thus, a non-shared database system having three nodes generally has three redo logs, each of the redo logs corresponding to one of the three nodes. The redo log associated with a non-shared node may only include redo for changes made by that node. However, when the re-execution log is stored in the shared disk to which another node has access, the other node can examine the contents of the re-execution log.

  As described in more detail below, a distributed transaction, or part of a distributed transaction, can be obtained by taking advantage of the non-shared node's ability to examine information held by other non-shared nodes. A technique is provided that allows it to be performed using a one-step commit protocol. For example, a technique that takes advantage of the fact that several participants in a distributed transaction can be read by the coordinator process of the distributed transaction and read information indicating the state of the distributed transaction. Describe. Such state information can be held, for example, on a shared disk in the re-execution log of the coordinator process. Alternatively, distributed transaction state information can be stored using a separate structure, such as a table, a set of blocks, or some persistent structure with an index. As described below, during the commit of a distributed transaction, the coordinator forces changes to the transaction state to the shared disk so that other participants can message the coordinator about the commit to other participants. If it stops functioning before sending, this status information can be examined to determine the result.

Internal Participant and External Participant According to one embodiment, the protocol used in the interaction between the coordinator node and the participant in a distributed transaction in a non-shared database system is maintained by the coordinator Depends on whether the status information of distributed transactions can be examined. Participants who can investigate distributed transaction state information are referred to as “internal participants” in this specification, and participants who cannot investigate distributed transaction state information are “external participants”. Called.

Two-stage commit for external participants According to one embodiment, external participants in a distributed transaction in a non-shared database system interact with a coordinator process according to a two-stage commit protocol. For example, an external participant may transition through the states and steps shown in FIG. Specifically, the external participant first receives a request from the coordinator to initiate a transaction as part of a larger distributed transaction. The external participant then begins a transaction and performs the requested operation as part of that transaction.

  If the changes made by the distributed transaction are intended to be permanent, the external participant will eventually receive a “prepare” request. In response to this preparation request, the external participant flushes the redo record to disk, flushes the “ready” record to disk, and sends a ready confirmation back to the coordinator node.

  If it is assumed that all participants can successfully prepare, the external participant receives a request to forget. In response to this forgetting request, the external participant forces a commit record to the disk. The participant then sends a forgetting confirmation to the coordinator node.

One-phase commit for internal participants In one embodiment, internal participants do not use the two-phase commit protocol during distributed transactions. Specifically, the internal participant does not need to log a preparation record indicating that the internal participant is ready after successfully performing the tasks associated with the distributed transaction. Rather, the internal participant only waits for a commit request from the coordinator after performing the requested work and flushing any changes made thereby to persistent storage. When a commit request arrives, the internal participant commits the changes and sends a commit confirmation message back to the coordinator.

  Referring to FIG. 3, FIG. 3 is a flow diagram illustrating interaction between a coordinator and internal participants during a distributed transaction, according to one embodiment of the present invention. For illustration purposes, the coordinator node and the internal participant are two non-shared nodes of a non-shared database, and the distributed transaction performs one or more operations that require data owned by the internal participant. Imagine what you want.

  In step 302, the coordinator receives a request to start a distributed transaction, and in step 304, the coordinator starts a distributed transaction. In step 306, the coordinator sends a request to the internal participant to initiate a child transaction and perform an operation that is part of the distributed transaction.

  In step 350, the internal participant receives a request to start a child transaction, and in step 352, the internal participant starts a child transaction. In step 308, the coordinator sends a request to perform the task to the internal participant, and in step 354, the internal participant receives the request and performs the task. While an internal participant performs a task, the internal participant generates a redo record that reflects the changes that the internal participant is making. Such a replay record can be periodically stored on the disk, as shown in step 356. Alternatively, the redo record may be kept in volatile memory until some condition that triggers a flash is met. Such conditions that trigger a flush may include, for example, the need to free volatile memory for other uses, or the receipt of a flush request.

  In step 310, the coordination node receives a commit request. In response to this commit request, the coordinator determines whether all participants have stored on disk a replay for all of the changes performed as part of the distributed transaction. Various techniques can be used by the coordinator to make this determination. Examples of such techniques are presented in more detail below.

  If all of the participants have stored on disk a replay for all of the changes performed as part of the distributed transaction, control proceeds to step 314; otherwise, control passes to step 314. Proceed to 322. In step 322, the coordinating node waits until all participants log changes to disk. The coordinator can optionally send a flush request to participants who have not yet logged all of their changes to disk to facilitate the completion of the transaction. In response to such a request, the participant flushes all redoes associated with the changes made as part of the distributed transaction to disk.

In step 314, the coordinator flushes to disk any replays for transactions that have not yet been flushed to disk. The coordinator also forces a commit record to disk to indicate that the distributed transaction has been committed. The coordinator then sends a commit request to the participant and waits to notify the participant that the change has been committed (steps 316 and 324). It should be noted that although the coordinator still sends a commit request to the internal participant, the commit request may be sent after the distributed transaction is actually committed. Thus, sending such messages and receiving subsequent confirmations do not exist on the “critical path” of the distributed transaction.

  In step 358, the internal participant receives the commit request and in step 360 commits the child transaction containing the work for the distributed transaction. After committing the child transaction, the internal participant sends a commit confirmation message back to the coordinator (step 362).

  The coordinator permanently retains data indicating the state of the distributed transaction until it receives a commit confirmation message from all participants. When the coordinator receives a commit confirmation message from all participants, the coordinator process no longer needs to maintain state information about the distributed transaction (step 320).

Determining whether a participant's replay has been written to disk As described above, when a node makes a change, that node generates a replay record corresponding to the change. Changes performed by each node are generally assigned a sequence number by the node. Such a sequence number is referred to herein as a “log sequence number”.

  According to one embodiment, when an internal participant performs a task that is part of a distributed transaction, the internal participant responds to the coordinator of the distributed transaction with the work performed by the internal participant for this transaction. Communicate the maximum log sequence number to be transmitted. For example, assume that an internal participant performs three changes as part of a distributed transaction. Further assume that log sequence numbers 5, 7, and 9 are assigned to the redo records for these changes. When the change is completed in this example, the internal participant communicates a log sequence number of 9 to the coordinator.

  According to one embodiment, the coordinator uses the log sequence number received from the internal participant to determine whether the internal participant has logged all changes made as part of the distributed transaction to disk. To do. For example, assume that the maximum log sequence number communicated to a coordinator by a particular internal participant is nine. Under these circumstances, if the internal participant's persistent log contains all redo records associated with the log sequence number 9 and lower, the coordinator shall Recognize that changes related to the transaction have been logged to disk.

  Various techniques can be used by the coordinator to determine which redo records have been flushed to disk by internal participants. For example, the internal participant redo log may reside on a shared disk that is directly accessible to the coordinator. Thus, the coordinator simply examines the internal participant's redo log and / or any metadata maintained for that redo log to see if the necessary redo information is stored on disk. Can be judged. Alternatively, the various nodes in a non-shared database system have their current redo log current boundary ("checkpoint") (where all redoes below the checkpoint are logged to disk) Can communicate with each other). Such communication can occur in response to a request for information, or can occur regularly in anticipation.

Superposed messages It is common for many messages to pass between non-shared nodes of a non-shared database system. According to one embodiment, some or all of the information communicated between the coordinator node and internal participants is communicated by “superimposing” information about messages being sent between the nodes.

  For example, in step 322, the coordinator sends a “force replay” message to the internal participant by superimposing the message on another message that is otherwise being sent to the internal participant's node. be able to. Similarly, internal participants can send the maximum log sequence number and commit confirmation message to the coordinator process by superimposing information on messages that are otherwise being sent to the coordinator.

Recovering a crashed participant As described above, the coordinator commits a distributed transaction after determining that all of the participants have logged replays related to changes made as part of the distributed transaction. (Step 314). It is possible that a participant in a distributed transaction will crash either before or after writing the required replay to disk. Under these circumstances, recovery of a crashed participant requires the decision to commit or roll back changes made as part of the distributed transaction.

  If the crashing participant is an external participant and the external participant was preparing changes before the crash, the participant's own redo log has a preparation record associated with the distributed transaction. When the recovery process detects this readiness record, it recognizes that it will not automatically roll back changes associated with distributed transactions. On the other hand, if the external participant's redo log does not have a preparation record, the recovery process automatically rolls back the changes.

  If the crashing participant is an internal participant and the crashing participant has logged enough redo information to disk before the crash, the participant's own redo log will have a preparation record. Absent. However, instead of automatically rolling back the changes associated with the distributed transaction, the recovery process asks the coordinating node whether the distributed transaction has been committed.

  When the coordinator is functioning and responds by indicating that the distributed transaction has been committed, the changes made by the crashed node become permanent as part of the recovery of the crashed node.

  When the coordinator node is functioning and responds by indicating that the distributed transaction has been rolled back, changes made by the crashed node are rolled back as part of the recovery of the crashed node.

  If the coordinator node crashes and another node is recovering the coordinator node, the process of recovering that coordinator node could provide the necessary information for the recovery process of the crashed participant. However, if the coordinator node crashes and the recovery process is not available to provide the status of the distributed transaction, the recovery process for internal participants has direct access to the distributed transaction state information maintained by the coordinator node. Thus, necessary information can be acquired.

Specifically, in an embodiment in which an internal participant has access to the coordinator's redo log, the recovery process for a crashed internal participant examines the coordinator's redo log and records a commit record for the distributed transaction. It can be confirmed whether or not it exists. If the co-ordinator process redo log contains a commit record for the distributed transaction, the recovery process commits the changes made by the crashing participant. On the other hand, if the coordinator's redo log does not include a commit record for the distributed transaction, the recovery process rolls back the changes made by the crashing participant.

Crashing coordinator The coordinator may crash before sending a commit request to a participant in a distributed transaction. Under such circumstances, the external participant recognizes the state of the distributed transaction based on the communication content received from the coordinator before the crash. Specifically, the external participant recognizes whether a request to prepare and / or a request to forget has been received.

  On the other hand, it is conceivable that the internal participant has to access the shared disk and examine the transaction state information written to the disk by the coordinator before the crash. According to one embodiment, an internal participant requests state information from the coordinator node when the internal participant needs to be aware of the coordinator's transaction state, or if the coordinator node is restored, Request status information from the recovery process to recover the coordinator node. If the coordinator node has crashed and has not been recovered, the internal participant retrieves the distributed transaction state information held by the coordinator. For example, in one embodiment, an internal participant obtains this information by examining the coordinator's redo log. When the transaction information indicates that the coordinator has committed the distributed transaction, the internal participant commits the changes made by the internal participant as part of the distributed transaction. If the coordinator process has not committed the distributed transaction at the time of the crash, the internal participant rolls back changes made by this internal participant as part of the distributed transaction.

  Eventually, to ensure that all internal participants are aware of the final state of a distributed transaction, until all subordinates have notified that their corresponding child transactions have been committed or aborted The coordinator node prevents the transaction state information of the distributed transaction from being deleted or overwritten. Thus, even if the internal participant crashes after the distributed transaction is committed and before receiving the commit request, the internal participant will eventually recognize that the distributed transaction has been committed, and therefore , And finally commit its corresponding child transaction.

Hardware Overview FIG. 4 is a block diagram that illustrates a computer system 400 upon which an embodiment of the invention may be implemented. Computer system 400 includes a bus 402 or other communication mechanism for communicating information, and a processor 404 coupled with bus 402 for processing information. Computer system 400 also includes a main memory 406, such as random access memory (RAM) or other dynamic storage device, coupled to bus 402 for storing instructions and information for execution by processor 404. Main memory 406 can also be used to store temporary numeric variables or other intermediate information during execution of instructions executed by processor 404. Computer system 400 further includes a read only memory (ROM) 408 or other static storage device coupled to bus 402 for storing static information and instructions for processor 404. A storage device 410, such as a magnetic disk or an optical disk, is provided and coupled to the bus 402 for storing information and instructions.

  Computer system 400 may be coupled via bus 402 to a display 412 for displaying information to a computer user, such as a cathode ray tube (CRT). An input device 414 that includes alphanumeric keys and other keys is coupled to the bus 402 to communicate information and command selections to the processor 404. Another type of user input device is a cursor control device 416, such as a mouse, trackball, or cursor direction key, for communicating direction information and command selections to the processor 404 to control the movement of the cursor on the display 412. . The input device generally has two degrees of freedom in two axes, a first axis (such as x) and a second axis (such as y), which allows the input device to locate on a plane. it can.

  The invention is related to the use of computer system 400 for implementing the techniques described in this specification. According to one embodiment of the invention, these techniques are performed by computer system 400 in response to processor 404 executing one or more sequences of one or more instructions contained in main memory 406. Such instructions can be read into main memory 406 from another computer-readable medium, such as storage device 410. By executing the sequence of instructions contained in main memory 406, processor 404 performs the process steps described herein. In an alternative embodiment, the present invention can be implemented using a connection circuit instead of or in combination with software instructions. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.

  The term “computer-readable medium” as used herein refers to any medium that participates in providing instructions to processor 404 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks such as storage device 410. Volatile media includes dynamic memory, such as main memory 406. Transmission media includes coaxial cables, copper wire, and optical fiber, and includes wires having a bus 402. Transmission media can take the form of acoustic or light waves, such as those generated during radio wave data communication and infrared data communication.

  Common forms of computer readable media include, for example, floppy disk, flexible disk, hard disk, magnetic tape, any other magnetic medium, CD-ROM, any other optical medium, punch Card, paper tape, any other physical medium with a hole pattern, RAM, PROM, EPROM, FLASH-EPROM, any other memory chip or cartridge, carrier wave described below, or computer-readable Any other media that can be included.

  Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to processor 404 for execution. For example, the instructions may be initially carried on a remote computer magnetic disk. The remote computer can load the instructions into its own dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 400 can receive the data on the telephone line and use an infrared transmitter to convert the data to an infrared signal. Data carried by the infrared signal can be received by an infrared detector, and appropriate circuitry can output the data on bus 402. Bus 402 carries the data to main memory 406, from which processor 404 retrieves and executes the instructions. The instructions received by main memory 406 may optionally be stored on storage device 410 either before or after execution by processor 404.

  Computer system 400 also includes a communication interface 418 coupled to bus 402. Communication interface 418 provides a two-way data communication coupling to network link 420 connected to local network 422. For example, the communication interface 418 may be an integrated services digital network (ISDN) card or modem for providing a data communication connection to a corresponding type of telephone line. As another example, communication interface 418 may be a LAN card for providing a data communication connection to a compatible local area network (LAN). A wireless link can also be realized. In any such implementation, communication interface 418 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

  Network link 420 typically provides data communication to other data devices via one or more networks. For example, the network link 420 may provide a connection via a local network 422 to a host computer 424 or a data device operated by an Internet Service Provider (ISP) 426. ISP 426 then provides data communication services through a worldwide packet data communication network now commonly referred to as the “Internet” 428. Local network 422 and Internet 428 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and on the network link 420 and through the communication interface 418 are exemplary forms of carriers that carry digital data to and from the computer system 400 and carry information.

  The computer system 400 can send messages over the network, network link 420, and communication interface 418 to receive data including program code. In the Internet example, the server 430 may send the requested code to the application program via the Internet 428, ISP 426, local network 422, and communication interface 418.

  The received code may be executed by processor 404 when received and / or stored in storage device 410 or other non-volatile storage for later execution. In this way, computer system 400 can obtain application code in the form of a carrier wave.

  In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details that may vary from implementation to implementation. Therefore, the only thing that exclusively indicates what the invention is and what the applicant intends for this invention is a set of claims arising from this application and taking a specific form Term. In a particular form, such a claim will be generated including any future corrections. Any definitions expressly set forth herein for terms contained in such claims shall govern the meaning of such terms as used in the claims. Hence, no limitation, element, property, feature, advantage or attribute that is not expressly recited in a claim should limit the scope of such claim in any way. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.

1 is a block diagram of a multi-node database system. It is a flowchart which shows the step contained in the conventional 2 step | paragraph commit protocol. FIG. 3 is a flow diagram illustrating interaction between a coordinator and internal participants according to one embodiment of the present invention. And FIG. 11 is a block diagram of a computer system in which an embodiment of the present invention may be implemented.

Claims (12)

A method for coordinating distributed transactions in a non-shared database system, comprising:
Wherein the first unshared node of a non-shared database system, the first coordinator on unshared nodes to adjust the distributed transaction, the distributed transactions performed by the first unshared node aspects in the first redo log the re-execution record first unshared node writes associated, comprising the steps of memorize a commit record indicating the committed state of the distributed transaction,
The first redo log is stored in a permanent storage device;
The persistent storage is accessible to participants who can perform one or more operations as part of the distributed transaction;
The participants, the runs on the second unshared nodes of non-shared database system, said participants, said the first second redo log that is different from the redo logs, the second Writing a replay record associated with an aspect of the distributed transaction executed by a non-shared node , the method further comprising:
In the second unshared node of the non-shared database system, a step wherein the participant, you determine the status of the distributed transaction by reading the commit record from the first redo log,
In response to a determination by the participant that the distributed transaction is committed, the participant commits changes made by the participant as part of the distributed transaction. The method, wherein the participant is a computer program executed on a computer . The participant is a first participant of a plurality of participants in the distributed transaction;
The plurality of participants includes a second participant having no access to the persistent storage;
The method may further accordance two-phase commit protocol, see contains the step of the coordinator to interact with the second participant,
The coordinator sends a prepare message to the second participant in the prepare phase of the two-phase commit protocol so that the second participant does not have access to the persistent storage;
The coordinator does not send any preparation message to the first participant in the preparation phase of the two-phase commit protocol because the first participant has access to the persistent storage;
At the time when the first participant will determine the state of the distributed transaction by reading the commit record from the first redo log, the coordinator has crashed and any recovery The process has not yet recovered,
The method of claim 1, wherein the second participant is a computer program executed on a computer . The coordinator commits the distributed transaction;
After the coordinator commits the distributed transaction, the coordinator sends a commit message to the participant;
Further comprising preventing the commit record from being overwritten or deleted until a set of conditions is met, wherein one condition within the set of conditions is the coordinator receiving a commit confirmation message from the participant. The method of claim 1, wherein The participant further includes transmitting a first piece of information to the coordinator, the first piece of information relating to work performed by the participant as part of the distributed transaction; The method further comprises:
The coordinator performing a comparison between the first piece of information and information associated with the second redo log of the second non-shared node;
The method of claim 1, further comprising: the coordinator determining whether to commit the transaction based at least in part on the comparison.   5. The method of claim 4, wherein the piece of information includes a log sequence number of the latest change made by the participant as part of the distributed transaction. Said step of transmitting comprises:
The participant identifying a message being sent to the first non-shared node for purposes unrelated to the distributed transaction;
Superimposing the log sequence number on the message. A method for executing a distributed transaction in a non-shared database system, comprising:
Assigning participants to perform one or more operations as part of the distributed transaction;
The participants, the runs on the first unshared nodes of non-shared database system, the method further
A replay log, in which only the participant writes a replay record related to an aspect of the distributed transaction executed by the participant, is recorded by the participant during the execution of the one or more operations. Storing in a permanent storage device state information indicating changes made to the data in the non-shared database on which the one or more operations are performed ;
The persistent storage is accessible to a coordinator responsible for coordinating the distributed transaction;
The coordinator is executed on a second non-shared node of the non-shared database system, the method further comprising:
On the second non-shared node of the non-shared database system, the participant performs the one or more operations based on the state information included in the re-execution log on the permanent storage device. a step that occurs lasting the coordinator whether written in the memory the change was that be determined,
Based at least in part on the permanent whether written in the memory changes the participant resulting from execution of the one or more operations, the coordinator is whether the distributed transaction may be committed look including a step of determining,
The method wherein the participant is a computer program running on a computer . The participants, the step of storing status information indicating the made by the participants during one or more execution changes permanent storage device, the participants, the persistent storage wherein said step you storing redo information to the redo log of the apparatus,
Based on the state information on the permanent storage device, the step of the participant said one or more of the coordinator whether written to persistent storage any changes caused by the execution of the operation to determine the The method of claim 7, comprising examining the redo log of the participant to determine whether the redo information about the change has been written to the persistent store. The participant is a first participant of a plurality of participants in the distributed transaction;
The plurality of participants includes a second participant that stores state information in a second persistent storage that is not accessible by the coordinator;
8. The method of claim 7, wherein the method further comprises the step of the coordinator interacting with the second participant according to a two-stage commit protocol. The information on the persistent storage indicates that the participant has not written changes to the persistent storage resulting from performing the one or more operations;
The method further includes the coordinator sending a message to the participant to force a re-execution to cause the participant to write the change resulting from the execution of the one or more operations to permanent storage. The method of claim 7, comprising transmitting. Sending the message forcing the re-execution,
Identifying a message being sent to the first non-shared node for purposes unrelated to the distributed transaction;
And superimposing a message forcing the re-execution on the message. A program for executing a method for coordinating distributed transactions in a non-shared database system, wherein the program causes a processor of a computer to execute the method according to any one of claims 1-11.

Images