> On May 19, 2021, at 5:15 PM, Jai Bheemsen Rao Dhanwada
> <jaibheem...@gmail.com> wrote:
>
>
> Hello,
>
> I am trying to get some suggestions on running upgradesstables(for a major
> version upgrade where there is a SSTable format change).
>
> The Cassandra cluster is set up in 3 datacenters with 18 nodes in each region
> and here are the 3 options that I am evaluating.
>
> 1. Run "nodetool upgradesstables" after every Cassandra node is upgraded to
> the new version.
> 2. Upgrade cassandra version on one of the data centers, run "nodetool
> upgradesstables" and proceed to the next datacenter and so on.
> 3. Upgrade cassandra version on all the datacenters and run "nodetool
> upgradesstables" at the end on all the data centers.
>
> I am more interested in understanding option-2 where I upgrade the cassandra
> version and run upgradesstables for one data center and then proceed to the
> next datacenter and so on. Are there any disadvantages with this option?
>
The difference between 2 and 3 is how long you stay in mixed mode
In 2, you could theoretically roll back the whole DC if you detect a failure
and the app can fail out of that dc. It’d be hard but possible.
In 3, you minimize mixed mode (internode), and the sstables largely upgrade
themselves in high churn clusters through compaction.
In theory 3 is probably faster, if you disable repair in mixed mode and until
sstables are upgraded, 3 gets you done “faster” so repair can run again. 2
might be strictly safer if you trust internode mixed mode AND have a way to
fail out of a dc and rebuild it without violating consistency.
