Database Reference
In-Depth Information
['-9223372036854775808', '-4611686018427387904', '0',
'4611686018427387904']
Note that the preceding calculation assumes that you are using
Murmur3Par-
titioner
, which ships as default with Cassandra Version 1.2 onwards. If you
have
RandomPartitioner
, instead of calculating the tokens manually, let the
tooling provided by Cassandra do it for us. We will see it in the
Load balancing
section.
Note
Be aware that token numbers are partitioner-dependent and in this case it is
Ran-
domPartitioner
. The other thing is if you see the old and new tokens, you
will realize that the first node is not going to be touched. It is already set to the
correct value. Also, it will be profitable in the old node, 2. The old node 3 gets as-
signed to the token values of node 2 and node 3 in the new configuration. This
way, we'll minimize data movement across the nodes (streaming). The new node
will have the initial token as described by node 4 in the previous results.
•
Start the new node
: Edit
cassandra.yaml
of the new node to set the appro-
priate value of the cluster name, initial token, seed node, listen address, and any
other customization as per the environment (such as broadcast address, snitch, se-
curity, data file, and so on). Now, start the node by issuing the
cassandra
com-
mand or starting the Cassandra service. Wait for a couple of minutes as the new
node gets introduced with the cluster. The cluster now looks pretty lopsided:
$ # /opt/cassandra/bin/nodetool ring
Note: Ownership information does not include
topology; for complete information, specify a keyspace
Datacenter: us-east
==========
Address Rack Status State
Load Owns Token
4611686018427387904
10.10.21.228 1a Up Normal 4.7
GB 25.00% -9223372036854775808
10.10.21.169 1a Up Normal 4.71
