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 >