Database Reference
In-Depth Information
Address Status Load Range Ring
134439585115453215112331952664863163581
192.168.1.7 Up 3.53 KB 41654880048427970483049687892424207188 |<--|
192.168.1.5 Up 2.95 KB 134439585115453215112331952664863163581 |-->|
Decommissioning a Node
Decommissioninga node means pulling it out of service. When you call
decommission
on No-
detool, you're calling the decommission operation on Cassandra's
StorageService
class.
Say that we have two nodes in the ring:
eben@morpheus$ bin/nodetool -host 192.168.1.5 ring
Address Status Load Range Ring
134439585115453215112331952664863163581
192.168.1.7 Up 4.17 KB 41654880048427970483049687892424207188 |<--|
192.168.1.5 Up 3.59 KB 134439585115453215112331952664863163581 |-->|
Now we want to decommission the 1.7 node. You can issue the
decommission
argument to No-
detool to pull one of the nodes out of service, as shown here:
$ bin/nodetool decommission -h 192.168.1.7
After issuing this command, it will wait for some time, as configured. By default, this is 30
seconds. Nodetool won't print anything further, but the server logs will. On our 1.5 node—the
node that we're keeping—we see the following output after issuing the
decommission
com-
mand:
DEBUG 13:59:00,488 Disseminating load info ...
DEBUG 13:59:40,010 Node /192.168.1.7 state leaving, token
41654880048427970483049687892424207188
DEBUG 13:59:40,022 Pending ranges:
/192.168.1.5:
(134439585115453215112331952664863163581,41654880048427970483049687892424207188]
DEBUG 14:00:00,488 Disseminating load info ...
DEBUG 14:00:10,184 Running on default stage
DEBUG 14:00:10,184 StreamInitiateVerbeHandler.doVerb STREAM_INITIATE 4084
DEBUG 14:00:10,187 no data needed from /192.168.1.7
DEBUG 14:00:10,551 Node /192.168.1.7 state left, token
41654880048427970483049687892424207188
DEBUG 14:00:10,552 No bootstrapping or leaving nodes -> empty pending ranges for
Keyspace1
INFO 14:00:18,049 InetAddress /192.168.1.7 is now dead.
