Reliability issues for fully replicated distributed databases

Reliability is commonly considered to be one of the main advantages of distributed databases, but there are problems that must be overcome before it can be achieved. Exactly what is reliability? There are many types of failures, and we should know which types the system will be protected against. It is also necessary to define how the system will react to those failures. A considerable number of special protocols must be implemented with great care in order to realize the desired level of reliability. The purpose of this article is to discuss the design alternatives and problems that must be solved in order to make a completely replicated distributed database reliable. A distributed database is completely replicated if a copy of the value of any data item is stored at every node (or site) in the system. A completely replicated distributed database is a special case of a general distributed database, and there are several reasons for studying the reliability issues in this limited context: (1) Complete replication simplifies the problems. Making a distributed database reliable is not a simple matter, so as a first step we can try to understand a simplified specific case. (2) Replicated data is the key to making data available after failures, so we will actually be concentrating on the critical component of distributed databases. (3) Transaction processing (with no failures) in a completely replicated distributed database is well understood and a good number of papers have been written on the subject. 1-5 Most of the research for reliable distributed databases has been performed in the context of particular transaction processing algorithms. (There are exceptions, however .6'7) This means that only the alternatives best suited to the transaction processing algorithm are considered. In this article this will be avoided by not advocating a particular transaction processing algorithm. A person designing a reliable distributed database is faced with a set of choices. Here these choices are divided into seven broad categories and each category will be discussed in one of the following sections. For each choice that must be made by the designer, I will attempt to give the major alternatives available and then list the implications of these alternatives. Many of the mechanisms for reliable distributed databases that we will discuss have been presented in the literature. I would like to caution the reader that my division of choices is somewhat arbitrary and that the …