Wait for 3.11.4 to be cut I also vote for doing all the binary bounces and upgradesstables after the fact, largely because normal writes/compactions are going to naturally start upgrading sstables anyway, and there are some hard restrictions on mixed mode (e.g. schema changes won’t cross version) that can be far more impactful.
-- Jeff Jirsa > On Oct 30, 2018, at 8:21 AM, Carl Mueller > <carl.muel...@smartthings.com.INVALID> wrote: > > We are about to finally embark on some version upgrades for lots of clusters, > 2.1.x and 2.2.x targetting eventually 3.11.x > > I have seen recipes that do the full binary upgrade + upgrade sstables for 1 > node before moving forward, while I've seen a 2016 vote by Jon Haddad (a TLP > guy) that backs doing the binary version upgrades through the cluster on a > rolling basis, then doing the upgradesstables on a rolling basis. > > Under what cluster conditions are streaming/node replacement precluded, that > is we are vulnerable to a cloud provided dumping one of our nodes under us or > hardware failure? We ain't apple, but we do have 30+ node datacenters and > 80-100 node clusters. > > Is the node replacement and streaming only disabled while there are > heterogenous cassandra versions, or until all the sstables have been upgraded > in the cluster? > > My instincts tell me the best thing to do is to get all the cassandra nodes > to the same version without the upgradesstables step through the cluster, and > then roll through the upgradesstables as needed, and that upgradesstables is > a node-local concern that doesn't impact streaming or node replacement or > other situations since cassandra can read old version sstables and new > sstables would simply be the new format. --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org For additional commands, e-mail: user-h...@cassandra.apache.org
