Schema are propagated by GOSSIP you can check schema propagation cluster wide with nodetool describecluster or "nodetool gossipinfo | grep SCHEMA | cut -f3 -d: | sort | uniq -c"
You'd better send your DDL instruction to only one node (for example by using the whitelist load balancing policy with only 1 host specified), this way your schemas changes will be serialized and you will avoid issues and race conditions 2016-11-15 19:04 GMT+01:00 Josh Smith <jsm...@ionicsecurity.com>: > Would someone please explain how schema changes happen? > > Here are some of the ring details > > We have 5 nodes in 1 DC and 5 nodes in another DC across the country. > > Here is our problem, we have a tool which automates our schema creation. > Our schema consists of 7 keyspaces with 21 tables in each keyspace, so a > total of 147 tables are created at the initial provisioning. During this > schema creation we end up with system_schema keyspace corruption, we have > found that it is due to schema version disagreement. To combat this we > setup a wait until there is only one version in both system.local and > system.peers tables. > > The way I understand it schema changes are made on the local node only; > changes are then propagated through either Thrift or Gossip, I could not > find a definitive answer online if thrift or gossip was the carrier. So if > I make all of the schema changes to one node it should propagate the > changes to the other nodes one at a time. This is how I used to think that > schema changes are propagated but we still get schema disagreement when > changing the schema only on one node. Is the only option to introduce a > wait after every table creation? Should we be looking at another table > besides system.local and peers? Any help would be appreciated. > > > > Josh Smith > -- Close the World, Open the Net http://www.linux-wizard.net
