But the topology change restrictions are only in place while there are heterogenous versions in the cluster? All the nodes at the upgraded version with "degraded" sstables does NOT preclude topology changes or node replacement/addition?
On Tue, Oct 30, 2018 at 10:33 AM Jeff Jirsa <jji...@gmail.com> wrote: > 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 > >
