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
Got a little lost in your email Jeremy. Sounds like (from Ben | Instaclustr and Mick | TLP experience) there's confidence to move forward testing and documenting the following: Tested: >From → To 2.1 → 3.0 → 4.0 2.1 → 3.11 → 4.0 3.0 → 3.11 → 4.0 3.0 → 4.0 3.11 → 4.0 And Recommended: >From → To 2.1 → 3.11 → 4.0 3.0 → 4.0 3.11 → 4.0 Distinction between what we've tested and what we recommend, and 1 clear path From any supported version To the latest GA. If we all agree on the above, we should probably now discuss what "Tested" means. :) On Sun, Oct 11, 2020 at 7:57 PM, Jeremy Hanna <jeremy.hanna1...@gmail.com> wrote: > 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 >
