How to check Apache Cassandra cluster status with nodetool

Cluster membership can look fine from the service manager while Apache Cassandra still sees a node as down, leaving, joining, or moving. nodetool status reads the local node's view of the ring so an operator can confirm which nodes are ready before maintenance, repair, or application handoff.

The first two letters in each node row carry the status check. The first letter is U or D for up or down, and the second letter is N, L, J, or M for normal, leaving, joining, or moving. UN is the expected steady-state signal for a serving node that has joined the ring.

The Owns (effective) column depends on the keyspace replication strategy, so use the application keyspace when ownership distribution matters. In large clusters or during network faults, run the command from more than one Cassandra node because each node reports its own gossip view.

Related: How to check Apache Cassandra service status
Related: How to view Apache Cassandra logs
Related: How to connect to Apache Cassandra with cqlsh

Steps to check Apache Cassandra cluster status with nodetool:

  1. Run the cluster status check from a Cassandra node. 
    $ nodetool status
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load        Tokens  Owns (effective)  Host ID                               Rack
UN  10.0.0.11   114.73 KiB  16      100.0%            8f4f6e2d-9f74-4f5a-a85f-43df5d4fcb21  rack1

    nodetool uses the local Cassandra JMX listener by default. Put global JMX options before the command name when checking another node, such as nodetool --host 10.0.0.12 --port 7199 status.

  2. Confirm that every expected serving node shows UN in the leftmost column.

    D means the node is down from this node's view. L, J, and M mean the node is leaving, joining, or moving rather than fully normal.

  3. Repeat the check from another Cassandra node when the first result is unexpected. 
    $ nodetool --host 10.0.0.12 --port 7199 status

    Different nodes can report different up or down views while gossip is converging or a network partition is present.

  4. Scope ownership to the application keyspace when token ownership is part of the check. 
    $ nodetool status app_data
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load        Tokens  Owns (effective)  Host ID                               Rack
UN  10.0.0.11   104.36 KiB  16      100.0%            8f4f6e2d-9f74-4f5a-a85f-43df5d4fcb21  rack1

    Replace app_data with the keyspace whose replication factor and datacenter placement need to be checked.

  5. Show storage ports when several Cassandra instances share an address. 
    $ nodetool --print-port status
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address          Load        Tokens  Owns (effective)  Host ID                               Rack
UN  10.0.0.11:7000   114.73 KiB  16      100.0%            8f4f6e2d-9f74-4f5a-a85f-43df5d4fcb21  rack1

    --print-port is a global nodetool option, so it appears before status.

  6. Check gossip when status output is empty, stale, or missing expected peers. 
    $ nodetool statusgossip
running

    If gossip is not running, inspect the Cassandra service and logs before trusting the ring view.
    Related: How to check Apache Cassandra service status
    Related: How to view Apache Cassandra logs