m
Our Mission Statement
This is Photoshop's version of Loremer Ipsn gravida nibh vel velit auctoregorie sam alquet.Aenean sollicitudin, lorem quis bibendum auci elit consequat ipsutis sem nibh id elit.
Follow Us
Top
High Availability - VoltDB
10942
page-template-default,page,page-id-10942,page-child,parent-pageid-10675,mkd-core-1.0,highrise-ver-1.0,,mkd-smooth-page-transitions,mkd-ajax,mkd-grid-1300,mkd-blog-installed,mkd-header-standard,mkd-sticky-header-on-scroll-up,mkd-default-mobile-header,mkd-sticky-up-mobile-header,mkd-dropdown-slide-from-bottom,mkd-dark-header,mkd-header-style-on-scroll,mkd-full-width-wide-menu,mkd-header-standard-in-grid-shadow-disable,mkd-search-dropdown,mkd-side-menu-slide-from-right,wpb-js-composer js-comp-ver-5.4.4,vc_responsive
VoltDB / Product  / Features and Benefits / High Availability

High Availability

Never Go Down

VoltDB may be a strongly consistent system, but it has been engineered since day one to continue running in the face of as many kinds of failures as possible. Whether hardware, software, or network failures, VoltDB systems can continue serving requests under a wide array of changing conditions.

Inter-Cluster Replication

VoltDB allows a user to specify how many copies of each datum the cluster will store. If you tell the database to store three copies, two machines can fail and the cluster will continue operating. Failure detection and failure handling are automatic and backed by strong consensus guarantees. Zero committed data is lost. VoltDB will even place replicas on different blade chassis, or virtualized replicas on different host systems if you give it a few hints.

VoltDB can transparently handle node failures, network failures and even many kinds of the dreaded network partitions without loss of availability and without a split-brain situation. Replacing failed nodes is a one line shell command, all data and configuration is pulled from live servers in the background, while your database continues doing it’s job.

VoltDB intra-cluster replication has even been tested by Kyle Kingsbury of the Jepsen project. He was unable to find fault with VoltDB 6.4 under a brutal series of tests. We continue to pass those same tests on all subsequent versions.

Operations

  • Want to change your application to add a new procedure or table?
  • Want to modify the SQL in one of your procedures?
  • Want to expand your cluster to support more load?
  • In any of these cases, VoltDB will perform the operation without impacting your workload.

Not only does VoltDB stay up, but its background operations have amongst the lowest overhead of all clustered databases. How much slower will your cluster be after some nodes have failed? It’s unlikely you’ll notice. How much slower while replacing those nodes? Ditto.

We’ve built these systems with Telco-Grade operations in mind and degraded performance can be as bad as downtime.

Intra-Cluster Replication

When one cluster in one datacenter isn’t enough, VoltDB supports connecting two or more clusters using our Database Replication (DR) functionality. DR is an asynchronous, bi-directional replication of either a complete database or just a subset of tables.

It supports two main configurations.

  1. Active-Passive Replication establishes a primary/replica relationship between clusters, where only one may accept active writes at a time, and external input is required to failover to the replica cluster.
  2. Active-Active Replication establishes a many-to-many relationship between writable clusters. Changes to one cluster are pushed to other with conflict-detection if needed.
    Active-Active replication is in use by nearly all of our telco and finance customers allowing them to build global applications with local latency and extreme availability.