Hi,
we will follow the recommendation not to use materialized views.
Thanks a lot to both of you!
You helped me a lot.
Oh and besides: We are also using the lagom framework :) So we will also
be able to regenerate a Read-Side if have to.
greetings,
Michael
On 07.06.2018 13:45, Evelyn
Hey Michael,
In the case that you have a production cluster set up with multiple nodes,
assuming you have rf>1 it’s easier to just replace the broken node and restore
it’s data. (For future reference)
I wasn’t sure if view was referring to materialised view at the time although
Pradeeps
Hi Michael,
We have faced the same situation as yours in our production environment
where we suddenly got "Unknown CF Exception" for materialized views too. We
are using Lagom apps with cassandra for persistence. In our case, since
these views can be regenerated from the original events, we were
Hi Evelyn,
thanks a lot for your detailed response message.
The data is not important. We've already wiped the data and created a
new cassandra installation. The data re-import task is already running.
We've lost the data for a couple of months but in this case this does
not matter.
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
Hello Evelyn,
if we do what you say cassandra creates a new, empty column family
directory on restart and the stops with the same exception.
One point i forgot to mention is that we've still got data in the commit
log. (99.9% for other keyspaces).
Are there any tools which we can use to
Hey Michael,
I have a hunch.
If the system doesn’t recognise the column family which is stopping the node
from starting perhaps try copying the column family directory to a backup then
deleting it.
Then restart Cassandra. If it starts I’ll assume the schema didn’t have the
column family:
*
