Hi Jeff, Repair is not a prerequisite for upgrading from 3.x to 4.x (but it's always recommended to run as a continuous process). Repair is not supported between nodes
running different major versions, so it should be disabled during the upgrade. There are quite a few fixes for hung repair sessio
We have similar issues with 3.x repairs, and run manually as well as with
Reaper. Can someone tell me, if I cannot get a table repaired because it is
locking up a node, is it still possible to upgrade to 4.0?
Jeff
From: Jon Haddad
Reply-To:
Date: Tuesday, December 17, 2024 at 2:20 PM
T
I strongly suggest moving to 4.0 and to set up Reaper. Managing repairs
yourself is a waste of time, and you're almost certainly not doing it
optimally.
Jon
On Tue, Dec 17, 2024 at 12:40 PM Miguel Santos-Lopez
wrote:
> We haven’t had the chance to upgrade to 4, let alone 5. Has there been a
>
> Secondly there are some very large clusters involved, 1300+ nodes across
multiple physical datacenters, in this case any upgrades are only done out
of hours and only one datacenter per day. So a normal upgrade cycle will
take multiple weeks, and this one will take 3 times as long.
If you only r
Hi Jon,
It is a mixture of things really, firstly it is a legacy issue where there have
been performance problems in the past during upgrades, these have now been
fixed, but it is not easy to regain the trust in the process.
Secondly there are some very large clusters involved, 1300+ nodes acro
It's kind of a shame we don't have rolling restart functionality built in to
the database / sidecar. I know we've discussed that in the past.
+1 to Jon's question - clients (i.e. java driver, etc) should be able to handle
disconnects gracefully and route to other coordinators leaving the
applic
Just curious, why is a rolling restart difficult? Is it a tooling issue,
stability, just overall fear of messing with things?
You *should* be able to do a rolling restart without it being an issue. I look
at this as a fundamental workflow that every C* operator should have available,
and you
All,
We are getting a lot of push back on the 3 stage process of going through the
three compatibility modes to upgrade to Cassandra 5. This basically means 3
rolling restarts of a cluster, which will be difficult for some of our large
multi DC clusters.
Having researched this, it looks like,
