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 fixing that issue?
Could Cassandra recover from that on its own or is there a nodetool command
to force schema agreement? I have heard that we have to restart the nodes 1
by 1, but it seems a very heavy procedure for that.

Regards,

Sébastien

Le jeu. 27 mai 2021 à 02:45, Kane Wilson <k...@raft.so> a écrit :

> 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 replies.
>
> 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
>> nodes? Are there some mistakes to avoid in table design to prevent such
>> issue?
>>
> Schema changes aren't strongly consistent across the cluster, so they can
> occur through various problems. The main one would be multiple clients
> making schema changes simultaneously and separate nodes ending up with
> conflicting schema definitions. Best practice to avoid that is to only make
> schema changes from a single client.
>
>
> --
> raft.so - Cassandra consulting, support, and managed services
>

Reply via email to