Database Reference
In-Depth Information
High availability
The simplest database deployments are run as a single instance on a single server. This sort
of configuration is highly vulnerable to interruption: if the server is affected by a hardware
failure or network connection outage, the application's ability to read and write data is com-
pletely lost until the server is restored. If the failure is catastrophic, the data on that server
might be lost completely.
A
master-follower
architecture improves this picture a bit. The master instance receives all
write operations, and then these operations are
replicated
to follower instances. The ap-
plication can read data from the master or any of the follower instances, so a single host be-
coming unavailable will not prevent the application from continuing to read data. A failure
of the master, however, will still prevent the application from performing any write opera-
tions, so while this configuration provides high read availability, it doesn't completely
provide high availability.
Cassandra, on the other hand, has no
single point of failure
for reading or writing data.
Each piece of data is replicated to multiple nodes, but none of these nodes holds the author-
itative master copy. If a machine becomes unavailable, Cassandra will continue writing
data to the other nodes that share data with that machine, and will queue the operations and
update the failed node when it rejoins the cluster. This means in a typical configuration,
two nodes must fail simultaneously for there to be any application-visible interruption in
Cassandra's availability.
Tip
How many copies?
When you create a keyspace—Cassandra's version of a database—you specify how many
copies of each piece of data should be stored; this is called the
replication factor
. A replic-
ation factor of 3 is a common and good choice for many use cases.
