a down node, etc., so I do not run in mixed version mode very
long.
Sean Durity
From: Carl Mueller
Sent: Tuesday, October 30, 2018 11:51 AM
To: user@cassandra.apache.org
Subject: [EXTERNAL] Re: rolling version upgrade, upgradesstables, and
vulnerability window
Thank you very much. I couldn't
Thank you very much. I couldn't find any definitive answer on that on the
list or stackoverflow.
It's clear that the safest for a prod cluster is rolling version upgrade of
the binary, then the upgradesstables.
I will strongly consider cstar for the upgradesstables
On Tue, Oct 30, 2018 at
Yes, as the new version can read both the old and the new sstables format.
Restrictions only apply when the cluster is in mixed versions.
On Tue, Oct 30, 2018 at 4:37 PM Carl Mueller
wrote:
> But the topology change restrictions are only in place while there are
> heterogenous versions in the
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 wrote:
> Wait
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
Hi Carl,
the safest way is indeed (as suggested by Jon) to upgrade the whole cluster
as quick as possible, and stop all operations that could generate streaming
until all nodes are using the target version.
That includes repair, topology changes (bootstraps, decommissions) and
rebuilds.
You
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
