In the previous blog post (http://newblog.voltdb.com/intro-voltdb-command-logging), Ariel Weisberg described how VoltDB’s command logging feature works. He also briefly mentioned how we replay command logs during the recovery process. In this post, I am going to focus on the replay process and discuss how VoltDB recovers from catastrophic events.

Goals of Command Logging Replay

The goals of command logging replay are pretty simple:

1. Ensure that the recovered database is 100% accurate to the last usable transaction in the command log
2. Complete the recovery process in the shortest possible time

Command logging obviously adds important new functionality to VoltDB’s infrastructure.  … Read more

VoltDB’s new command logging feature reduces the window of data loss during a cluster wide failure from single digit minutes (the window between snapshots) to zero. Command logging can be tuned to give you the same amazing latency and throughput you get from VoltDB, even on a single 7.2k SATA disk. Our unique approach to log based durability exploits the determinism and replication inherent in VoltDB’s architecture to avoid the overhead and latency of ARIES style logging.

How We Log

A command log is kept at every node and contains partially ordered stored procedure invocations. As stored procedure invocations arrive … Read more

We, at VoltDB, are excited to tell you about the command logging feature that we’ve been working on this summer. We’ve built this feature because our customers asked for it, and they’ve given us some great feedback on how it should work. Here’s a heads up to get you thinking about how you can make use of this new functionality.

So what’s command logging and why are we so excited about it? First, let me remind you of VoltDB’s snapshot functionality. A database snapshot is exactly what it sounds like — a point-in-time copy of the database contents written to … Read more

Deciding whether to handle your workload as a sequential set of synchronous operations or an asynchronous batch isn’t just a .NET topic, but a larger design decision with any VoltDB application. This week we review the pros and cons of each choice in a general context and then as it pertains specifically to your .NET implementations.

By now, you probably have a good idea of how VoltDB works: each partition is its own processing engine, and while, within a partition, work is performed sequentially, each partition is essentially autonomous so that all perform work in parallel.

As we discuss below, … Read more

In this blog post I want to build on the example given by John and dig a little deeper into how VoltDB ensures global ordering and replication in the face of failures.

I am going to drill down on the following paragraph

Site 1 and site 4 both receive the message from the initiator. They then each do the same work in parallel. Since each individual site performs transactions one at a time, the transaction information is put into a queue at site 1 and queue at site 4. Work is pulled from the queues at

… Read more

Let’s say a developer, Dan, is working on a new website. He’s decided to use VoltDB as part of his data management layer. One of Dan’s users requests a dynamically generated page and the code that generates that page sends a request to Dan’s VoltDB cluster. The excitement begins.

Dan’s code asks the VoltDB client library to execute his procedure named “GetUserProfile” and provides the user’s handle, “dbNerd”, as a parameter. The client library maintains persistent connections to … Read more