Database high availability using SHADOW systems

Abstract

Various High Availability DataBase systems (HADB) are used to provide high availability. Pairing an active database system with a standby system is one commonly used HADB techniques. The active system serves read/write workloads. One or more standby systems replicate the active and serve read-only workloads. Though widely used, this technique has some significant drawbacks: The active system becomes the bottleneck under heavy write workloads. Replicating changes synchronously from the active to the standbys further reduces the performance of the active system. Asynchronous replication, however, risk the loss of updates during failover. The shared-nothing architecture of active-standby systems is unnecessarily complex and cost inefficient.In this thesis we present SHADOW systems, a new technique for database high availability. In a SHADOW system, the responsibility for database replication is pushed from the database systems into a shared, reliable, storage system. The active and standby systems share access to a single logical copy of the database, which resides in shared storage. SHADOW introduces write offloading, which frees the active system from the need to update the persistent database, placing that responsibility on the underutilized standby system instead. By exploiting shared storage, SHADOW systems avoid the overhead of database-managed synchronized replication, while ensuring that no updates will be lost during a failover. We have implemented a SHADOW system using PostgreSQL, and we present the results of a performance evaluation that shows that the SHADOW system can outperform both traditional synchronous replication and standalone PostgreSQL systems.iii

Leveraging Scale-Up Machines for Swift DBMS Replication on IaaS Platforms Using BalenaDB

“…While BalenaDB focuses on DBMS instance replication for load balances, the goal of other approaches is to attain the availability of the DB service. SHADOW [11] is an efficient hot-standby system for DBMS instances. It shares the transaction log between active and standby DBMSs and forces the standby DBMS to checkpoint itself to mitigate I/O overhead on the active DBMS.…”

“…BalenaDB replicates a DBMS in instances running on the machine where its master instance runs. To protect DB services against failures, we need to use other replication schemes that generate replicas on another physical machine and/or other datacenters [11], [12].…”

Rethinking database high availability with RDMA networks

“…When a machine p fails, the system maintains its high availability by promoting one of p's backup nodes as the new primary and fails over to that node. There are many different implementations of activepassive replication both in academic projects [9,15,18,39] and in commercial databases [4] (such as Postgres Replication [17], Oracle TimesTen [19], and Microsoft SQL Server Always On [26]). Active-passive schemes are often implemented through log shipping where the primary executes the transaction, then ships its log to all its backup replicas.…”

A Method of Transparent Graceful Failover in Low Latency Stateful Microservices

“…However, modern database high availability solutions, including the aforementioned ones, focus on reducing the failover time. Either by increasing consistency of replicas by means of sharing storage [12] sharing memory [13], novel persistence framework for container based deployments [14], novel replication algorithm [15],. or by improving connection pooling towards persistent systems [16,17].…”