upgrading a 2.2.12 murder to 2.3.14

Brian Awood bawood at umich.edu
Thu Jul 16 10:55:57 EDT 2009


On Thursday 16 July 2009 @ 05:21, Gavin Gray wrote:

> 2. We should end up then with our existing murder but with three
> backends running 2.3.14. We then plan to upgrade the other machines
> in the murder to 2.3.14 in the following order: frontends then lmtp
> and finally the mupdate server. Does this make sense?

This is the order we did our 2.2->2.3 migration in, although 
technically it shouldn't make much difference.  We ran a mixed 
environment for quite a while (2.2 frontends and 2.3 backends) 
because we wanted to enable unified murder on the 2.3 frontends so 
they wouldn't ask mupdate for a mailbox location on every connection.  
We had a separate patch that gave us this behavior in 2.2.

> 3. As part of our preparation for this work we have been
> experimenting with cyrus replication. The replication protocol
> seems pretty solid, however we have some concerns about how to make
> use of it in our upgrade. We are considering having a replicant
> machine for each of the new backends. But this makes the migration
> even slower. In our tests, if we migrate users via xfer to a
> machine that is doing rolling replication, the replication takes
> around three times as long to complete as the xfer. Does anyone
> have any experience of migrating to a replicating environment?

replication is significantly slower than xfer, but it shouldn't affect 
the speed of xfer.  We wrote some scripts to prevent xfer from 
getting too far ahead of replication.  Since our replicas are a key 
part of our DR/backup strategy, we never would want to get in a 
situation where a large amount of data wasn't replicated.  In your 
situation it shouldn't matter since the data is not replicated 
currently, you should just be able to enable rolling replication and 
let it catch up.  If you still would like to keep xfer from getting 
too far ahead of replication, I can probably post the scripts we use 
for this.  

-Brian


More information about the Info-cyrus mailing list