Hi Wolfgang!

On Fri, 9 May 2025, at 9:03 PM, Wolfgang Breyha wrote:
> Hi!
>
> I'm currently using a large cyrus 2.5 murder setup with 3 frontends, a
> mupdate master and >10 backends.
>
> I plan to stick with
> mailbox_legacy_dirs: 1
> unixhierarchysep: 0
> altnamespace: 0
> hashimapspool: 1
> fulldirhash: 1
>
> The patches to correctly detect newer cyrus backend versions are in place.
>
> Looking into the upgrade documents of 3.x I see that "in place" upgrades
> are not recommended for cyrus >3.4 in case of 2.5.
>
> Would it be possible to place 3.8 backends into the existing setup and XFER
> the mailboxes without the issues raised by an in place upgrade? Or should I
> use 3.4 as well?

This *might* work.

As I recall, the big issue with in-place upgrades across the 3.4->3.6 boundary 
is the rewrite of mailboxes.db that happens on first startup.  Older versions 
didn't guarantee the information required by the rewrite was present, and if 
any mailbox is missing it, the rewrite will fail and the upgraded server might 
be unable to start, or start in a weird state.  Upgrading to 3.4.4+ first, 
running it for a while, and fixing anything that it reports as broken, gets you 
into a good position for a later upgrade to 3.6 or 3.8 to succeed.

But if you're building new 3.8 backends and XFERing mailboxes into them, this 
won't apply, since the new mailboxes.db will start empty.  So the questions 
then become:
 • whether 2.5->3.8 XFERs can succeed reliably; and
 • whether a 3.8 backend can play nicely in a 2.5 murder during the cutover 
period 
I don't know the answers, but I don't know them for 2.5->3.4 either.  Perhaps 
some other murder users could chime in.  I'd suggest reading through all the 
release notes for murder- or XFER-related bugs and fixes; I'm sure there have 
been some over the years, but I've forgotten their details.

Probabilistically speaking, I think the safer bet is to get the whole 
deployment to the latest 3.4 first, and then move forward to 3.8 afterwards.

> Or is the recommendation to use 3.4 bound to some features and upgrading to
> 3.8 possible in certain cases? I at least tried it on a small cyrus 2.5
> setup without visible troubles.

The devil is really in the data here, rather than the configuration.  
Anecdotally, it seems like the biggest difficulties come from mailboxes that 
have been around for a long time, especially if this 2.5 environment was 
previously upgraded from 2.4 or earlier, and mailboxes that were around back 
then are still active.  Small scale testing tends to happen with new, small 
mailboxes, on newly-installed servers, and this doesn't reflect reality 
particularly well.

If it were me, and if I had the resources to do so, I would want to get 
snapshots from some of my real servers -- at least one frontend, at least one 
backend, and mupdate -- and then spin up virtualised clones to test the various 
upgrade paths with real data.  See what problems shake out, and work out how to 
address them.  Rinse and repeat with fresh snapshots until I'm confident, and 
only then start touching the live servers/mailboxes.

Cheers,

ellie
------------------------------------------
Cyrus: Info
Permalink: 
https://cyrus.topicbox.com/groups/info/T6b93ab144d6e9957-Me3e7c8c99a7f1f0ff50e3b94
Delivery options: https://cyrus.topicbox.com/groups/info/subscription

Reply via email to