Luis Irún-Briz

Managing Transaction Conflicts in Middleware-based Database Replication Architectures

Database replication protocols need to detect, block or abort part of conflicting transactions. A possible solution is to check their writesets (and also their readsets in case a serialisable isolation level is requested), which however burdens the consumption of CPU time. This gets even worse when the replication support is provided by a middleware, since there is no direct DBMS support in that layer. We propose and discuss the use of the concurrency control support of the local DBMS for detecting conflicts between local transactions and writesets of remote transactions. This allows to simplify many database replication protocols and to enhance their performance

MADIS: a slim middleware for database replication

Data replication serves to improve the availability and performance of distributed systems. The price to be paid consists of costs caused by protocols by which a sufficient degree of consistency of replicated data is maintained. Different kinds of targeted applications require different kinds of replication protocols, each one requiring a different set of metadata. We discuss the middleware architecture used in the MADIS project for maintaining the consistency of replicated databases. Instead of reinventing wheels, MADIS makes use of basic resources provided by conventional database systems (e.g. triggers, views, etc) to achieve its purpose, to a large extent. So, the underlying databases can perform more efficiently many of the routines needed to support any consistency protocol, the implementation of which thus becomes much simpler and easier. MADIS enables the databases to simultaneously maintain different metadata needed for different replication protocols, so that the latter can be chosen, plugged in and exchanged on the fly as online-configurable modules, in order to fit the shifting needs of given applications best, at each moment.

FOBr: a version-based recovery protocol for replicated databases

Within the field of databases that are deployed in distributed environments there is a need to guarantee consistency among replicas and availability among nodes despite of network disconnections and node crashes. A recovery protocol, such as FOBr, manages the database update of a recovering node as it might have missed many transactions during its absence. FOBr does so without stopping data access, and minimizing its interference with the active nodes, their memory usage, and the network traffic. The recovery protocol we propose is very suitable when a fast recovery of the missed data is required. It balances the recovery issues among nodes very fairly and due to this, out-dated data will promptly be recovered. Thus accesses to data that is not out-dated are not interrupted or delayed in any way. These characteristics allow regular transactions to be performed during the recovery process.

CLOB: communication support for efficient replicated database recovery

Replication protocols using an eager update propagation strategy commonly need a reliable broadcast service; i.e., a broadcast primitive with atomic delivery and, in some cases, also with total order. This communication service provides some appropriate features for the recovery tasks, although in some cases this leads to partial blocking of the replica taken as the source in the updating process. CLOB is a framework for reliable broadcast protocols that log the missed update messages in case of failure, being able to automatically resend these updates when the faulty destinations recover. This behaviour is easily configurable and allows an efficient recovery mechanism in case of short-term failures, which can be combined with other version-based recovery protocols in order to manage long-term outages.

Ensuring Progress in Amnesiac Replicated Systems

Replication is used for providing highly available and fault-tolerant information systems, which are constructed on top of replication and recovery protocols. Important aspects when designing these systems are the failure model assumed and the progress condition assumed. Replicated transactional systems usually assume the crash-recovery with partial amnesia failure model, and the majority partition progress condition. But, despite the large use of such combination most of these works do not handle accurately a very special phenomenon that can lead to diverging states in different replicas causing, when happening, critical situations.

Recovery strategies for linear replication

Replicated systems are commonly used to provide highly available applications. In last years, these systems have been mostly based on the use of atomic broadcast protocols, and a wide range of solutions have been published. The use of these atomic broadcast-based protocols also has aided to develop recovery protocols providing fault tolerance to replicated systems. However, this research has been traditionally oriented to replication systems based on constant interaction for ensuring 1-copy-serializability. This paper presents a general strategy for recovery protocols based on linear interaction as well as providing other isolation levels as snapshot isolation. Moreover, some conclusions of this work can be used to review recovery protocols based on constant interaction.

Supporting amnesia in log-based recovery protocols

Replicated systems are commonly used to provide highly available and fault tolerant applications, based on the use of replication and recovery protocols. Traditionally, the literature has focused on replicated systems which adopt the fail-stop failure model which presents good performance levels for replicated systems managing few state. This paper points out how the crash-recovery with partial amnesia failure model presents a better accuracy for replicated systems with huge state, but how its use has the amnesia phenomenon drawback. Then, the paper analyzes this phenomenon and how to deal with it in a basic configuration using a log-based recovery approach. Analyzing after, how it is supported and managed with other replication configurations.

An Improved Optimistic and Fault-Tolerant Replication Protocol

In this paper, a protocol is proposed that provides the advantages of lazy approaches, forestalling their traditionally found disadvantages. Thus, our approach reduces the abortion rates, and improves the performance of the system. It can also use a dynamic computation of the protocol threshold, approximating its results to the optimal ones. In addition, fault tolerance has been included in the algorithm, using a pseudo-optimistic approach, and avoiding to block any local activity, and minimizing the interference over any node in the system.

Flexible Management of Consistency and Availability of Networked Data Replications

We describe a family of three replication protocols, each of which can operate in three different modes of consistency. The protocols are tailored to satisfy the availability demands of interconnected databases that have a high degree of data locality. The protocols accomplish a grade of transaction completion which does not compromise availability, and ensure the consistency of replicas also if a transaction needs to be aborted. Flexibility of query answering is understood as optimizing the tradeoff between consistency and availability, i.e., between correctness and timeliness of query answering. This is achieved by choosing an appropriate protocol alternative, and changing the consistency mode of operation during the session, as appropriate for a given transaction.

A middleware architecture for supporting adaptable replication of enterprise application data

Enterprise-wide data replication improves availability, performance, fault-tolerance and dependability of database services within and between different subunits in medium and large enterprises. The overhead of consistency management of replicated data can be tamed by built-in DBMS functionality. Different kinds of applications, e.g., update-intensive online transaction processing, cyclical updates for data warehousing, knowledge sharing of repository data, and so on, have different requirements for the availability, up-to-dateness and consistency of replicated data. Thus, replication strategies should be adaptable to the specific requirements of diverse enterprise applications. We describe a middleware for enterprise-wide data replication. It maintains meta data for several protocols, so that the replication strategy can be adapted on the fly to the actual needs of an application.