Hi Michael,
So I looked at the code, here are some stages of your error message:
1. at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:292)
[apache-cassandra-3.11.0.jar:3.11.0
At this step Cassandra is running through the keyspaces in it’s schema
turning off compactions for all tables before it starts rerunning the commit
log (so it isn’t an issue with the commit log).
2. at org.apache.cassandra.db.Keyspace.open(Keyspace.java:127)
~[apache-cassandra-3.11.0.jar:3.11.0]
Loading key space related to the column family that is erroring out
3. at org.apache.cassandra.db.Keyspace.<init>(Keyspace.java:324)
~[apache-cassandra-3.11.0.jar:3.11.0]
Cassandra has initialised the column family and is reloading the view
4. at org.apache.cassandra.db.Keyspace.getColumnFamilyStore(Keyspace.java:204)
~[apache-cassandra-3.11.0.jar:3.11.0]
At this point I haven’t had enough time to tell if Cassandra is
requesting info on a column specifically or still requesting information on a
column family. Regardless, given we already rule out issues with the SSTables
and their directory and Cassandra is yet to start processing the commit log
this to me suggests it’s something wrong in one of the system keyspaces storing
the schema information.
There should definitely be a way to resolve this with zero data loss by either:
1. Fixing the issue in the system keyspace SSTables (hard)
2. Rerunning the commit log on a new Cassandra node that has been restored from
the current one (I’m not sure if this is possible but I’ll figure it out
tomorrow)
The alternative is if you are ok with losing the commitlog then you can backup
the data and restore it to a new node (or the same node but with everything
blown away). This isn’t a trivial process though I’ve done it a few times.
How important is the data?
Happy to come back to this tomorrow (need some sleep)
Regards,
Eevee.
> On 5 Jun 2018, at 7:32 pm, m...@vis.at wrote:
>
> Keyspace.getColumnFamilyStore
