Review for Paper: 38-RemusDB: Transparent High Availability for Database Systems

Review 1

Databases for high availability typically rely on internal DBMS techniques to ensure availability guarantees. This causes problems because the solutions for in-database high availability are complex, making them more difficult to program and for DBAs to administer. It would be simpler to use a virtualization layer for high availability, so that the complexity of providing failover could be pushed out of the database. Unfortunately, simply running a conventional DBMS on top of a Remus virtual machine (HA software) causes significant performance overhead, due to excessive data shipping for checkpointing between nodes.

RemusDB aims to provide the simplicity of a DBMS on top of a virtualization layer, but with a specialized virtualization system designed to reduce overhead by limiting data shipping. One method RemusDB uses to reduce data shipping is memory optimization. In memory optimization, RemusDB sends only compressed diffs of changes to memory pages that are about to be written to disk, instead of the entire page. To do this, the page is XOR-ed with its previous version, yielding a string of mostly zeroes, which is then run-length encoded. RemusDB also tracks which pages in the buffer pool have not been altered since being read from disk, and does not send their contents in a checkpoint, instead merely sending information on how to generate those pages. This reduces data shipping at checkpoints.

Another method RemusDB uses to reduce overhead of shipping data to backup nodes is commit protection. RemusDB allows certain packets not to be buffered until checkpoint time, if those packets will not cause a transaction’s commit logic to be violated. For example, messages indicating operations within a transaction can be sent unbuffered to backup nodes, while the commit message itself must be buffered until the next checkpoint. This amortizes the sending of data to backup nodes and increases throughput.

One limitation of RemusDB is that although the purpose of a virtualization layer approach to high availability is to remove complexity from the DBMS, RemusDB’s commit protection methods require code changes to the database. Thus, RemusDB is not fully “transparent” to the database. The system would be easier to use, if perhaps a bit slower, if RemusDB were designed such that no database changes are needed to use it.



Review 2

What is the problem addressed?
This paper presents a technique for building a high-availability (HA) database management system (DBMS).

Why important?
Maintaining availability in the face of hardware failures is an important goal for any database management system (DBMS). Users have come to expect 24 hours and 7 days a week availability even for simple non-critical applications. Many database systems are designed to continue serving user requests with little or no disruption even when hardware fails. However, this high availability (HA) comes at a high cost in terms of complex code in the DBMS, complex setup for the database administrator, and sometimes extra specialized hardware.

1-­‐2 main technical contributions? Describe.
RemusDB provides active-standby HA and relies on VM checkpointing to propagate state changes from the primary server to the backup server. In this paper, they present an active-standby HA solution that is based on running the DBMS in a virtual machine and pushing much of the complexity associated with HA out of the DBMS, relying instead on the capabilities of the virtualization layer. The virtualization layer captures changes in the state of the whole VM at the active host (including the DBMS) and propagates them to the standby host, where they are applied to a backup VM. The virtualization layer also detects failure and manages the failover from the active host to the standby, transparent to the DBMS. During failover, all transactional (ACID) properties are maintained and client connec- tions are preserved, making the failure transparent to the DBMS clients.
To implement commit protection, the communication channel between the database server and the client needs to provide abstractions to dynamically enable or disable buffering of network messages, i.e., abstractions to protect or de-protect the channel.

1-­‐2 weaknesses or open questions? Describe and discuss
I like the idea of decoupling high availability and the DBMS which offers a transparent service by the cloud infrastructure on which the DBMS runs. However it trades diversity and flexibility to achieved this modularization.


Review 3

This paper presents a new high availability system called RemusDB, which is designed to provide simple transparent DBMS high availability at the virtual machine layer. In short, RemusDB is implemented in the virtualization layer and uses asynchronous virtual machine state replication to provide transparent HA and failover capabilities. It provides active-standby HA and relies on VM checkpointing to propagate state changes from the primary server to the backup server.This paper first introduces the overview of the system and background of HA RDBMS. Then it moves to the design details of RemusDB, including the techniques of memory checkpointing, facilities to reduce the latency added to the client-server communication path, etc. Then it provides performance evaluation on several main DBMS and traditional benchmarks. Finally, it discusses related and future work.

The problem here is that there is a strong need to maintain high availability in the face of hardware failure, however, to achieve this HA comes at a high cost. It is important to maintain HA, for example, some businesses can suffer costly disruptions when hardware fails, so it is important to continue serving user requests even when hardware fails. However, to achieve such HA needs complex code in the DBMS, complex setup for DBA, and extra specialized hardware. Therefore, a reliable, cost-effective HA solution is needed and this paper presents one such solution called RemusDB.

The major contribution of the paper is that it provides a good HA solution that is transparent to the DBMS, runs on commodity hardware, and incurs a low performance overhead. RemusDB can provide active-standby HA and make DBMS highly available with little or no code changes which imposes little performance overhead. Here we will summarize some key elements:

1. simple approach to memory checkpointing (copy pages of memory that change from the active host, transmit of the network to backup hosts)
2. compress checkpoints by sending less data and protecting less memory
3. relax output commit by allowing the DBMS to be buffered until the next checkpoint
4. protect transaction control messages (commit protection)

One interesting observation: this paper is very innovative and it provides a good HA solution with plenty of detailed experiments. One possible weakness is that it does not provide many other existing HA solutions. It might be better to provide comparison between different HA solutions so that we can know if RemusDB can outperform others.


Review 4

PROBLEM:
The paper proposed the idea of making DBMS high available by leveraging VM HA technology called Remus and performing DBMS specific performance optimizations for it.
One of the key challenges in providing HA lies in maintaining database consistency in the face of failures
and minimizing the impact of HA on performance.Active/standby replication is complex to implement in the DBMS, and complex in propagating the transaction log, atomic handover from primary to backup on failure, redirecting client requests to backup after failure.This brings virtual machines (VM) into picture.

TECHNICALITIES:
RemusDB is based on Remus, which is part of the Xen hypervisor.It maintains replica of a running VM on a separate physical machine and extends live migration to do efficient VM replication while providing transparent failover with only seconds of downtime.
Remus uses an epoch based checkpointing system in which it divides time into epochs and performs a checkpoint at the end of each epoch. The primary VM is suspended and all state changes are copied to a buffer.The primary VM is then resumed and an asynchronous message is sent to the backup containing all state changes.After a failure, backup resumes execution from the latest checkpoint.
Remus provides a consistent view of execution to clients in which any network packets sent during an epoch are buffered until the next checkpoint.It guarantees that a client will see results only if they are based on safe execution and same principle is also applied to disk writes.
The authors then explaining why Remus can be used to do DBMS HA without breaking ACID properties and then discussed 4 different optimizations (3 memory related, 1 network related) DBMS specific optimizations.
To reduce the size of checkpoint synced from active to standby node, they use asynchronous checkpoint compression in which not the whole original page content is sent to checkpoint since most modifications between consecutive checkpoint change only part of a page.
To avoid checkpointing pages that can be read from disk, they also track disk read operations and put metadata into checkpoint data and standby server can use these small size metadata to reconstruct those memory pages.
Network optimization which is DBMS specific leverages transaction semantic to avoid Remus’s TCP packet level protecting. In this optimization, the underlying VM only need to protect Transaction related message such as acknowledge to ABORT and COMMIT message from client. This will reduce the latency a lot for irrelevant messages, such as those that comprising the transaction itself but it is not fully transparent. Commit protection is also implemented using setsockopt which again lacks complete transparency.
Finally with experimental evaluation, behavior of RemusDB during failure is studied along with overheads during normalized execution using TPC-C and TPC-H benchmarks.They also cover the effect of DBSize and DB Buffer pool size on RemusDB

DRAWBACKS:
RemusDB is described only to work with VM, which has an overhead especially for DBMS due to its I/O sensitivity. This overhead of running DBMS inside VM is not considered by the authors.It would have been great to compare the performance of RemusDB with other HA systems, such as MySQL HA cluster.
Remus’s checkpoint is unaware of the transaction running inside it, so the standby server is consistent with active server in system level, but not transaction level which I assume means that the latest state of standby server may not be consistent in terms of ACID, and hence can’t be used to serve reading requests under specific isolation level.


Review 5

This paper purposes a novel way to provide high availability for database systems. Current system involve complex code within the DBMS, and this code is often tightly integrated into the rest of the database. An alternative is RemusDB, a system that use Virtual Machines and replication to maintain HA, instead of complex DBMS code. This is interesting, considering that the last paper was read was advocating against a VM per database model(and for multiple databases per node), and this paper proposes multiple VMS per database. However, the paper are attempting to solve different problems.

The system takes frequent, increment checkpoints of the complete state of the virtual machine on the active server. These checkpoints are moved over to the standby virtual machine, where they are installed. If the standby does not receive these checkpoints, it assumes that the master is down, and it becomes the active system. The paper goes into a fair amount of detail in how disk accesses can be minimized, and how the amount of data transmitted in checkpoints can be reduced. Both of these can lead to dramatic performance improvements.

One downside to this system is the overhead of the full VM. VM tend to not uses hardware efficiently - maintaining their own buffer pages, etc., when compared to a single machine. In the face of a large, rapidly changing database, the cost to maintain such high availability could lead to long response times. However, from their experiments so far, the overhead does not appear to be that bad.

This paper shows an exciting proof of concept. The future work launched from it could be very exciting. For example, what if we saw the rise of decoupling of recovery systems from database systems, and it became a seamless microservice. If we could remove the large, monolithic components from database systems, I think we could see great increases in performance, as well as other areas.



Review 6

Problem and solution:
Most of the database management systems require high availability, which means it is still available when facing hardware failures. The problem proposed in the paper is that current implementations of high availability are expensive with complex code in DBMS, complex setup for the database administrator and extra specialized hardware. It is costly for an DBMS to provide HA guarantees.

The solution proposed is to find out a reliable, cost-effective HA solution, transparent to the DBMS, runs on commodity hardware and incurs a low performance overhead, which is RemusDB. It is a virtual machine checkpointing system based on Remus, a general VM checkpointing system with high performance overhead on database systems, to support DBMS high availability.

Main contribution:
The main contribution of the paper is talking about the design of RemusDB. It supports high availability based on virtual machine replication. The system run database on VM while put the checkpointing work associated with HA out of the DBMS. The HA relies on the capabilities of the virtualization layer, which can capture the changes of the whole VM, detect failure and manage the failover by working with the active host and the standby host. It is very clever to add high availability to VM instead of DBMS itself. Since more DBMS are being run in VM for convenience and easiness, adding HA to VM allows them to use HA with very few modifications. The approach minimizes the setup cost and optimized the performance.

The original version of RemusDB is Remus, which has very high performance overhead for database. One reason is that a lot of states need to be backup during a checkpoint. RemusDB makes the techniques to be completely transparent to the DBMS to solve the problem. The other reason is that the database workload can be sensitive to network latency. To reduce the latency, RemusDB requires minor modifications to original DBMS code. The experiment shows that it improves the performance significantly.

Weakness:
The weakness of the paper is its experiments. It compares different optimizations with different configurations, while it does not compares the performance with other DBMS that already supports high availability. So it is unclear that how is the performance of RemusDB comparing to other HA databases.


Problem and solution:
Most of the database management systems require high availability, which means it is still available when facing hardware failures. The problem proposed in the paper is that current implementations of high availability are expensive with complex code in DBMS, complex setup for the database administrator and extra specialized hardware. It is costly for an DBMS to provide HA guarantees.

The solution proposed is to find out a reliable, cost-effective HA solution, transparent to the DBMS, runs on commodity hardware and incurs a low performance overhead, which is RemusDB. It is a virtual machine checkpointing system based on Remus, a general VM checkpointing system with high performance overhead on database systems, to support DBMS high availability.

Main contribution:
The main contribution of the paper is talking about the design of RemusDB. It supports high availability based on virtual machine replication. The system run database on VM while put the checkpointing work associated with HA out of the DBMS. The HA relies on the capabilities of the virtualization layer, which can capture the changes of the whole VM, detect failure and manage the failover by working with the active host and the standby host. It is very clever to add high availability to VM instead of DBMS itself. Since more DBMS are being run in VM for convenience and easiness, adding HA to VM allows them to use HA with very few modifications. The approach minimizes the setup cost and optimized the performance.

The original version of RemusDB is Remus, which has very high performance overhead for database. One reason is that a lot of states need to be backup during a checkpoint. RemusDB makes the techniques to be completely transparent to the DBMS to solve the problem. The other reason is that the database workload can be sensitive to network latency. To reduce the latency, RemusDB requires minor modifications to original DBMS code. The experiment shows that it improves the performance significantly.

Weakness:
The weakness of the paper is its experiments. It compares different optimizations with different configurations, while it does not compares the performance with other DBMS that already supports high availability. So it is unclear that how is the performance of RemusDB comparing to other HA databases.


Review 7

This paper introduces RemusDB, a virtual machine strategy to gain high availability for the DBMS while not making the DBMS more complex. RemusDB adds a virtualization layer between client and DBMS servers and checkpoint the state from active VM to the backup VM. Based on this, RemusDB build several optimization techniques to get rid of the overhead for virtual machine: large memory usage and network load latency.

RemusDB maintains a stand-by VM on a separate machine and periodically updates the backup VM with the changes from the active VM using checkpointing, which includes the whole machine state, which supports transparent failover with limited down time. In addition, RemusDB provides a consistent view of the executions from the user point of view. It buffers the network packages since last checkpoint and does not release until the next checkpoint has been made.

Advantages:
RemusDB provides high availability with low cost in maintaining the virtual machine. It implements several memory optimizations to reduce the performance overhead in the traditional VM strategy. It implements LRU cache tracking frequent changing page to avoid unnecessary messages and compress checkpoint. In addition, it avoid checkpoint the unnecessary memory state by tracking the disk reads. The overhead of RemusDB is essentially small and those changes are not complex in code.

Disadvantages:
If there are a huge amount of memory change which exceeds the capacity of the LRU, then the LRU cache may not be suitable to track recent changing page under many circumstances. Though LRU is a prediction for the most recently used job, if, for instance, the workload requires high usage of disk pages with frequent check and modification or there exists many concurrent and frequent updates for different pages, this strategy may not work well and the performance may go down.


Review 8

Problem/Summary:

High availability (HA) is an important requirement for database systems, especially if the databases are being provided as a service. One approach to ensuring HA is by using an active-passive approach, where each system is mirrored so that in case the active server fails, the passive server can take over. Implementing this in a DBMS would result in a lot of complex code (log shipping, maintaining consistency and recoverability). Instead, a system called Remus runs both the active and passive servers in a VM, and ships the VM states (RAM, CPU, Disk, network states) from the active to the passive. This reduces the complexity of the DBMS implementation, and also keeps the passive warm so that recovery is quick. However, the authors of this paper point out some downfalls of Remus, and present their system called RemusDB to fix these issues.

Since shipping VM state can be expensive, RemusDB uses compression on state diffs before sending state to the passive, so that less data needs to be sent. Additionally, if certain RAM pages can be completely rebuilt from disk, they don’t need to be shipped.

Normally, in order to maintain consistency, Remus holds back acknowledgement messages until all state is shipped to the passive. Once this is done, all messages are sent to the client. However, there is no need to do this except for COMMIT acknowledgement, since there is only inconsistency if the server says it has successfully committed when it has not. Therefore, RemusDB only holds back commit acknowledgement messages until state is successfully shipped to the passive.

Strengths
The authors have clearly made improvements to Remus by identifying and getting rid of inefficiencies.

Weaknesses/Open Questions:
It seems like Remus and RemusDB are designed to provide HA for single server systems, but can VM replication be used for distributed systems as well?

How can RemusDB be used for k-safety? Is RemusDB less efficient than a distributed database which provides 2-safety, since a distributed database uses all of its nodes to serve queries, while the passive server in RemusDB does not?



Review 9

The paper proposes a new system called RemusDB, which uses virtual machine checkpointing to provide a high-availability (HA) database systems.

As we have seen in the previous paper of Relational Cloud, it is becoming more popular to oursource databases into the cloud, meaning they are likely to run inside virtual machines (VM). The approach of the paper tries to utilize such scenario and uses VM checkpointing to backup the database and perform migration upon failure with a backup VM. I think the approach itself is smart, but it has a few problems.

First, VM checkpointing of a DBMS involves an extra overhead of storing the entire state of the system compared to other backup techniques, which only need to backup the current consistent data. Second, their approach is active-standby, which is much less effective in terms of utilization of resource compared to an active-active setup. I do not think that the approach in the paper is well justified and people are going to use the technique in the paper instead of existing HA solutions for each DBMS.

In conclusion, I was quite disappointed with the approach in the paper, which seems to provide a little to no advantages over existing HA solutions with active-active setup.



Review 10

This paper discusses providing high database availability through the use of RemusDB. RemusDB uses VM checkpointing in order to maintain an updated copy of the state of the database. To lower the overhead of the amount of data sent in a checkpint, RemusDB uses an LRU based cache. Pages in the cache are XORed with the new version and sent using RLE. Otherwise, the uncompressed version is sent. The checkpoint also act as a heartbeat to let the backup VM know if the active VM is still working. If the messages are delayed for a period of time, the active VM is assumed to have failed and the backup VM is used. To the user, there is no change in database behavior since the outward appearance of the database remains unchanged.

RemusDB is nice in that it does not require changes to the DBMS clients or the DBMS. Furthermore, since it uses VMs it has many useful properties such as VM migration. However, from my understanding, it seems like the system doubles the hardware requirements of the database and the overhead from checkpoint still seems pretty significant even with the use of the LRU cache. I am also not sure how this design scales to multinode databases. It seems that the database must fit entirely in one VM rather than being allowed to be distributed across multiple machines. My guess would be that this would require multiple copies for each machine the database exists on and it would probably have very complicated communication management since now each machine needs to track the state of the other machines. I would have liked much larger database sizes in the last experiment to demonstrate scale up.


Review 11

Motivation for RemusDB:

The purpose of RemusDB is to provide a high-availability DBMS. High availability is important because users expect continuous availability in the applications they use and businesses suffer costly disruptions when hardware fails. DBMS that provide high availability often come at high costs (complex code, specialized hardware). Remus is cost effective, reliable that runs on commodity hardware and has low performance overhead. It is implemented in the virtualization layer, and uses asynchronous virtual machine state replication to provide transparent high availability and failover capabilities. For TPC-C workloads, RemusDB has a 29% performance improvement running under PostgreSQL and 30% improvement under MySQL compared to Remus. RemusDB also recovers from failure in less than 3 seconds and incurs only a 3% performance overhead with respect to an unprotected VM.

Details on RemusDB:

Performance overhead from Remus and other virtual machine checkpointing systems are from a large number of states that need to be transferred from the primary VM to the backup VM during a checkpoint because database systems use memory intensively, and from added latency to the communication path because of added mechanisms used to ensure client-server communication during network latency. RemusDB extends Remus by optimizing with reduced checkpoint size and reduced latency by adding network buffering. The memory overhead from checkpoints can be halfed when the implementation of an LRU-based cache of often changing pages from previous checkpoints is asynchronous and allows the VM to resume execution in parallel with compression and replication. Ignoring changes to certain parts of memory also reduces the checkpoint size, so that clean pages in the buffer pool that can be read from disk and dirty buffer pool pages that can be read from transaction log are not sent to the Remus checkpoints. The disk read tracking optimization is thus implemented to add annotations to the replication stream to indicate that the sectors on the disk may be read, allowing for the remote reconstruction of the page.

Commit protection is implemented by switching the client/server communication channel to protected mode when the message received from the client is either COMMIT or ABORT, performing all actions needed to commit or abort a transaction through writing the COMMIT or ABORT log record to disk, indicating the successful commit or abort transaction to the client though the protected channel, and switching the channel back to unprotected mode. In the presence of failovers, RemusDB maintains completeness because it never loses transactions. Memory and network optimizations work well for OLTP workloads, and solely memory optimizations work best for DSS style workloads. The overhead of RemusDB increases with a larger buffer pool.

Strengths of the paper:

I liked that the paper provided a comprehensive description of Remus, which it was built on, and then clearly describes where RemusDB improves in reducing performance overhead and latency. I also liked that the paper addresses failover and provides complete experimental results from Remus on top of both MySQL and Postgres.

Limitations of the paper:

I would’ve liked to see more real world examples of where RemusDB is used, since the experimental results were all on benchmark tests. I would’ve also liked to see some pseudocode of how the checkpoint compression and commit protection are implemented. The paper states that the overhead increases as the buffer pool size increases. I would have liked to see more discussion on why that 10% of extra overhead is acceptable.


Review 12

This paper titled "Remus DB: Transparent High Availability for Database Systems" introduces a database system called Remus DB which is built using the high availability technology named Remus. This system is proposed to allow existing databases that are currently in use to use Remus to improve reliability. This paper talks about memory optimizations and commit protection, and evaluates their modifications using the TPC-C and TPC-H benchmarks. The behavior of the proposed system is described for different DBMS systems, buffer pool sizes, and database sizes.

The advantages of this paper come from its combination of a technology for high availability with database technologies. The Remus system shows comparable performance to other systems and has a very fast recovery time. Section five of this paper shows detailed evaluation of their system using two different types of benchmarks. They show the effects for Postgres and MySQL and they vary the database size and the buffer pool size used in their experiments. This gives us a view of how the system performs in a variety of real world circumstances. This paper convincingly shows the effectiveness of RemusDB.

The drawbacks from this paper come from what is sacrificed in order to obtain high availability. The operations involved in using RemusDB incur a small amount of overhead but it should be noted that this overhead makes it unsuitable for all applications. Additionally, issues that the authors are aware of should also be considered. They mention that TCP connection states are not maintained during failover. This can cause the connection to stall. They say that they do not currently have a solution for this problem but users of RemusDB should be aware of the problems that failover can cause.



Review 13

Part 1: Overview
This paper presents a building high availability database technique. This technique is pretty general that it only requires little customization or even no customization. This approach is Remus based and is a commodity HA solution implemented in the virtualization layer. Ther approach provides a practical means for existing, deployed database systems to get better. There are literature of providing HA by replicating machine state at the virtualization layer. RemusDB however imposes a significant performance improvement in terms of overhead. Some DBMS-level HA solutions provide similar features, but these features add more code and complexity to the already complex systems. During normal operation, Remus takes frequent, incremental checkpoints of the complete state of the virtual machine on the active server. These checkpoints capture the entire state of the active VM, which includes disk, memory, CPU, and network device state.

As RemusDB uses a brute force method to copy all pages of memory that change from the active host and transmits them over the network to some back up host. Memory optimization therefore is implemented. Compressing checkpoints is beneficial when the amount of data to be replicated is large, and the data contains redundancy. This method can help reduce network communication and thus reduce overhead.

Part 2: Contributions
High availability is crucial in many applications and at the same time is also hard to achieve. Users expect 24×7 always online availability even for simple non-critical applications, and businesses can suffer costly and embarrassing disruptions when hardware fails. During failover, all transactional (ACID) properties are maintained and client connections are preserved, making the failure transparent to the DBMS clients.

Disk read tracking and memory deprotection in addition to buffer pool can read data from disk into a memory page without marking the page dirty.

Commit protection is used to reduce overhead on controlling output commits.Client and server communications always result in long sessions and thus would increase overhead. Remus reduces communication time by buffering TCP packages.

Part 3: Drawbacks
The database workloads incur incur a performance overhead of up to 32% as compared to an unprotected DBMS. They identify the sources of this overhead and develop optimizations that mitigate the problems.



Part 1: Overview
This paper presents a building high availability database technique. This technique is pretty general that it only requires little customization or even no customization. This approach is Remus based and is a commodity HA solution implemented in the virtualization layer. Ther approach provides a practical means for existing, deployed database systems to get better. There are literature of providing HA by replicating machine state at the virtualization layer. RemusDB however imposes a significant performance improvement in terms of overhead. Some DBMS-level HA solutions provide similar features, but these features add more code and complexity to the already complex systems. During normal operation, Remus takes frequent, incremental checkpoints of the complete state of the virtual machine on the active server. These checkpoints capture the entire state of the active VM, which includes disk, memory, CPU, and network device state.

As RemusDB uses a brute force method to copy all pages of memory that change from the active host and transmits them over the network to some back up host. Memory optimization therefore is implemented. Compressing checkpoints is beneficial when the amount of data to be replicated is large, and the data contains redundancy. This method can help reduce network communication and thus reduce overhead.

Part 2: Contributions
High availability is crucial in many applications and at the same time is also hard to achieve. Users expect 24×7 always online availability even for simple non-critical applications, and businesses can suffer costly and embarrassing disruptions when hardware fails. During failover, all transactional (ACID) properties are maintained and client connections are preserved, making the failure transparent to the DBMS clients.

Disk read tracking and memory deprotection in addition to buffer pool can read data from disk into a memory page without marking the page dirty.

Commit protection is used to reduce overhead on controlling output commits.Client and server communications always result in long sessions and thus would increase overhead. Remus reduces communication time by buffering TCP packages.

Part 3: Drawbacks
The database workloads incur incur a performance overhead of up to 32% as compared to an unprotected DBMS. They identify the sources of this overhead and develop optimizations that mitigate the problems.



Review 14

===OVERVIEW===
RemusDB is introduced in this paper as a transparent high availability for database systems. It offers lower overall costs to uses by moving much of the operational burden of provisioning, configuration, scaling, performance tuning, backup, privacy, and access control from the database users to the service operator. Three major challenges are there in this area, and they are efficient multi-tenancy, elastic scalability, and database privacy. To support those targets, three key features are discussed in this paper.

===DESIGN===
The system is composed of the following parts: on the trusted platform, we have client nodes as user applications and JDBC-Client. On the untrusted platform we have front-end nodes and admin nodes which contains partitioning engine and placement and migration engine, which further talk to CryptDB with encrypted communication. The database use partitioning for 1. to scale a single database to multiple nodes, 2. and to enable more granular placement and load balance on the back-end machines compared to placing entire databases.

Resource allocation is a major challenge when designing a scalable database like this. To solve this problem, a new database and workload are placed arbitrarily on some set of nodes for applications. The system is composed of 1. resource monitor, 2.combined load predictor, 3. consolidation engine to realize placement functionality.

===STRENGTH===
The design has strong enforcement on the three major issue for cloud database systems, which are efficient multi-tenancy, elastic scalability, and database privacy.

===WEAKNESS===
The completeness of the design is questionable for the following reasons:
1. They didn't test the database against different TPC-C query mixture.
2. The system efficiency cannot be stated with one single system resource setup.
Overall, the design and the discussion is great, which makes the experiment section a little to short.


Review 15

RemusDB is a technique to provide high availability to any database with little or no customization and with lesser overhead in comparison to the usually available HA platforms. This is especially important considering that a system failure is inevitable and the customers not having access to the system in that while is unacceptable.

RemusDB has its failover mechanism is based on virtual machine replication. Typically, high availability is implemented using another database system on another machine in sync with the primary DBMS using either log shipping or delta changes in data. But here, they wish to shift the mechanism to the virtualization layer that captures the state of the primary VM including the changes to its database. One of the major ways in which they reduce the performance impact is by letting the compression and replication happen asynchronously in the domain 0 where the LRU cache is present while execution is resumed in the primary database system.

One of the major advantages that RemusDB has is that the failover is completely transparent to the users especially because the secondary VM is always warmed-up ready to jump into execution if and when necessary. Another feature that I really liked was that if a particular page is read by the primary database, RemusDB does not mark it as dirty thereby reducing the delta that needs to be taken care of by the secondary VM. They have also taken into consideration the idea if the data is changed by another process, and it is read only by the DB, since the failover is handled at the VM level, they ensure that those changes are propagated.

RemusDB specifies that there is not much information lost in case of a failure since it controls the outgoing network packets until the next checkpoint is not committed. However, in case of high network latency, this can result in really slow execution and the users might have to wait a long while for the results. Also, I was not really sure how this could be extended to multiple failovers since large companies hardly have only one backup server.

Overall, it seems like a good solution for high availability in widely used open source databases.


RemusDB is a technique to provide high availability to any database with little or no customization and with lesser overhead in comparison to the usually available HA platforms. This is especially important considering that a system failure is inevitable and the customers not having access to the system in that while is unacceptable.

RemusDB has its failover mechanism is based on virtual machine replication. Typically, high availability is implemented using another database system on another machine in sync with the primary DBMS using either log shipping or delta changes in data. But here, they wish to shift the mechanism to the virtualization layer that captures the state of the primary VM including the changes to its database. One of the major ways in which they reduce the performance impact is by letting the compression and replication happen asynchronously in the domain 0 where the LRU cache is present while execution is resumed in the primary database system.

One of the major advantages that RemusDB has is that the failover is completely transparent to the users especially because the secondary VM is always warmed-up ready to jump into execution if and when necessary. Another feature that I really liked was that if a particular page is read by the primary database, RemusDB does not mark it as dirty thereby reducing the delta that needs to be taken care of by the secondary VM. They have also taken into consideration the idea if the data is changed by another process, and it is read only by the DB, since the failover is handled at the VM level, they ensure that those changes are propagated.

RemusDB specifies that there is not much information lost in case of a failure since it controls the outgoing network packets until the next checkpoint is not committed. However, in case of high network latency, this can result in really slow execution and the users might have to wait a long while for the results. Also, I was not really sure how this could be extended to multiple failovers since large companies hardly have only one backup server.

Overall, it seems like a good solution for high availability in widely used open source databases.


Review 16

RemusDB: Transparent High Availability for Database Systems paper review

In this paper, the RemusDB is introduced to prove the author’s technique of building high-availability database systems. we refer to a database system is highly available (HA) if it remains accessible to its users in the face of hardware failures. And the user would expect 24x7 availability even for simple database applications in today’s context. The key challenge of providing HA system is maintaining database consistency in the face of failures and minimizing the impact of HA on performance.

The major contribution of this paper is that the author proposed the use of virtual machines to achieve transparent active standby design. In short, the idea of active standby replication can be stated as:
1.firstly, primary server accepts user requests and performs database updates.
2.secondly, changes to database propagated to backup server by propagating the transaction log.
3. lastly, backup server takes over as primary upon failure
And in the RemusDB, the design provide HA as a service from the underlying virtualization infrastructure. The virtual machine checkpointing is used to maintain replica of a running VM on a separate physical machine. Remus can provide a consistent view of execution to clients, since any network packets sent during an epoch are buffered until the next checkpoint guarantees that a client will see results only if they are based on safe execution. As stated in the paper, RemusDB implements optimizations to reduce the overhead of protection for database workloads recovers from failures in less than 3 seconds while incurring 3% overhead. In terms of memory optimization, the author utilized the fact that database workloads tend to modify more memory in each epoch as compared to other workloads. So RemusDB reduce checkpointing overhead by (1) sending less data asynchronous checkpoint compression (ASC) and (2).protecting less memory disk read tracking (RT) memory deprotection. As for network optimization, Remus requires buffering of outgoing network packets and exploits consistency and durability semantics provided by database transactions.

However, there are still weakness in this design of RemusDB:
1.first of all, it doesn’t count for double failure: since maintaining availability in the face of hardware failures is an important goal for any DBMS, it only uses one standby server, if that server also fail at the same time, the database could lose user data.
2.secondly, the author claimed that RemusDB can make any database system highly available with little or no code modifications by exploiting the capabilities of virtualization. However, the truth is, to make RemusDB completely transparent to the DBMS, the commit protection of RemusDB requires code changes to the client communication layer of a DBMS, which is not trivial to implement.



Review 17

RemusDB provides DBMS with high availability feature with reasonable overhead. It uses asynchronous virtual machine state replication to support transparent failover and builds optimizations to minimize the overhead in memory usage and network latency.

RemusDB minimizes the overhead of virtual machine replications mainly in following ways:

1.Checkpoint compression. It uses an LRU cache to maintain all the frequent changing pages and only sends the different part between two versions when the page resides in the cache. It reduces the amount of data sends to the backup VM.

2.Tracking disk reads. It is similar to the copy-on-write strategy. The replica will not read a page from disk as primary do until the page is modified by the primary.

3.It provides an interface for DBMS to decide which network packet to be buffered until next checkpoint. In this way, the memory space is saved by avoiding store the unprotected packet.

Advantage:
RemusDB pushes the complexity to gain HA out of the DBMS. It uses virtual machine replication to gain capacity in fault tolerance and support high availability with very fast failover when the active server is down. In addition, it extracts the high availability feature from the DBMS and make it possible to provide high availability as a service.



Disadvantage:
RemusDB, though has small performance overhead, still consumes more resources to provide the virtualization compared to an unprotected DBMS. As a result, there might be higher hardware cost for this solution. In addition, there comes load balancing, resource management and capacity issues when there are limited physical machines and many virtual servers.


Review 18

The authors provide failover database replication by taking advantage of virtual machine replication. The idea is to replicate VM state rather than deal with replication within the DBMS. The authors detail an existing system called Remus and how it achieves this goal. They notice that much of the overhead of replicating entire VMs can be eliminated by employing the use of a few optimizations: compression, not replicating pages that can be retrieved from disk, and taking advantage of transactional guarantees at the DBMS level rather than at the TCP-level. The authors conduct a performance comparison using TPC-C and demonstrate that RemusDB has low overhead despite achieve fast failover.

The main idea used by the authors is that by coupling different layers of their software stack, they were able to reduce the overhead of VM-level replication.

Though the authors achieved low-overhead, I disagree with their approach. The authors claim that the system provides transparent high-availability for databases. However, it couples the database implementation with VM-replication which breaks several abstractions. I would argue that this makes future enhancements hard to develop, it makes RemusDB hard to deploy, and I would argue that few software vendors would want to maintain or provide such tightly coupled systems. After all, equivalent functionality could be provided by providing replication within the database system, so perhaps a different approach could be used (some sort of userspace middleware) that achieved the same effect but without the coupling.


Review 19

This paper describes a highly available DBaaS system called RemusDB. Users of database systems have now come to expect 24x7 uptime even on applications that do not necessarily need it. It is difficult, though, to provide high availability without introducing complicated code, a complicated setup, or specialized hardware. Some examples of highly available databases are Amazon’s DynamoDB and Google’s BigTable. Both of those systems have complicated setups that allow them to be highly abvailable.

RemusDB introduces a simple, cost-effective solution that utilizes virtual machine replication to provide high availability for users. Every database on the system has two servers: a primary server and a secondary server. All transactions are first run on the primary server, but commit and abort messages are not sent back to the clients immediately. Checkpoints are created every so often when the exact state of the primary server is copied to the secondary server. At this time, all commit and abort messages are sent to the clients because we know that the transactions will be durable. During a failure, the secondary server starts up from the previous checkpoint. Any changes to the database since the previous checkpoint are reverted and have to be processed again. There is not much overhead when switching from the primary server to the secondary server because the total state of the server is copied including the state of the memory and the buffer pool.

I believe these are the positives of the paper:

1. The idea provides a simple way to give users high availability and failure handling is not complicated.
2. There are extensive tests on the performance of RemusDB with different scenarios and modified parameters.

Overall, this paper gives very detailed explanations of the highly available database, but I do have one concern about the paper:

1. The check pointing system runs once about every 100ms as seen in the experimental settings. Would it be possible that we have a workload that changes so much in the database that just creating the checkpoint would be longer than the 100ms?



Review 20

This paper discusses RemusDB. Remus is an existing system that provides high availability (HA) to database systems by checkpointing the state of the VM in which the DBMS is being run and copying this state to a backup VM in order to allow for low failover times when the primary VM crashes. Remus takes an overly simplistic approach to checkpointing, transmitting every page of memory that has been modified since the last checkpoint. It also buffers all network packets in order to prevent speculative commits from becoming visible to the user. These approaches incur a significant performance overhead as compared to an unprotected VM. RemusDB makes several optimizations to the base Remus system in order to reduce the overhead of providing high availability.

RemusDB uses two optimizations to avoid sending as many memory pages per checkpoint. First, it uses a cache in domain 0 of the VM hypervisor to track frequently modified pages, then sends only the compressed XOR of the pages. Second, it avoids sending some pages if they have not been modified since being read to memory, or if the modifications made to them can be recreated from the transaction log. The other major optimization made in RemusDB is commit protection. The practice of buffering all network packets in the base Remus system significantly increased network latency. Therefore, RemusDB buffers only packets containing commit or abort messages. This allows the majority of packets to be sent unbuffered on an unprotected channel, which improves network latency. This can cause some active transactions to be aborted on failover, but this transparent to the user, and no committed transactions will be lost.

In experimental trials, the authors determined that RemusDB removed much of the unnecessary overhead incurred by Remus. While Remus performed at around 70% capacity in comparison to an unprotected VM, RemusDB performed at 90-97% of base capacity. The authors noted that implementing commit protection offered no benefit in data warehouse scenarios, since network latency was not a factor in these cases. Additionally, the authors noted that RemusDB scaled much better than Remus in warehouse scenarios, incurring 3-6% overhead cost on the largest databases, as compared to 10-32% overhead incurred by Remus.

My primary concern with this paper is that some of the modifications they had to make for their optimizations to work seemed a bit hacky. At the beginning of the paper, they stated that part of the purpose of systems such as RemusDB is to move the responsibility for failover and availability out of the DBMS into applications that can be used as add-ons. However, the authors had to modify Linux and expose TCP metadata in order to get commit protection to work. The authors stated that they intend to address this in the future, but it represents a significant obstacle in the meantime, as you don’t want users of your product to have to modify their OS in order to get your application working.



Review 21

This paper is an introduction to RemusDB. RemusDB is a DBMS that is focused on providing high availability as much as possible. There are many databases that focus on this and their downsides are it is very complex code and not easy to understand for the user. RemusDB is aware that crashes are going to happen so it’s mindset is to provide the fastest possible recovery time so it becomes available again quicker, with less data loss, and more readable code.

RemusDB takes advantage of the fact that most DBMSs now are running out of virtual machines for a variety of features that virtual machines offer. They make the case that high availability is a feature that you can add onto a VM similar to other features. They also put a heavy focus on making the code more transparent to the user (easier to understand what is happening). I think this is the most important innovation of this paper because accomplishing that task alone without a performance degradation is important. They were able to (or at least claim to) accomplish that task as well as improve performance by ~30% and the ability to recover from failure in 3 seconds. Recovering from failure in 3 seconds is phenomenal because for almost all non computerized requests by the time the second one is sent the failure recovery will have occurred and all will work normally.

It is hard to believe that it works so well because the ideas seem pretty simple from a high level. For checkpointing it copies all the pages from memory with a change and sends them over the network to a backup host. They were able to do this effectively by just compressing and limiting the amount of data that is sent effectively. Also certain parts of memory are not protected and “selectively ignored”.

Overall, this is a good paper with good results and great graphical representation of those results. They were able to provide higher availability and a performance boost while having simple code that is easy to interface with existing DBMSs. I think they also have a good direction and suggestions for future work and this sounds like a promising paper! Overall, pretty solid.



Review 22

The motivation for this paper is to propose a system with high availability, i.e. even in the fact of failure on the component level, it still remains accessible to users (reminiscent of Dynamo DB). Many systems, in their methods for dealing with availability, make sacrifices in other areas, namely performance overhead. Another area is through consistency; how can one maintain correctness even through hardware failures without additional expense or overhead. The goal of RemusDB is to provide a simple/cheap high availability database system.

A typical implementation technique I’ve seen used in industry is to have a primary server and a backup server, where the primary server is handling all live server with the backup standing ready, quietly receiving transaction logs. When the primary fails, the backup springs to life to take over. However, this is not so easy to implement in practice; the transaction logs need to be propagated safely, and transactions between primary/backups need to be atomic. In addition, this information propagation needs to incur minimal overhead. The RemusDB solution is to utilize the virtualization facilities in order to provide high availability as a VM service. While the virtual machine running a database system incurs a relatively large amount of bulk overhead (OS operations, sandboxing, resource management), the RemusDB system aims to capitalize on the VM layer to be resource-aware and increase throughput with virtualization. They even explicitly state that their DBMS-aware system for checkpointing VM state. What happens is essentially the primary/backup model, but instead of propagating DBMS data, VM state is recorded and transferred. This way, there doesn’t even need to be any change in the DBMS infrastructure; any DBMS can be made highly available in this setup without significant modification, if any. So instead of having to reload transaction logs, VM data is resumed from the last checkpoint upon failures. However, in the case of failures, this is potentially unsafe, as it may be based on failed nodes. To remedy this, requests to the node are queued until a checkpoint is made, so that only safe executions are passed on to the client.

My first question, and the thing they immediately address, is the fact that VM check pointing would cost a lot of overhead, in addition to the overhead incurred by guaranteeing protection through the buffering protocol. They go further in depth regarding optimizations for DBMS protection. Since DB workloads tend to be highly active in their memory modification compared to other workloads, their two main solutions are (1) sending less data overall by caching compressed pages of the VM state that tend to be modified more frequently (since mem-writes often only change small portions of memory) or (2) selectively ignoring/choosing to send/backup data that is important to back up. If a significant portion data can be regenerated from disk reads, then we probably don’t need to send an uncompressed version every time. The key method they use is keeping track of disk reads and the memory addresses to which they are mapped, associating pages in memory with addresses on disk. That is, synchronization of clean buffer pool pages is unnecessary, so RemusDB only needs to sync dirty buffer pool data. I think these optimizations are necessary, and are clever ways of not having to redundantly send information back and forth. I wonder if any of these nuances (of redundant data that is the same in bytes) can be exploited as a security vulnerability, or if they are always true for VM systems.

The second massive area of optimizations lies in network optimization. If they were to protect every packet request coming in, this would cost a large amount of overhead (<= 32%). The key idea behind their network optimization is to only protect transaction control information (commit/abort protection), since any transaction that has been committed is also safe. This makes sense, as the hierarchy of DBMS semantics lends itself to only needing to incur latency when these commit operations arrive (so latency is not increased by an order of magnitude). They gave some discussion to the setsockopt() addition to the linux system, which exposes failover for in-flight transaction that may be managed by the recovery handler (aborting transactions running unprotected).

They dedicated a hefty portion of the paper to the experimental evaluation to thoroughly convince us of RemusDB’s effectiveness. Everything seems as though it gives what was promised, with comparable performance to the Remus system itself (though I am not sure Remus and RemusDB can be directly compared. Then again, I don’t really know what Remus does exactly, so I am unsure of this statements durability). I felt that they were very thorough by also including effects of database structure on RemusDB effectiveness, but I wonder what the whole storage overhead was for storing VM state, and how that changes depending on workload and data changed. However, since they probably only need to care about TPC-C score, I can see why this was not included (but I am still curious). Overall, I thought this was quite a thorough paper and had a good motivation for creating a system with high availability that can be implemented on top of (or rather, under) existing DBMS systems.


Review 23

This paper explains technique to build a high-availability (HA) DBMS that can be applied to any DBMS with little or no customization based on Remus. The motivation behind the paper is because as an HA solution implemented in virtualization layer, Remus incurs high performance overhead (up to 32%). The paper tries to identify the sources of the problem and mitigate the problem.

The paper starts with system overview. Two servers are used, in which one of them acts as active host and the other one as spare (standby VM). When active host is down, the workload is then transferred to standby VM. Remus’s checkpoint captures the entire state of active VM, so after failover, the DBMS in the standby VM begins execution with warmed up buffer pool. For DBMS, checkpoint size for Remus may be large, so there needs to be optimization. The paper explains about memory optimization, which includes asynchronous checkpoint compression (ASC) and disk read tracking (RT). The ASC technique enables VM to send less data by compressing checkpoints. The RT technique protects less memory, since it does not mark the read page as dirty but adds an annotation to the replication stream indicating the sector on disk that may be read to reconstruct the page remotely. Another optimization technique is commit protection (CP). This protocol ensures that committed/aborted transactions exposed by the primary VM are guaranteed to survive a failure: the client only receives the acknowledgement of the commit/abort after state changes made by this transaction at the primary VM have propagated to the backup VM as part of Remus Checkpoint. The paper continues with experimental result. It tracks the effect of implementing ASC, RT, and CP in two different workload benchmark (TPC-C and TPC-H). It shows that while RT gives little performance benefit for TPC-C, but significant gain for TPC-H. On the contrary, ASC and CP gives significant performance increase to TPC-C, but little benefit for TPC-H. Benefit of RT also decreases as buffer size increases. In terms of scalability, RemusDB with network and memory optimization gives best performance at all scales. Lastly, the paper mentions several related work in high availability techniques used in DB system. One of them, active-standby HA, is the basis of RemusDB, in which RemusDB uses asynchronous active-standby. Alternatives to that are shared access and multi-master HA. It also briefly discusses virtualization technique.

The main contribution of this paper is providing (and explaining) the design decisions to be employed on Remus in order to ensure that the setup effort and performance overhead is minimal. The paper also shows how to implement these decision in a DBMS-aware VM checkpointing system (RemusDB). In addition, this paper addresses the issue of whether HA is best implemented within the DBMS or as a service infrastructure below it.

However, the paper does not explain the possibility of workload awareness. The paper shows that there are different results for each optimization technique when each is applied to different type of workload. Since certain techniques are more usable for certain condition, it should be better for RemusDB to be able to recognize workload type immediately before deciding which optimization technique to use.--



Review 24

The purpose of this paper is to present improvements on RemusDB, an existing highly-available DBMS add-on to do reduce the amount of overhead incurred by its users while still maintaining high availability for the user’s data.

A key technical insight provided in the author’s implementation is the use of Virtual Machine replication and this system runs on commodity hardware alongside existing DBMSs. Their reliance on VMs allows for the exploitation of properties and functionalities of the virtualization layer that decreases the complexity of their high availability solution when compared to existing methods. Their novel contributions are methods to reduce the performance overhead in this VM replication scheme that has been developed by others. RemusDB contributes several memory usage optimizations to increase the performance. It increases transparency with the underlying DBMS so that smaller amounts of data must be shipped during checkpointing via checkpoint compression. Additionally, RemusDB optimizes for decreasing client-server latency by adding in a layer that is not transparent to the DBMS to allow for the prioritization of specific kinds of communication.

As far as strengths go, this paper has strong foundations in existing research and the reduction in overhead that they present empirically is impressive. I don’t know if this system is actually used in the real world, but in this paper it shows promise. Additionally, the authors pose the interesting question of whether all HA utilities should be considered as separate from the DBMS for a reduction in complexity. They also thoroughly discuss the results they find in the experimental evaluation section.

As far as weaknesses go, I would have been more satisfied with the paper if it had a better conclusion. They kind of throw in a future works discussion without fully summarizing their contributions and what was shown in the paper.



Review 25

Paper Title: RemusDB: Transparent High Availability for Database Systems
Paper Summary:
This paper proposes a novel technique that helps reducing the overhead introduced by systems that are used to protect DBMSs, such as Remus. The proposed model is based on Remus and can perform better, introducing lower overhead, as shown by the experimental results provided in the paper. The value in this paper comes from the fact that it solves a contradiction, where securing a DBMS introduces overhead on performance, which put security and performance of a DBMS on the two opposite ends of a seesaw. As claimed by this paper, there are two major sources of the overhead introduced by systems under Remus and the like. First one is that they are memory heave and the second one is that they are sensitive to network latency. The RemusDB addresses those two issues.

Paper Stength:
The major strength of this paper is the contribution made by the proposed method. While security and performance being on the opposite side of the trade-off, the proposed method in this paper helps overcome the bottleneck.

Paper Weakness:
It could help to add detailed explanations of what each figure represents and what are the conclusions to be drawn from the figures into the captions. Because with only the titles below the figures, in some cases such as Figure 8 and 9 it is not that trivial to get the sense what the authors want to demonstrate.



Paper Title: RemusDB: Transparent High Availability for Database Systems
Paper Summary:
This paper proposes a novel technique that helps reducing the overhead introduced by systems that are used to protect DBMSs, such as Remus. The proposed model is based on Remus and can perform better, introducing lower overhead, as shown by the experimental results provided in the paper. The value in this paper comes from the fact that it solves a contradiction, where securing a DBMS introduces overhead on performance, which put security and performance of a DBMS on the two opposite ends of a seesaw. As claimed by this paper, there are two major sources of the overhead introduced by systems under Remus and the like. First one is that they are memory heave and the second one is that they are sensitive to network latency. The RemusDB addresses those two issues.

Paper Strength:
The major strength of this paper is the contribution made by the proposed method. While security and performance being on the opposite side of the trade-off, the proposed method in this paper helps overcome the bottleneck.

Paper Weakness:
It could help to add detailed explanations of what each figure represents and what are the conclusions to be drawn from the figures into the captions. Because with only the titles below the figures, in some cases such as Figure 8 and 9 it is not that trivial to get the sense what the authors want to demonstrate.



Review 26

Summary:
This paper introduces RemusDB, a virtualization layer that can provide high availability DBMS for any DBMS with little code change, with a trade off of performance overhead. The RemusDB is based on Remus, a virtualization layer HA solution that provide transparent HA and failover based on asynchronous virtual machine state replication. This paper also identifies the optimization problems to solve the overhead problem.
One of the optimization is based on the memory checkpoint algorithm of Remus: instead of sending all the pages in memory at checkpoint, it transmits less data with less redundancy with less memory. Another memory optimization is based on a protocol that dynamically enable or disable buffering of network message. This paper also gives a complete experiment with TPC-C and TPC-H to shows the performance of RemusDB.

Strengths:
1. This paper provides a solution for HA system on building infrastructure on virtualization layer. It gives a good insight on solving DBaaS problems, instead of incorporate distributed layer with database, we can actually pushdown that to the low level layers such as virtualization or even network protocol or operating system.
2. The HA solution provide by this paper can be easily incorporate with existing single machine DBMS to provide HA system, involving low code change, which can be easily adopted by existing services.

Weakness:
1. Although it is clear that utilizing HA solution on virtualization layer can be a good solution for HA system, it is still true that the overhead is high. This has been proved in the paper, and fully discussed with current DBMS implementation that sacrifice consistency. However, a design decision has to be made by the users when choosing these two approaches for HA system.
2. In this version, there is still code change need to incorporate with Remus, although a future work has been discussed to provide no code effort for HA transition.



Review 27

This paper introduced RemusDB, a high-available (HA) DBMS. RemusDB leverages asynchronous virtual machine level state replication to provide transparent HA and failover capabilities. The prior work such as Remus can provide similar functionality but with significant overhead. RemusDB takes a similar approach but identifies the source of overhead and applies optimization on such aspects. RemusDB can make any DBMS highly available with little or no code changes and it imposes little performance overhead compared to Remus. There are two sources of overhead. First, database systems use memory intensively, so the amount of state that needs to be transferred from the primary VM to the backup VM during a checkpoint is large. Second, database workloads can be sensitive to network latency, and the mechanisms used to ensure that client-server communication can survive a failure add latency to the communication path. To address these issues, RemusDB applies several optimizations.
Sending Less Data: RemusDB compresses checkpoints by only sending the actual changes to these pages, thus achieves a considerable reduction in replication traffic.
Protecting Less Memory: memory pages whose contents can be regenerated, or alternatively can be safely thrown away may be ignored during checkpointing. RemusDB uses disk read tracking and memory deprotection.
Commit protection: A significant amount of latency comes from holding uncheckpointed transaction. RemusDB relax output commit by allowing the DBMS to decide which packets sent to the client should be protected (i.e., buffered until the next checkpoint) and which packets can be unprotected (i.e., sent unbuffered). The DBMS should be able to protect transaction control messages. The messages comprising the contents of the transaction can remain unprotected.

The main advantage of this paper is disk read tracking. RemusDB interposes on disk read requests from the virtual machine and tracks the set of memory pages into which the reads will be placed, and the associated disk addresses from which those pages were read. This approach saves sending the read disk over to stand-by virtual machine. This optimization largely reduces the memory replication overhead.

Though claiming that RemusDB is largely isolated from the DBMS itself, it still requires the modifying the code for DBMS. It would be more feasible if the full isolation can be achieved.