That is very helpful, thank you so much, Bowen.
I dropped the keyspace and created a new one (like with a new name).
Things look good now.
Will modify the service bootups to introduce the checks you've mentioned,
and that should mitigate the issue for any new clusters we'd setup.
Regards,
Aman
Ouch, all nodes are affected? That's a bit unusual...
If you don't have any useful data in the table, try drop the table and
then manually delete the data folder on all nodes. TBH I'm not even sure
if this is going to work, but worth to give it a try as it's simple enough.
Alternatively, if t
Hi,
I tried looking for the Id we got from schema table in all 18 nodes of my
cluster (we maintain 9+9 hot/warm cluster), but none of the node seems to
have the same Id in its data folder.
Is there a mechanism in cass which would've cleaned the duplicate/redundant
id table?
To summarise, we have
Ah, was expecting concurrency to be the cause. Lucky, we caught it before
we started ingesting any data in cassandra :)
Thanks for your help, Bowen, let me try this.
Regards,
Aman
On Tue, 25 Jan, 2022, 7:14 pm Bowen Song, wrote:
> The usual cause of this is the CQL statement CREATE TABLE ...
The usual cause of this is the CQL statement CREATE TABLE ... and/or
CREATE TABLE ... IF NOT EXISTS were ran on two nodes in a short period
of time (i.e. before the schema is fully synced between the nodes). If
both tables (same name, different UUIDs) have data in them, fixing the
issue without
Hi,
We're running an embedded Janus graph on top of Cassandra. On starting the
graph, it creates certain tables in cassandra for its operation. We noticed
that there is an Id mismatch for one of the tables named
system_properties_lock i.e.
Id fetched from schema table of cass (SELECT keyspace_nam
