Browse Prior Art Database

Replication and Recovery of Database State Information in Fault Tolerant Clusters

IP.com Disclosure Number: IPCOM000106341D
Original Publication Date: 1993-Oct-01
Included in the Prior Art Database: 2005-Mar-21
Document File: 4 page(s) / 273K

Publishing Venue

IBM

Related People

Azagury, AC: AUTHOR [+6]

Abstract

In a fault-tolerant cluster, one of the goals is to provide databases that are resilient to failure, necessitating replicating database state information (cursor position, lock information, record modifications, commitment control, etc). Described is an efficient mechanism for replication and recovery of state information, enabling applications to switch seamlessly to a backup replica of the data when the primary replica fails. Database consistency and integrity are continuously preserved with minimal impact on normal transaction throughput. A background to cluster terminology and the type of database that the invention applies to is given under "Background" at the end of the disclosure.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 24% of the total text.

Replication and Recovery of Database State Information in Fault Tolerant Clusters

      In a fault-tolerant cluster, one of the goals is to provide
databases that are resilient to failure, necessitating replicating
database state information (cursor position, lock information, record
modifications, commitment control, etc).  Described is an efficient
mechanism for replication and recovery of state information, enabling
applications to switch seamlessly to a backup replica of the data
when the primary replica fails.  Database consistency and integrity
are continuously preserved with minimal impact on normal transaction
throughput.  A background to cluster terminology and the type of
database that the invention applies to is given under "Background" at
the end of the disclosure.

      For each application using the database, the cluster maintains
state information at the primary machine (position, locks held,
commit information, record modifications, etc).  Some attributes of
the state information are kept in the database (e.g., record locks,
record contents), whereas others are kept in the primary agent (eg
position).  When the primary machine fails, one of the backup
replicas is designated as the new primary for the database.  For each
application that survives, an agent is established on the new primary
machine and the state information is restored.  The application stub
can then route its operations to the new primary agent.  Switchover
should be completely transparent to the application, except for a
short delay.  If a database operation issued by an application was in
progress when the failure occurred, it must be determined if the
operation has actually completed executing on the primary.  If so,
the feedback of the operation needs to be recreated and returned to
the application stub.

      Disclosed are mechanisms to replicate state information
efficiently, with minimal impact on normal transaction throughput,
and to determine the status of operations that were in progress at
the time of failure.  It regenerates in a simple manner the operation
feedback that was to be returned to application stubs when the
failure occurred, which is important for operations whose feedback
cannot be determined from the journal entry.  The latter operations
are called critical operations.

      In the new mechanisms, state information is divided in two
parts:  (a) application related, and (b) database related.
Application-related state information is returned to the application
with each operation, piggybacked on the operation feedback.
Database-related state information is broadcast to the backup
machines while the operation is being journaled.

      For a journaled operation, the journal sequence number of the
entries generated by the operation is returned to the application
together with other state information.  When the backup applier
encounters a journal entry of a critical operation, it blocks
execution until...