Replication documentation anywhere?

Adam Tauno Williams awilliam at opengroupware.us
Fri May 24 15:40:47 EDT 2013


On Fri, 2013-05-24 at 09:41 +0100, Karl Pielorz wrote:
> --On 24 May 2013 11:10 +1000 Bron Gondwana <brong at fastmail.fm> wrote:
> > I'm afraid there isn't much :(  Feel free to ask questions about
> > specific things you run in to, and we can use that as a basis to put
> > together more detailed documentation.
> Thanks for your reply (which I've read through now!) - if we have an 
> existing mailstore (with ~2-3 million emails) and we setup a replica is 
> 'sync_client' going to be able to bring the replica to the same state as 
> the master? (given time, and not too many changes on the master?) - or are 
> we better off using another method (such as FS snapshot -> replica).

Yes, a syncrepl will theoretically transfer all the contents of the
server.  But it might be rather brutal.

Personally I would:
 (1) rsync the message store from the master to the slave [this will
bulk move tons of files,  mailboxes moved first could be quite out of
date by the end.]
 (2) rsync the message store from the master to the slave [this will
only moved changed stuff, and give you a reasonably current snapshot of
the mailstore.
 (3) rsync the meta-data [/var/lib/imap] from the master to the slave.
 (4) run reconstruct on the slave to make sure everything is consistent
 (5) run "sync_client -v -r  -z" in screen and watch it for a bit,
verify that messages get replicated as expected
 (6) switch to running sync_client 'for real'

You can run "sync_client -z -u {user}" to sync a user, so if you have an
easy to use list of all your users, or "-m {mailboxes}" if you generate
a list of all your mailboxes.  This can help to 'push' the towards
making sure the replica is up to date;  and running multiple
sync_client's seems to work OK.




> 
> Presumably the replication doesn't do anything for users (we use sasl for 
> auth, i.e. saslpasswd2 to create the users) - if we intend to have users 
> 'hitting' the replica (when the master as failed) presumably we'd need to 
> create those users / passwords on the replica as well?
> 
> In a nutshell - when we have the master / replica setup, if we 'switch' to 
> having users hit the replica (because the master has failed) - it appears 
> we can simply 'switch' the replication configs over, and then have what was 
> the master 're-sync' with the new master?
> 
> I guess what I'm trying to figure out is if the replication / 'sync_client' 
> is the 'magic' solution is appears to be - i.e. given enough bandwidth, 
> time / 'grunt' & low enough volume of changes on the master - it'll drag an 
> empty mailstore up to be an identical replica, or re-sync a once failed 
> master to be a new replica.
> 
> Thanks again for your time,
> 
> -Karl


Adam Tauno Williams <mailto:awilliam at whitemice.org> GPG D95ED383
OpenGroupware Developer <http://www.opengroupware.us/>



More information about the Cyrus-devel mailing list