On Wed, 28 Jun 2023, at 11:47 AM, Mikhail T. wrote: > 27.06.23 21:34, ellie timoney пише: >>> Does this mean, going straight from 2.5.17 to 3.8 will not work even in >>> theory? Thank you! >> >> It hasn't been tested, or at least, anyone who has tested it hasn't reported >> back alive... > > > That's a fair warnings about the dark realities of practice, but I was asking > about theory: is it supposed to work, or have there been deliberate steps > taken -- such as removal of compatibility code -- that'd prevent such an > upgrade from working even in theory? >
2.5 still supported Berkeley DB, but 3.x do not at all, as described in the 3.0 upgrade documentation. This shouldn't affect a replication upgrade, but an in-place one across the 2.5->3.0 boundary without proper preparation will definitely fail. The upgrade across the 3.4->3.6 boundary contains substantial changes to underlying storage. This also shouldn't affect a replication upgrade, but complicates an in-place one -- as per the 3.6 upgrade docs. We haven't knowingly broken anything in the replication protocol, at least not in a forward direction (that is: replicating to a newer version ought to work, but replicating back to an older version may not). But we also don't regularly test it across major version boundaries, except in an ad-hoc fashion when we think some change might need such testing, and even then we wouldn't test a jump as big as 2.5->3.8. At Fastmail, we do very small upgrades very frequently -- our production environment is more or less tracking the master branch. It's hard for any of us to provide experienced advice about big upgrades because we just don't do them. On the other hand, by the time new features make it into a numbered release, they have at least run successfully in our production environment for 1-12 months. Tradeoffs, I suppose. In theory: a replication based upgrade directly from 2.5.17 -> 3.8 might work. But I dunno, I haven't tried! And if I tried, it would be with brand new test data, not real data with years of accumulated cruft, and thus not really reflective of real-world complexities. A direct in-place upgrade might also work, if you tread carefully and do all the right steps in the right order, but I sure wouldn't bet my data or weekend on it. > > > Ouch. Are you deliberately trying to increase the level of FUD?! :-) > > I'm deliberately trying to increase the level of caution. Most of the reports we see of failed upgrades come from people who just dove in, maybe without a good backup, probably without reading or adequately understanding the documentation, and often they don't come here asking for help until after they've already tinkered around and made things worse. I don't think this is you -- after all, you're here asking questions first, and good, thoughtful ones at that. But if one other person reads this thread and chooses to give their upgrade process the same care and respect they give their data, that seems like a net positive. I'm also trying to generally encourage making smaller upgrades more often. The further behind you are, the less likely you are to find someone who remembers how to help when you run into problems. > > > You mentioned your own role as a release engineer. Maybe, you can ask someone > else from the team to comment? > > They're on this mailing list, and welcome to chime in any time they like. > > > I'd be willing to try it, if it is supposed to work in theory -- and report > back too! But if it's been knowingly disabled, then I will not bother... > > It might be an interesting experiment, but I'm not sure it's a useful one. If it works, you may have just got lucky; I certainly wouldn't start recommending it as a general practice. If it doesn't work, we haven't learned anything we didn't already assume. Cheers, ellie ------------------------------------------ Cyrus: Info Permalink: https://cyrus.topicbox.com/groups/info/T6b49b7c42f338077-M2a39e2ab123490f2a2215a68 Delivery options: https://cyrus.topicbox.com/groups/info/subscription
