Database Reference
In-Depth Information
architecture, it's really simple to let a node join on the fly. Also, instead of generating
the initial token value, we also can set up this with virtual nodes.
Prior to the Cassandra 1.2 release, we needed to manually assign one token range to
each data node using the token-generator tool, but with virtual nodes now we can as-
sign multiple token ranges per node. Using the
num_tokens
property, we can assign
a number of virtual nodes per data node, which means holding a large number of smal-
ler data ranges. This is very handy when we need to replace or rebuild a dead node.
A dead node means a node that becomes unresponsive to gossip/intercommunica-
tion with other nodes. Such a failure may happen because of network or hardware fail-
ures. Each node can be a primary or replica node for data distributed across the Cas-
sandra cluster. When a dead node is ready to join a Cassandra ring, it must stream all
data from replica nodes. Without virtual nodes, the contiguous token assignment intro-
duces a lot of overhead as data needs to stream from various primary and replica nodes.
With virtual nodes, more tokens assigned to each node mean smaller and more hetero-
geneous data distribution, which means the same volume of data can be streamed in
from multiple nodes! Obviously this would be much faster.
Let's explore replacing a dead node with a new one in a sample exercise.
Replacing a Dead Node
Sometimes it's possible to have a few dead nodes in a cluster. That is, they are not re-
sponding to gossip and need to be replaced with new ones. Replacing a dead node in a
running Cassandra cluster is straightforward. Let's explore it with a sample exercise
continued from the previous one.
1.
First, let's bring down node 2 and check the ring status:
vivek@vivek-Vostro-3560:~/software/
local-cluster/node1$ bin/nodetool ring
Datacenter: datacenter1
==========
Address Rack Status State
Load Owns Token
3074457345618258602
127.0.0.1 rack1 Up Normal 50.44
