As said already by Alain you should make this as short as possible: - streaming operations won't work (repair, bootstrap) - Hinted Handoff won't work as 2 differents major version of cassandra can't shared the same schema version - So no DDL operations (CREATE/ALTER) as you change won't be propagated
you don't need to wait for the end of "nodetool upgradesstable" to upgrade next node: this can be done after you upgrade all nodes and satrt as an asynchronous planified job. My take on this: - disable repairs - backup date and especially system table on all nodes - upgrade 1 node on DC1 - if everything is fine, rolling upgrade all nodes on DC1 - ensure that everything is working (you can still rollback at this point by rebuild entirely DC1 if something is wrong or restore previous cassandra version with previous backup files) - once you are confident enough, upgrade DC2 - when done, schedule upgradesstables and try to spread upgradesstable throughout your DC and racks if you don't want to impact your read latency too much - once finished, reenable repairs 2016-11-16 11:12 GMT+01:00 techpyaasa . <techpya...@gmail.com>: > Hi all, > > We are currently running c*-2.0.17 with 2 datacenters each with 18 nodes. > > We like to upgrade to c*-2.1.16. Can we upgrade first all nodes(one by > one) in one dc and then go to next data center. > > As it might take few days as it will have 'upgrade sstables' , so just > wanted to know would be there any possibility during this mismatch of c* > version among nodes in cluster during this upgrade process? > > Thanks > Techpyaasa > -- Close the World, Open the Net http://www.linux-wizard.net
