Replication is an area of interest to both distributed systems and databases. The solutions developed from these two perspectives are conceptually similar but differ in many aspects: model, assumptions, mechanisms, guarantees provided, and implementation. In this paper, we provide an abstract and "neutral" framework to compare replication techniques from both communities in spite of the many subtle differences. The framework has been designed to emphasize the role played by different mechanisms and to facilitate comparisons. With this, it is possible to get a functional comparison of many ideas that is valuable for both didactic and practical purposes. The paper describes the replication techniques used in both communities, compares them, and points out ways in which they can be integrated to arrive to better, more robust replication protocols.

Abstract-In this paper, we present a performance comparison of database replication techniques based on total order broadcast. While the performance of total order broadcast-based replication techniques has been studied in previous papers, this paper presents many new contributions. First, it compares with each other techniques that were presented and evaluated separately, usually by comparing them to a classical replication scheme like distributed locking. Second, the evaluation is done using a finer network model than previous studies. Third, the paper compares techniques that offer the same consistency criterion (one-copy serializability) in the same environment using the same settings. The paper shows that, while networking performance has little influence in a LAN setting, the cost of synchronizing replicas is quite high. Because of this, total order broadcast-based techniques are very promising as they minimize synchronization between replicas.

Data replication is an increasingly important topic as

No abstract

In this paper, we study the safety guarantees of group communicationbased database replication techniques. We show that there is a model mismatch between group communication and database, and because of this, classical group communication systems cannot be used to build 2-safe database replication. We propose a new group communication primitive called end-to-end atomic broadcast that solves the problem, i.e., can be used to implement 2-safe database replication. We also introduce a new safety criterion, called group-safety, that has advantages both over 1-safety and 2-safety. Experimental results show the gain of efficiency of group-safety over lazy replication, which ensures only 1-safety. IntroductionDatabase systems represent an important aspect of any IT infrastructure and as such require high availability. Software-based database replication is an interesting option because it promises increased availability at low cost. Traditional database replication is usually presented as a trade-off between performance and consistency [1], i.e., between eager and lazy replication. Eager replication, based on an atomic commitment protocol, is slow and deadlock prone. Lazy replication, which foregoes the atomic commitment protocol, can introduce inconsistencies, even in the absence of failures.However, eager replication does not need to be based on atomic commitment. A different approach, which relies on group communication primitives to abstract the network functionality, has been proposed in [2, 3], These techniques typically use an atomic broadcast primitive (also called total order broadcast) to deliver and order transactions in the same serial order on all replicas, and offer an answer to many problems of eager replication without the drawbacks of lazy replication: they offer good performance [4], use the network more efficiently [5] and also reduce the number of deadlocks [6].Conceptually, group communication-based data replication systems are built by combining two modules: (1) a database module, which handles transactions and (2) a group communication module, which handles communication. When combined, these two module result in a replicated database. However, the two modules assume different failure models, which means that the failure semantics of the resulting system are unclear. Group Communication Component Database ComponentReplicated Database Component (Application) Model and DefinitionsWe assume that the overall system is built from three components (Fig. 1): the database component, the group communication component and the replicated database component. The first two components offer the infrastructure needed to build the application -in our case a replicated database. These two infrastructure components are accessed by the application, but they have no direct interaction with each other. The replicated database component implements the actual replicated database and is described in Sect. 2.1. The database component contains all the facilities to store the data and execute transactions locally, and is de...