Upgrade and Migration

[Ben Carter]

Carson Gaspar wrote:
> Ben Carter wrote:
> 
>> If you use rsync, you have to stop everything until that finishes, 
>> possibly reconstruct all mailboxes, maybe fix some other things before 
>> giving people their mail functionality back and allowing mail delivery 
>> to resume.
> 
> That's just silly. If you're going to use rsync to migrate data, you do 
> at least one rsync while the source data is live. More than one if the 
> initial sync takes a long time. Then you go offline, do a final sync 
> (which should be very fast), and bring the new data store online.
> 

The longer you wait to upgrade, the less silly it gets.  In the case 
of a move to completely new servers, doing a migration using the 
protocol can be much more appealing.

Also, we did what you suggest with rsync on our previous upgrade and 
we did an rsync every night leading up to the upgrade night, so the 
last rsync copied only a day's worth of changes.  The last rsync took 
hours even though we ran multiple rsyncs concurrently.  I think it may 
have taken as long as 6-8 hours, but I don't remember the exact timing.

> You have to do the _exact_ same thing with imapsync, unless you want to 
> lose email.
> 

As has already been pointed out, you are incorrect.  The order is:

[Pre-create inboxes with large quotas on new server]

1. Shut off mail delivery to old server
2. Shut off imapd on old server.
3. Bring up new server with imapd running
4. Start mail delivery to new server.
5. Start imapd on old server with a new IP address or bound to a 
nonstandard port so MUAs will not get to it.
6. Migrate data using imapsync.

And your service can be down literally for only a few minutes if you 
plan correctly.

>> Also, the ACL format in the mailboxes file might be different between 
>> these 2 Cyrus versions.
> 
> Might be, but I don't think it is.
> 
>> If you use the protocol to move the data, you don't have to worry 
>> about any data structure differences etc.  You also can re-arrange 
>> your partitions and so on.  Plus it re-calculates all quota usage as 
>> imapsync APPENDs the messages during the migration.
> 
> All true, except to the best of my knowledge none of this (except 
> repartitioning, which the OP didn't mention) matters for cyrus imapd - 
> it will Just Work(tm) on your old data store. The only exceptions are 
> database format changes (if you use bdb and you've revved the library 
> version, for example), and sieve compiled bytecode.

Yes, but that's the point: you can fix all those things that you 
always wanted to fix.  Spin out the mailboxes evenly again across 
partitions, change DB formats, use fulldirhash, go to fewer, larger 
partitions, leave unused mailboxes behind, etc.

Not to mention that the years of RENAME operations you did to move 
mailboxes left garbage behind that rsync would blindly copy over.

> 
> And why do you care about quota re-calculation? The existing quota data 
> should be correct.
> 

In our case, the problem was that the old code used 32-bit integers to 
track quota/usage so we had to have a cron job that zeroed usage on 
the old server for large mailboxes every once in a while.

Ben

-- 
Ben Carter
University of Pittsburgh/CSSD
bhc at pitt.edu
412-624-6470