39th Annual IEEE/IFIP International Conference on Dependable Systems and Networks.
Database server clustering, used ubiquitously for dependability and scalability, is commonly based on one of two competing approaches. The first, a shared storage cluster such as Oracle RAC, is based on distributed locking and a distributed cache invalidation protocol [3]. Its main advantage is flexibility, as one uses as many nodes as required for processing the workload and to ensure the desired availability, while the storage is configured solely according to the desired storage bandwidth and disk resilience. Unfortunately, it can be implemented only with a deep refactoring of server software; the reliance on distributed locking limits scalability; and by directly sharing a physical copy of data it becomes harder to ensure data integrity. These reasons make it costly to develop and deploy, as attested by most of the mainstream database servers not providing this option. The second, a shared nothing cluster such as C-JDBC, can be implemented strictly at the middleware level by intercepting client requests and propagating updates to all replicas [1]. The resulting performance and scalability is good, especially, with currently common mostly read-only workloads. Moreover, as each replica is physically independent, this strategy can easily cope with a wider range of faults [2]. The main problem is that in a shared-nothing cluster a separate physical copy of data is required for each node. Therefore, even if a only few copies are required for dependability, a large cluster with hundreds of nodes must be configured also with sufficient storage capacity for hundreds of copies of data. The naive combination of both approaches by simply sharing the data volume would obviously not work, as asynchronous propagation of updates and nondeterministic physical data layout would lead to data.