Re: Supported upgrade path for 4.0

[Jeremy Hanna]

So to reiterate the recommended/tested paths that I get from this thread:

2.1.x -> 2.1.latest -> [3.0.latest | 3.11.latest] -> 4.0
2.2.x -> 2.2.latest -> [3.0.latest | 3.11.latest] -> 4.0
3.0 -> 3.0.latest -> 4.0
3.x -> 3.11.latest -> 4.0

I just wanted to be explicit about getting to the latest in the current line 
you're in before upgrading to reduce risks and test surface area by upgrading 
from a single '.latest' version.  That and in case there are additional fixes 
added in this upgrade test process to make the '.latest' version more stable 
for the upgrade.  Also we hadn't mentioned 2.2 which some people are running 
and is currently supported by the project.

Something that makes [3.0.latest | 3.11.latest] as a midpoint less of a risk is 
that both 3.0.latest and 3.11.latest use the same sstable version (md).  That 
sstable version came about in 3.0.18/3.11.4.  If people are on earlier versions 
of 3.0 or 3.x, we should consider recommending that they upgrade to 3.0.latest 
or 3.11.latest, run upgradessttables, and then go to 4.0 to just make sure they 
go from md to na (4.0).  Just to save people from looking it up, the last major 
change to the sstable format was in 3.0.18/3.11.4 with version md to correct 
sstable min/max metadata.  See 
https://issues.apache.org/jira/browse/CASSANDRA-14861 and 
https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/io/sstable/format/big/BigFormat.java#L128.
  I've been surprised to see some clusters that back API gateways running 3.7 
for example.

> On Oct 12, 2020, at 8:32 AM, Scott Andreas  wrote:
> 
> Great, thanks Ben!
> 
> The primary configuration my colleagues and I will be vetting is the 3.0.x -> 
> 4.0 path (implicitly, 2.1 -> 3.0 -> 4.0). From a quality + safety perspective 
> we will be ensuring that it’s a smooth ride for folks who opt for this route; 
> though no major concerns on my part with the project recommending 2.1 -> 3.11 
> -> 4.0 aside from not having experienced it myself.
> 
>> On Oct 11, 2020, at 12:47 AM, Ben Slater  wrote:
>> 
>> Just to add to Mick's point, we (Instaclustr) have also been running and
>> recommending 3.11.x by default. It's currently by far the most common
>> version in our managed fleet and our last 3.0.x cluster will likely be
>> upgraded shortly. 3.11.x is also our recommendation for consulting and
>> support customers. I'd therefore support Mick's recommendation (really
>> based on our experience with and confidence in 3.11.x rather than being
>> able to point to specific issues off hand) that 2.*->3.11.x->4.0 is the
>> preferred upgrade path. We will do testing on 3.11.x to 4.0 upgrade but I
>> can't see us doing any work on 3.0 to 4.0.
>> 
>> Cheers
>> Ben
>> 
>> ---
>> 
>> 
>> *Ben Slater**Chief Product Officer*
>> 
>> 
>> 
>>    
>> 
>> 
>> Read our latest technical blog posts here
>> .
>> 
>> This email has been sent on behalf of Instaclustr Pty. Limited (Australia)
>> and Instaclustr Inc (USA).
>> 
>> This email and any attachments may contain confidential and legally
>> privileged information.  If you are not the intended recipient, do not copy
>> or disclose its content, but please reply to this email immediately and
>> highlight the error to the sender and then immediately delete the message.
>> 
>> 
>> On Sun, 11 Oct 2020 at 06:42, Mick Semb Wever  wrote:
>> 
 "3.11 performs close to parity with 2.1/2.2. 3.0 does not. If we
>>> recommend
 people upgrade from 2.1 -> 3.0 -> 4.0, we are asking them to have a
>>> cluster
 in a regressed performance state for potentially months as they execute
 their upgrade."
 
 Did I get anything wrong here Mick? ^
 
>>> 
>>> 
>>> That's correct Josh.
>>> 
>>> From tickets like those listed, and from experience, we recommend folk
>>> avoid 3.0 altogether. This has only been made more evident by witnessing
>>> the benefits from 3.0 → 3.11 upgrades.
>>> 
>>> My recommendation remains  2.*→3.11→4.0. And I don't believe I'm alone.
>>> Though if a user was already on 3.0, then I would (of course) recommend an
>>> upgrade directly to 4.0.
>>> 
>>> I feel like I'm just splitting straws at this point, since we have accepted
>>> (folk willing to help with) both paths to 4.0, and I can't see how we stop
>>> recommending  2.*→3.11 upgrades.
>>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Supported upgrade path for 4.0

[Scott Andreas]

Great, thanks Ben!

The primary configuration my colleagues and I will be vetting is the 3.0.x -> 
4.0 path (implicitly, 2.1 -> 3.0 -> 4.0). From a quality + safety perspective 
we will be ensuring that it’s a smooth ride for folks who opt for this route; 
though no major concerns on my part with the project recommending 2.1 -> 3.11 
-> 4.0 aside from not having experienced it myself.

> On Oct 11, 2020, at 12:47 AM, Ben Slater  wrote:
> 
> Just to add to Mick's point, we (Instaclustr) have also been running and
> recommending 3.11.x by default. It's currently by far the most common
> version in our managed fleet and our last 3.0.x cluster will likely be
> upgraded shortly. 3.11.x is also our recommendation for consulting and
> support customers. I'd therefore support Mick's recommendation (really
> based on our experience with and confidence in 3.11.x rather than being
> able to point to specific issues off hand) that 2.*->3.11.x->4.0 is the
> preferred upgrade path. We will do testing on 3.11.x to 4.0 upgrade but I
> can't see us doing any work on 3.0 to 4.0.
> 
> Cheers
> Ben
> 
> ---
> 
> 
> *Ben Slater**Chief Product Officer*
> 
> 
> 
>    
> 
> 
> Read our latest technical blog posts here
> .
> 
> This email has been sent on behalf of Instaclustr Pty. Limited (Australia)
> and Instaclustr Inc (USA).
> 
> This email and any attachments may contain confidential and legally
> privileged information.  If you are not the intended recipient, do not copy
> or disclose its content, but please reply to this email immediately and
> highlight the error to the sender and then immediately delete the message.
> 
> 
> On Sun, 11 Oct 2020 at 06:42, Mick Semb Wever  wrote:
> 
>>> "3.11 performs close to parity with 2.1/2.2. 3.0 does not. If we
>> recommend
>>> people upgrade from 2.1 -> 3.0 -> 4.0, we are asking them to have a
>> cluster
>>> in a regressed performance state for potentially months as they execute
>>> their upgrade."
>>> 
>>> Did I get anything wrong here Mick? ^
>>> 
>> 
>> 
>> That's correct Josh.
>> 
>> From tickets like those listed, and from experience, we recommend folk
>> avoid 3.0 altogether. This has only been made more evident by witnessing
>> the benefits from 3.0 → 3.11 upgrades.
>> 
>> My recommendation remains  2.*→3.11→4.0. And I don't believe I'm alone.
>> Though if a user was already on 3.0, then I would (of course) recommend an
>> upgrade directly to 4.0.
>> 
>> I feel like I'm just splitting straws at this point, since we have accepted
>> (folk willing to help with) both paths to 4.0, and I can't see how we stop
>> recommending  2.*→3.11 upgrades.
>> 

Re: Supported upgrade path for 4.0

[Ben Slater]

Just to add to Mick's point, we (Instaclustr) have also been running and
recommending 3.11.x by default. It's currently by far the most common
version in our managed fleet and our last 3.0.x cluster will likely be
upgraded shortly. 3.11.x is also our recommendation for consulting and
support customers. I'd therefore support Mick's recommendation (really
based on our experience with and confidence in 3.11.x rather than being
able to point to specific issues off hand) that 2.*->3.11.x->4.0 is the
preferred upgrade path. We will do testing on 3.11.x to 4.0 upgrade but I
can't see us doing any work on 3.0 to 4.0.

Cheers
Ben

---


*Ben Slater**Chief Product Officer*



   


Read our latest technical blog posts here
.

This email has been sent on behalf of Instaclustr Pty. Limited (Australia)
and Instaclustr Inc (USA).

This email and any attachments may contain confidential and legally
privileged information.  If you are not the intended recipient, do not copy
or disclose its content, but please reply to this email immediately and
highlight the error to the sender and then immediately delete the message.


On Sun, 11 Oct 2020 at 06:42, Mick Semb Wever  wrote:

> > "3.11 performs close to parity with 2.1/2.2. 3.0 does not. If we
> recommend
> > people upgrade from 2.1 -> 3.0 -> 4.0, we are asking them to have a
> cluster
> > in a regressed performance state for potentially months as they execute
> > their upgrade."
> >
> > Did I get anything wrong here Mick? ^
> >
>
>
> That's correct Josh.
>
> From tickets like those listed, and from experience, we recommend folk
> avoid 3.0 altogether. This has only been made more evident by witnessing
> the benefits from 3.0 → 3.11 upgrades.
>
> My recommendation remains  2.*→3.11→4.0. And I don't believe I'm alone.
> Though if a user was already on 3.0, then I would (of course) recommend an
> upgrade directly to 4.0.
>
> I feel like I'm just splitting straws at this point, since we have accepted
> (folk willing to help with) both paths to 4.0, and I can't see how we stop
> recommending  2.*→3.11 upgrades.
>