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 <sc...@paradoxica.net> 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 <ben.sla...@instaclustr.com> 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* >> >> <https://www.instaclustr.com/platform/> >> >> <https://www.facebook.com/instaclustr> <https://twitter.com/instaclustr> >> <https://www.linkedin.com/company/instaclustr> >> >> Read our latest technical blog posts here >> <https://www.instaclustr.com/blog/>. >> >> 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 <m...@apache.org> 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
