RFC 677 (rfc677) - Page 2 of 10

Maintenance of duplicate databases

RFC 677          The Maintenance of Duplicate Databases     January 1975


Introduction

    There are a number of motivations for maintaining redundant,
duplicate copies of databases in a distributed network environment.  Two
important motivations are:

  - to increase reliability of data access.

    The accessibility of critical data can be increased by redundantly
    maintaining it. The database used for TIP login and accounting is
    redundantly distributed to achieve highly reliable access.

  - to insure efficiency of data access.

    Data can be more quickly and efficiently accessed when it is "near"
    the accessing process. A copy of the TIP user ID database is
    maintained at each site supporting the TIP login service to insure
    rapid, efficient access.  (Reliability considerations dictate that
    this database be redundantly maintained, and efficiency
    considerations dictate that a copy be maintained at each
    authentication site.)

    The design of a system to maintain redundant, duplicate databases is
a challenging task because of the inherent communication delay between
copies of the database, as well as the real world constraints of system
crashes, operator error, communication channel failure, etc.  This paper
discusses some of the problems we encountered in designing such a
system, and outlines a system design for maintaining a particular type
of database which solves those problems.


The Model

    A system for supporting duplicate copies of a database can be
modeled by a group of independent database management processes (DBMPs)
each maintaining its own copy of the database. These processes
communicate with each other over network communication paths. Each DBMP
has complete control over its copy of the database. It handles all
accesses to and modifications of the database in response to requests
from other processes. Though the DBMPs act only upon requests, in the
following they will often be said to be actually causing or originating
the modifications.

    An important design consideration is that the communication paths
between the DBMPs are subject to failures. Thus one DBMP may have its
interactions with other DBMPs interrupted and/or have to wait until
communication paths are re-established before it can communicate with
other DBMPs. An assumption made in this paper about the communication



Johnson & Thomas