1. Field of the Invention
The present invention relates generally to providing a backup database system to a primary database system and more particularly to providing a backup database system to a distributed primary database system.
2. Description of the Related Art
A transaction database management system (DBMS) must ensure that every transaction performed by the system has four important properties. Each transaction, which consists of a series of reads and writes of database objects, must be (i) atomic, (ii) consistent regarding the database objects it affects, (iii) isolated from other transactions with which it may be concurrent, and (iv) persistent after it is completed (durable). (These are the so-called ACID properties of a DBMS.) An atomic transaction is one that is either carried out completely or not done at all. A durable transaction is one that, once completed, is from then one always completed despite system failures that may occur subsequent to its completion.
A part of the transaction DBMS, called the recovery manager, is responsible for ensuring that each transaction is atomic and durable. In order for the recovery manager to ensure these transaction properties, it is customary for the recovery manager to maintain a log file (or audit file) of all changes to the database objects. This log file is stored on a storage medium that survives system failures and media failures. Changes to the database objects are made only after the change which is to occur is written to the log file (known as write-ahead logging). The log file allows the recovery manager to perform undo operations and redo operations. Undo operations remove actions made upon the database objects for transactions that did not complete. Redo operations repeat all the actions of a transaction that did complete. Redo operations must proceed from a known or determined point in the log file. By these operations, the database is restored to the state it had prior to the failure it experienced.
If a primary transaction database system having the ACID properties is centralized (meaning that a single transaction monitor is used), it is possible to provide a backup database system that can provide complete functionality when the primary database system fails. The backup database system must be transactionally consistent with the primary system so that the transfer of operations onto the backup system is seamless. Transactional consistency means that all transactions that have been committed on the primary system are committed on the backup system and all transactions that have been or were in the process of being aborted on the primary are aborted on the backup system. One such primary and backup system is disclosed in U.S. Pat. No. 5,799,323, which is incorporated by reference into this document.
However, if a primary database system is only part of a larger database system such that there are multiple primary database systems (primary nodes each having a transaction monitor) and multiple backup systems (backup nodes, one for each primary node), then the current art backup system recovery procedures cannot guarantee that the multiple backup nodes are in a consistent state when a failure of a primary node occurs, if a transaction is distributed across and affects two or more of the multiple primary nodes. The reason is that an unplanned outage of a primary node can cause transactions received on the backup node for the primary node to be in an incomplete state (neither committed nor aborted) (lack of local consistency) and committed distributed transactions not to be received as committed on each and every primary node that participates in a distributed transaction (lack of distributed consistency). A backup system in such a condition cannot takeover the transaction processing of the primary system without loss of data integrity.
Thus, there is a need for a recovery procedure and backup system that guarantees that the backup nodes for the primary nodes of a distributed database system have both local consistency and distributed (or network) consistency after a failure of a primary node that participates in a distributed transaction.
An unplanned outage on a primary node of a primary distributed transaction system requires that a takeover procedure occur not just on the backup system for that primary node but on all backup nodes for the nodes of the primary system. In particular, the loss of one of the primary nodes to an unplanned outage, requires that (i) a takeover operation occur on the backup node of the primary node that disappeared; (ii) applications on the surviving primary nodes quit; and (iii) a takeover operation be executed on each of the other backup nodes. The present invention is directed towards the takeover operations on the backup nodes in this circumstance.
One method, in accordance with the present invention, includes a method of backing up a distributed database system that has a plurality of primary nodes, each with a database and transaction monitor, where each primary node is configured to participate in at least one distributed transaction, and each primary node has a backup node with a database. The method includes the steps of performing a local backup operation on the database of each backup node to leave on the backup node""s database only those transactions received as committed or aborted from the backup node""s primary node and then performing a global backup operation to undo any committed transaction whose presence causes the backup nodes to primary nodes that participated in the distributed transaction to be inconsistent. The step of performing a global backup operation includes finding a common synchronization point among the backup nodes, then producing for each backup node a local commit list that contains all transactions received as committed on each backup node from the common synchronization point through the last committed transaction received on the backup node. Next, the method includes modifying the local commit list at each backup node to mark as undo: (i) committed transactions that are not fully committed and (ii) committed transactions that are potentially dependent on transactions not fully committed. Finally, a network undo list is formed based on the modified local commit list and the updates for those transactions in the network undo list are undone.
One advantage of the present invention is that the backup nodes are quickly ready to support operations in place of the primary system.
Another advantage is that operator intervention is not required to determine whether the backup system is in a consistent and usable state.
Yet another advantage is that backup nodes do not have to be restricted to systems that support only non-distributed transactions. The backup systems are fully generalized to back up nodes that participate in both non-distributed and distributed transactions.
USPTO Backgrounds
USPTO Backgrounds