Recovering from a single disk failure using JBOD
Steps for recovering from a single disk failure in a disk array using JBOD (just a bunch of disks).
Steps for recovering from a single disk failure in a disk array using JBOD (just a bunch of disks).
- The operation's consistency level is ALL.
- The data being requested or written is stored on the defective disk.
- The data to be compacted is on the defective disk.
It's possible that you can simply replace the disk, restart Cassandra, and run nodetool repair. However, if the disk crash corrupted system table, you must remove the incomplete data from the other disks in the array. The procedure for doing this depends on whether the cluster uses vnodes or single-token architecture.
cassandra-env.sh
- The cassandra-env.sh file is located in the installation_location/conf directory.
cassandra.yaml
- The cassandra.yaml file is located in the installation_location/conf directory.
Procedure
-
Verify that the node has a defective disk and identify the disk, by checking
the logs on the affected node.
Disk failures are logged in
FILE NOT FOUND
entries, which identifies the mount point or disk that has failed. - If the node is still running, stop Cassandra and shut down the node.
- Replace the defective disk and restart the node.
-
If the node cannot restart:
-
Try restarting Cassandra without bootstrapping the node:
Start Cassandra with this option:
sudo bin/cassandra Dcassandra.allow_unsafe_replace=true
-
Try restarting Cassandra without bootstrapping the node:
- If Cassandra restarts, run nodetool repair on the node. If not, replace the node.
- If the repair succeeds, the node is restored to production. Otherwise, go to 7 or 8.
-
For a cluster using vnodes:
-
For a cluster single-token nodes: