Hi, I’ll add a few learnings from my upgrade from 2.5 to 3.4 [Centos8]
Sync between 2.5 to 3.4 direct didn’t work for me directly and never got the bottom of the issue. I included an intermediary step. The path I used was: - Version 2.5 to 3.2 - Version 3.2 to 3.4 I found that I had to clear conversation history to get the sync to work (forget if it affected sync between 2.5 and 3.2 or between 3.2 to 3.4). You may experience a similar issue, be great to hear if you encounter that problem also or perhaps I had a configuration issue and clearing it was “a hackish last resort approach”. There may have been another solution to it but couldn’t determine root cause so trial by fire (rightly or wrongly). In my case I ran 3.2 and 3.4 with double sync running at the same time. I carried out functional IMAP (Read Only) access to 3.2 and 3.4 to validate configuration/authentication/cal-card-dav was working as desired. Careful not to make any changes in the IMAP client during that testing. When I was comfortable that the 3.2 and 3.4 server was running correctly and mailboxes accessible on the 3.2 and 3.4 server and the sync was in place, I then had confidence to stop the access to 2.5 at the firewall level, confirm that 2.5 > 3.2 and 3.4 were in sync, then transitioned the NATs and firewall rules and re-enabled access. - 2.5 > sync > 3.2 > sync > 3.4 This approach seemed to provide a way to fall back to a previous state before the change window when you stop. This way mail will queue upstream and then be delivered to the latest cyrus server when you update the NATs and firewall rules. Just have to try and prevent mail delivery to the older server once clients go live on the latest versions. To simplify things further and reduce some extra complexity, I de-coupled the postfix service from the IMAP servers and separated that functionality from the mailbox servers. I wrote ansible scripts to take care of most of the migration/configuration updates and deployment approaches – ensuring I got consistency in configurations and removing my “fat finger” syndrome. I’ll be doing a similar thing to move to the latest version. Sharing my experience just in case you encounter replication issues when going between the versions (conversation history was the culprit for me and I spent quite a bit of time and reading forums to find that this was likely problematic). Regards, Andrew From: Michael Menge Sent: Tuesday, 14 September 2021 7:38 am To: Info Subject: Re: Migration from 2.5 to 3.4 Hi, Quoting Andrea Venturoli <[email protected]>: > Hello. > > In the next week I'm changing a couple of servers where 2.5 is > running and I'm thinking of taking advance of this opportunity to > migrate to 3.4. > I've never performed a replication before, though. > > My idea would be: > _ set up the new server as replica; > _ set up the old as master; > _ call sync_client a few time; > _ firewall the old server so that it receives no changes from clients or MTA; > _ call sync_client the last time; > _ shut down the old server; > _ change the IP of the new server to be the same as the old one; > _ remove the replica settings. > > Is this list correct? i have no experience with cyrus 3.2 of 3.4, but 15 years with cyrus 2.3 to 3.0. This should work fine. There is one potential pitfall I see regarding the replication. The replication protocol used change between 2.5 and 3.0 from "csync" to "imap" As 2.5. is unable to sync via IMAP you have to use csync with sync_server I also would change one thing. And i would add an additional step - use rolling replication. If you configure cyrus to use rolling replication it will create a log to tell the sync_client where something has changed. With this you only need one initial sync_client run, and one sync_client run with the "-r" option. You can monitor the sync change log(s) and can start switching to the new server as soon as there are no logs. this will reduce the number of runs for sync_client and will shorten the downtime for switching as there is no "final" sync_client run. - You should restart cyrus on the new server after switching the IP If your setup allows your services to listen to "0.0.0.0" instead of a specific IP you can configure the new server so that you don't need to restart the cyrus service after switching the IPs (the sync_server would still be running without being needed) > Unfortunately I see the failover chapter is still missing from the docs... In your case failover is not complicated. The tricky part is switching forth and back and automation / split brain / active-active setups In your case the difference between a replica and a master with out replication are the services running / configured in cyrus.conf The replica needs the sync_sever or imap server depending on the replication protocol used and no other service. You can configure the other services used by the master (lmtp, pop, sieve, ...) if you only allow replication write access and prevent all other write access The master needs the other services and does not need the sync_server -------------------------------------------------------------------------------- Michael Menge Tel.: (49) 7071 / 29-70316 Universität Tübingen Fax.: (49) 7071 / 29-5912 Zentrum für Datenverarbeitung mail: [email protected] Wächterstraße 76 72074 Tübingen ------------------------------------------ Cyrus: Info Permalink: https://cyrus.topicbox.com/groups/info/T31d4933e422af363-M1f7c9c83a8f99efc9ff2f797 Delivery options: https://cyrus.topicbox.com/groups/info/subscription
