Database Replication Using Generalized Snapshot Isolation

Abstract

Generalized snapshot isolation extends snapshot isolation as used in Oracle and other databases in a manner suitable for replicated databases. While (conventional) snapshot isolation requires that transactions observe the "latest" snapshot of the database, generalized snapshot isolation allows the use of "older" snapshots, facilitating a replicated implementation. We show that many of the desirable properties of snapshot isolation remain. In particular, read-only transactions never block or abort and they do not cause update transactions to block or abort. Moreover, under certain assumptions on the transaction workload the execution is serializable.An implementation of generalized snapshot isolation can choose which past snapshot it uses. An interesting choice for a replicated database is prefix-consistent snapshot isolation, in which the snapshot contains at least all the writes of locally committed transactions. We present two implementations of prefix-consistent snapshot isolation. We conclude with an analytical performance model of one implementation, demonstrating the benefits, in particular reduced latency for read-only transactions, and showing that the potential downsides, in particular change in abort rate of update transactions, are limited.

Managing Multiple Isolation Levels in Middleware Database Replication Protocols

“…There have been multiple database replication protocols in the update everywhere server architecture with a constant server interaction [11,19,17,9,12,23]. Many of them share the following characteristics, proving to be extremely adequate for replication purposes.…”

“…Most current database replication protocols aim to provide support for only the serialisable [22,19,17] or snapshot isolation levels [9,12], since they are needed by a wide variety of applications. However, there have also been some works that have studied multiple levels of isolation, either providing protocols for each of them [11,23] or by specifying new definitions of such levels [4,2].…”

Scalable Transactions in the Cloud: Partitioning Revisited

“…On one hand, we have that primary copy solutions [21] do not scale well for update intensive scenarios, apart from the single point of failure, because the maximum throughput is limited by the primary. On the other hand, update everywhere solutions [22,23] use a total order broadcast facility [24] to generate the one copy history (i.e., update transactions are delivered to all replicas in the same order). It is well-known that total order broadcast does not scale well after a few tens of replicas have been added [25].…”

Correctness Criteria for Database Replication: Theoretical and Practical Aspects

“…The majority of the protocols proposed in the literature ensure either 1SR (e.g., [5,7,12]) or SI (e.g., [3,18]). However, some applications may require stronger guarantees.…”