hi @Erick,
Actually this timestamp *1614575293790 *is equivalent to
*GMT: Monday, 1 March 2021 05:08:13.790*
that stands for
*GMT+1: Monday, 1 March 2021 06:08:13.790* (my local
timezone).
This is consistent with the other logs time in the cluster.
Thank
The timestamp (1614575293790) in the snapshot directory name is equivalent
to 1 March 16:08 GMT:
actually I found a lot of .db files in the following directory:
>
> /var/lib/cassandra/data/mykespace/mytable-2795c0204a2d11e9aba361828766468f/snapshots/dropped-1614575293790-
> mytable
>
which lines
I haven't made any schema modifications for a year or more.
This problem came up during a "normal day of work" for Cassandra.
Il giorno lun 1 mar 2021 alle ore 16:25 Bowen Song
ha scritto:
> Your missing keyspace problem has nothing to do with that bug.
>
> In that c
Your missing keyspace problem has nothing to do with that bug.
In that case, the same table was created twice in a very short period of
time, and I suspect that was done concurrently on two different nodes.
The evidence lies in the two CF IDs - bd7200a0156711e88974855d74ee356f
own (or is
> unreachable via network) before 2021-02-28 05:17:33. Is there any chance
> you can find the log file on that node at around or before that time? It
> may show why did that node go down. The reason of that might be irrelevant
> to the missing keyspace, but still worth to have
to the missing keyspace, but still worth to have a look in
order to prevent the same thing from happening again.
As Erick said, the table's CF ID isn't new, so it's unlikely to be a
schema synchronization issue. Therefore I also suspect the keyspace was
accidentally dropped. Cassandra only logs "
As the warning message suggests, you need to check for schema disagreement.
My suspicion is that someone made a schema change and possibly dropped the
problematic keyspace.
FWIW I suspect the keyspace was dropped because the table isn't new -- CF
ID cba90a70-5c46-11e9-9e36-f54fe3235e69 is
pace.mytable where id = 123935;
>> *InvalidRequest: Error from server: code=2200 [Invalid query]
>> message="Keyspace * *mykeyspace does not exist"*
>>
>> Investigating on each node I found that all the *SStables exist*, so I
>> think data is still there but the keys
* I have been getting Anticompaction errors from 2 nodes due to
the fact the disk was almost full.
* the cluster was online friday
* this morning, Monday, the whole cluster was offline and I
noticed the problem of "missing keyspace"
* During the weekend the c
exist*, so I
> think data is still there but the keyspace vanished, "magically".
>
> Other facts I can tell you are:
>
>- I have been getting Anticompaction errors from 2 nodes due to the
>fact the disk was almost full.
>- the cluster was online friday
>
t full.
* the cluster was online friday
* this morning, Monday, the whole cluster was offline and I noticed
the problem of "missing keyspace"
* During the weekend the cluster has been subject to inserts and deletes
* I have a 9 node (HDD) Cassandra 3.11 cluster.
I really nee
ning, Monday, the whole cluster was offline and I noticed the
problem of "missing keyspace"
- During the weekend the cluster has been subject to inserts and deletes
- I have a 9 node (HDD) Cassandra 3.11 cluster.
I really need help on this, how can I restore the cluster?
Thank you very much
Marco
12 matches
Mail list logo
