Sorry Kane, I am a little bit confused, we are talking about schema version
at node level.
Which client operations could trigger schema change at node level? Do you
mean that for ex creating a new table trigger a schema change globally, not
only at KS/table single level?
Sébastien
Le jeu. 27 mai
I don't have schema changes, except keyspaces and tables creations. But
they are done from multiple sources indeed. With a "create if not exists"
statement, on demand. Thanks you for your answer, I will try to see if I
could precreate them then.
As for the schema mismatch, what is the best way of
>
> I have had that error sometimes when schema mismatch but also when all
> schema match. So I think this is not the only cause.
>
Have you checked the logs for errors on 135.181.222.100, 135.181.217.109,
and 135.181.221.180? They may give you some better information about why
they are sending bad
On Tue, May 25, 2021 at 6:36 AM Jai Bheemsen Rao Dhanwada <
jaibheem...@gmail.com> wrote:
> Hello All,
>
> I see that Cassandra 4.0 RC1 is released in April, is there going to be an
> official 4.0 GA release or is RC1 considered as an official GA release with
> Production use? If not is there a te
Thank you for your answer.
I have had that error sometimes when schema mismatch but also when all
schema match. So I think this is not the only cause.
By the way, what could cause such a shema mismatch. I would like to know
what should be or not be done in order to keep schema agreements between
Hello Sebastien,
Not sure but have you checked the output of "nodetool describecluster"? A
schema mismatch or node unavailability might result in this.
Thanks,
Dipan Shah
From: Sébastien Rebecchi
Sent: Wednesday, May 26, 2021 7:35 PM
To: user@cassandra.apache
Hi,
I have an issue with repairing my Casandra cluster, that was already the
case with Cassandra 3 and the issue is not solved with Cassandra 4 RC1.
I run in a for loop, one 1 by 1, the following command:
nodetool -h THE_NODE -u jTHE_USER -pw THE_PASSWORD repair --full -pr
and I always get the
