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 10
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
>
> In other words, if I am running Cassandra 1.2.x and upgrading to 2.0.x,
> 2.0.x will continue to read all the old Cassandra 1.2.x table. However, if
> I then want to upgrade to Cassandra 2.1.x, I’d better make sure all tables
> have been upgraded to 2.0.x before making the next upgrade.
@cassandra.apache.org
Subject: Re: Version Upgrade
There's no harm in running it during any upgrade, and I always recommend doing
it just to be in the habit.
My 2 cents.
On Wed, Apr 25, 2018 at 3:39 PM Christophe Schmitz
<christo...@instaclustr.com<mailto:christo...@instaclustr.com>> wrot
perform a major Cassandra
> version upgrade, so you don't need to run it for upgrading in the 3.x.x
> series.
> One way to check which storage version your SSTables are using is to look
> at the SSTables name. It is structured as:
> --.db The version is a string that
> represents t
Hi Pranay,
You only need to upgrade your SSTables when you perform a major Cassandra
version upgrade, so you don't need to run it for upgrading in the 3.x.x
series.
One way to check which storage version your SSTables are using is to look
at the SSTables name. It is structured as:
--.db
When is it necessary to upgrade SSTables ?? For a minor upgrade do we need
to run upgrade stables??
I knew when we are doing a major upgrade we have to run upgrade sstables so
that sstables will be re-written to newer version with additional meta data.
But do we need to run upgrade sstables for
Is there a tool/guide/document that shows you upgrade paths for different
versions of Cassandra?
For example if you are on version X and want to go to version Y, here are the
intermediate versions you need to upgrade to and here are some special
precautions/Steps you need to take for so and so
Check https://github.com/apache/cassandra/blob/trunk/NEWS.txt to see the
steps required, if any, when upgrading.
As a general practice you should also reviw the changes at
https://github.com/apache/cassandra/blob/trunk/CHANGES.txt If upgrading
major versions it is often recommended to be on the
:
Hi,
I have some questions about SSTable compatibility when doing a minor version
upgrade. For example when upgrading from 1.0.3 (Uses version hb) to 1.0.6
(uses version hc).
1. Will I need to upgrade all nodes before performing streaming/repair?
2. Will it be possible to downgrade
Hi,
I have some questions about SSTable compatibility when doing a minor
version upgrade. For example when upgrading from 1.0.3 (Uses version
hb) to 1.0.6 (uses version hc).
1. Will I need to upgrade all nodes before performing streaming/repair?
2. Will it be possible to downgrade a node
16 matches
Mail list logo
