AFAIK there's nothing special being the first disk in the list. It's
fairly likely that you were just "lucky" that an important part of the
system keysapce was on that disk. It's always a good idea to keep some
spare hardware at hand, because you will never know when will they be
needed.
On
Thank you Bowen. I had the policy set to "best_effort", but as Jeff
pointed out since it was the first disk in the list that failed maybe
that is a special case?
I don't have a spare drive at the moment, so I'll just delete all the
cassandra data on that node and have it rejoin as a new
Likely lost (enough of) the system key space on that disk so the data files
indicating the host was in the cluster are missing and the host tried to
rebootstrap
> On Dec 11, 2021, at 12:47 PM, Bowen Song wrote:
>
>
> Hi Joss,
>
> To unsubscribe from this mailing list, please send an
Hi Joss,
To unsubscribe from this mailing list, please send an email to
user-unsubscr...@cassandra.apache.org, not the mailing list itself
(user@cassandra.apache.org).
On 09/12/2021 16:14, Joss wrote:
unsubscribe
On Mon, 6 Dec 2021 at 14:12, Joe Obernberger
wrote:
Hi All - one node
Hi Joe,
In case of a single disk failure, you should not remove the data
directory from the cassandra.yaml file. Instead, you should replace the
failed disk with a new empty disk. See
https://docs.datastax.com/en/cassandra-oss/3.x/cassandra/operations/opsRecoverUsingJBOD.html
for the steps.
unsubscribe
On Mon, 6 Dec 2021 at 14:12, Joe Obernberger
wrote:
> Hi All - one node in an 11 node cluster experienced a drive failure on
> the first drive in the list. I removed that drive from the list so that
> it now reads:
>
> data_file_directories:
> - /data/2/cassandra/data
> -
Hi All - one node in an 11 node cluster experienced a drive failure on
the first drive in the list. I removed that drive from the list so that
it now reads:
data_file_directories:
- /data/2/cassandra/data
- /data/3/cassandra/data
- /data/4/cassandra/data
-
