Browse Prior Art Database

Bounding Journal Back-Off during Recovery of Data Base Replica in Fault-Tolerant Clusters

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

Publishing Venue

IBM

Related People

Azagury, A: AUTHOR [+5]

Abstract

In a fault tolerant cluster with replicated databases, a machine that rejoins the cluster after a failure must recover its local database replicas. If the failure occurred while the machine was the primary site of a database, recovery entails deleting an undetermined number of journal entries which, due to the failure, were not replicated at any backup site. Normally, such entries are identified by simple comparison with the journal of the current primary replica. Described is a solution which bounds the number of entries that would have to be deleted. This is useful when the latest primary replica of the database is damaged, due to subsequent failure, and cannot be consulted. In this case the recovered journal has to be backed off to an old, consistent state. The new mechanism has minimal impact on transaction throughout.

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

Bounding Journal Back-Off during Recovery of Data Base Replica in Fault-Tolerant Clusters

      In a fault tolerant cluster with replicated databases, a
machine that rejoins the cluster after a failure must recover its
local database replicas.  If the failure occurred while the machine
was the primary site of a database, recovery entails deleting an
undetermined number of journal entries which, due to the failure,
were not replicated at any backup site.  Normally, such entries are
identified by simple comparison with the journal of the current
primary replica.  Described is a solution which bounds the number of
entries that would have to be deleted.  This is useful when the
latest primary replica of the database is damaged, due to subsequent
failure, and cannot be consulted.  In this case the recovered journal
has to be backed off to an old, consistent state.  The new mechanism
has minimal impact on transaction throughout.

      Clustering of machines and replication are a means of providing
highly available computing services.  Services typically provided by
one machine are replicated on several machines, and cluster
management provides transparent and consistent (single system image)
access to such services, independent of their location.  This
disclosure concerns database replication, although the concepts may
easily be adapted to other services having similar behaviour.  A key
issue in database replication design is how to bring local replicas
up-to-date when a machine re-joins the cluster after a failure.  In a
single machine environment, modifications of the database are usually
logged in a journal.  The journal serves several purposes, for
instance as a recovery tool.  Modifications logged in the journal can
be applied on a saved copy of the database to bring it up to date.
The journal can therefore be used to replicate databases in a cluster
of machines.  Journal entries, while being added to the local
journal, are also broadcasted to backup machines.  There, they are
applied to local (backup) replicas of the database to bring them up
to date.

      A journal has the following characteristics: access to the
journal is serialised by means of an exclusive lock; also journal
entries are guaranteed to reach stable storage before the
corresponding database modifications do.

      Consider a cluster that provides resilient databases, i.e.,
journaled databases that are replicated on two or more machines in
the cluster.  For each given database, one replica is designated as
primary replica and all the others as backup replicas.  All database
operations are shipped to the machine holding the primary replica of
the database, where they are executed.  Backup replicas are kept
updated by broadcasting the entries added to the journal of the
primary and applying them on the backup replicas of the objects.
Control will return to the application only after backup machines
acknowledge receipt of the journal entries...