Maintenance of duplicate databases (RFC0677)
Original Publication Date: 1975-Jan-01
Included in the Prior Art Database: 2019-Feb-14
Internet Society Requests For Comment (RFCs)
P.R. Johnson: AUTHOR [+1]
Network Working Group Paul R. Johnson (BBN-TENEX) RFC # 677 Robert H. Thomas (BBN-TENEX) NIC # 31507 January 27, 1975
The Maintenance of Duplicate Databases
This RFC is a working paper on the problem of maintaining duplicated databases in an ARPA-like network. It briefly discusses the general duplicate database problem, and then outlines in some detail a solution for a particular type of duplicate database. The concepts developed here were used in the design of the User Identification Database for the TIP user authentication and accounting system. We believe that these concepts are generally applicable to distributed database problems.
Johnson & Thomas [Page 1]
RFC 677 The Maintenance of Duplicate Databases January 1975
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.
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 [Page 2]