Yes, going to 3.0.14 or 3.0.15 should work correctly 3.0.15 will have important bug fixes not in 3.0.14
-- Jeff Jirsa > On Nov 29, 2017, at 4:52 PM, Jai Bheemsen Rao Dhanwada > <jaibheem...@gmail.com> wrote: > > Thanks Jeff, > > You mean if I upgrade from 3.0.8 -> 3.0.15 it should work without any issues? > >> On Wed, Nov 29, 2017 at 4:21 PM, Jeff Jirsa <jji...@gmail.com> wrote: >> This is because in 3.0.14, we had to bump the internode messaging version to >> fix a nasty bug (it's something we almost never do in minor versions, but it >> was necessary here), and schema changes won't cross internode messaging >> versions. >> >> You can continue upgrading, and when new nodes reach 3.0.14 they'll get the >> new schema versions. Until they all match, schema changes won't propagate >> properly. >> >> If you REALLY need schema changes to propagate during the upgrade, you >> should read the notes on CASSANDRA-13004 and Alex's summary here >> https://gist.github.com/ifesdjeen/9cacb1ccd934374f707125d78f2fbcb6 >> >> But really, you should just upgrade to 3.0.15 and not do any schema changes >> until the upgrade is complete (and be aware that having 2 schema versions >> during the upgrade is normal and expected). >> >> - Jeff >> >> >>> On Wed, Nov 29, 2017 at 4:05 PM, Jai Bheemsen Rao Dhanwada >>> <jaibheem...@gmail.com> wrote: >>> Hello, >>> >>> >>> >>> I am trying to upgrade the cassandra version from the 3.0.8 to 3.0.14. I am >>> adding a new node with 3.0.14 version to 3.0.8. cluster and I see the >>> schema disagreement between the nodes and the new node doesn't stream any >>> data. >>> >>> I am looking at : https://issues.apache.org/jira/browse/CASSANDRA-13559, >>> does this mean, I will not be able to add nodes with the higher version >>> than 3.0.13? >>> >>> here is what I see in the nodetool describecluster output >>> >>> $ nodetool describecluster >>> Cluster Information: >>> Name: production >>> Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch >>> Partitioner: org.apache.cassandra.dht.Murmur3Partitioner >>> Schema versions: >>> 45ad6427-30a8-3381-9e2c-266b446c6ea7: [192.168.1.2, 192.168.1.3, >>> 192.168.1.4] >>> >>> c2a2bb4f-7d31-3fb8-a216-00b41a643650: [10.10.1.10] >>> Any work around to mitigate this? >>> >> >
