[Forgot to send this to the list; sorry. >>>>> "BG" == Bron Gondwana <brong@xxxxxxxxxxx> writes: BG> No, sorry. I figured as much; I backed off to 2.3.7 on the new machine so that I could get a good replica. BG> Replication across versions is trick at the best of times, and BG> you're talking about versions 3 and a half years apart! I had guessed, though perhaps I had hoped that something would simply tell me that instead of giving odd errors that made me think that I had misconfigured something. But I think I have my plan of attack readied. BG> Unfortunately, your only real option is to upgrade to 2.3.16 on both BG> at roughly the same time. Actually my plan is to simply abandon the old, failing master (leaving it with the current content in case things blow up), upgrade the replica to 2.3.16, make it the master and set up yet another machine as a replica. BG> The upgrade itself should go seamlessly. Because of the mailbox BG> format change, you will get an IO hit as each mailbox open causes a BG> full index file rewrite to upgrade it to the new format! Not a big deal, though I wonder if there's any way I can force this to happen all at once in the middle of the night instead of when some user happens to open their multi-gigabyte inbox. The new machine is seriously over-specified for the task at hand so I don't think the extra IO will be a problem, but it would still be nice to do it all at once. BG> This also means you can't downgrade again without doing a full BG> reconstruct of every mailbox. I hope to not need to do so, but in case I do, that's just reconstruct -r on everything under user, right? I guess it's a credit to the software that I've never really have to mess with the recovery tools in the years I've been using it. - J< ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html