A dead Apache Cassandra node can remain in the ring after the process, host, or disk is permanently gone. Leaving that membership entry in place keeps the cluster assigning token ranges to a node that cannot stream data or receive repairs, so removal should happen only after the node is confirmed lost rather than temporarily down.
nodetool removenode tells a live Cassandra node to remove a dead node's host ID from cluster membership. Cassandra then assigns the dead node's token ranges to surviving nodes and streams any needed data from remaining replicas; nodetool decommission is the safer path when the departing node is still running.
The command is destructive from the cluster's point of view because the old host ID should not rejoin afterward. Confirm keyspaces have enough surviving replicas for the ranges being reassigned, decide whether a replacement-node workflow is more appropriate, and keep a repair window ready when the node was down longer than the hinted handoff window or missed writes.
Steps to remove a dead Apache Cassandra node from the cluster:
- Run nodetool status from a live node and identify the down node's Host ID.
$ nodetool status Datacenter: dc1 =============== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.0.10.11 2.48 GiB 256 100.0% 8f4b4df0-38e9-4d76-8df8-609bb8e36a11 rack1 UN 10.0.10.12 2.51 GiB 256 100.0% b11f8fb4-7cf3-40b9-a8f6-ff1b1e65ac21 rack1 DN 10.0.10.13 2.39 GiB 256 100.0% e8b7f3c3-f0b6-44b0-a16f-5c72ad76a345 rack1
DN means down and normal in the status legend. Run the check from more than one live node if gossip views disagree.
Related: How to check Apache Cassandra cluster status with nodetool - Confirm the node is permanently lost and should not be decommissioned or replaced in place.
Use nodetool decommission for a live node. Use the replacement workflow instead when a new Cassandra process should take over the dead node's address or host identity.
- Start the removal from a live Cassandra node using the dead node's Host ID.
$ nodetool removenode e8b7f3c3-f0b6-44b0-a16f-5c72ad76a345
Do not use the node IP address here. removenode expects the host ID shown by nodetool status.
- Check the removal state until no token removal is active.
$ nodetool removenode status RemovalStatus: Removing token (-6124872051879382454). Waiting for replication confirmation from [/10.0.10.11, /10.0.10.12].
The exact token and replica list vary by ring. If the same token message does not move for a long time, inspect logs before using nodetool removenode force.
- Check streaming progress on the live nodes.
$ nodetool netstats Mode: NORMAL Not sending any streams. Read Repair Statistics: Attempted: 0 Mismatch (Blocking): 0 Mismatch (Background): 0 Pool Name Active Pending Completed Dropped Large messages n/a 0 0 0 Small messages n/a 0 8 0 Gossip messages n/a 0 1,284 0
During the removal, nodetool netstats can show active receiving or sending streams. Repeat the check on each surviving node that owns data for the affected keyspaces.
- Verify the removal has completed.
$ nodetool removenode status RemovalStatus: No token removals in process.
- Confirm the removed host ID is absent from cluster status.
$ nodetool status Datacenter: dc1 =============== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.0.10.11 2.72 GiB 256 100.0% 8f4b4df0-38e9-4d76-8df8-609bb8e36a11 rack1 UN 10.0.10.12 2.76 GiB 256 100.0% b11f8fb4-7cf3-40b9-a8f6-ff1b1e65ac21 rack1
- Review Cassandra logs on surviving nodes for removal or streaming errors.
$ sudo journalctl -u cassandra --since "1 hour ago" Jun 17 10:42:31 cassandra-01 cassandra[1842]: Removal of e8b7f3c3-f0b6-44b0-a16f-5c72ad76a345 completed Jun 17 10:42:34 cassandra-01 cassandra[1842]: Stream session with /10.0.10.12 completed
Related: How to view Apache Cassandra logs
- Run repair for affected keyspaces when the dead node missed writes beyond the hinted handoff window or a replacement is not being started immediately.
$ nodetool repair app_keyspace [2026-06-17 10:55:02,411] Starting repair command #3, repairing keyspace app_keyspace [2026-06-17 11:04:18,936] Repair command #3 finished in 9 minutes 16 seconds
Related: How to run Apache Cassandra repair
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.
