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 2021 à 08:33, Sébastien Rebecchi <srebec...@kameleoon.com> a écrit : > 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 >> >
