Making Replication Robust
David Carter
dpc22 at cam.ac.uk
Tue Oct 9 11:10:19 EDT 2007
On Thu, 4 Oct 2007, Bron Gondwana wrote:
> a) MUST never lose a message that's been accepted for
> delivery except in the case of total drive failure.
>
> b) MUST have a standard way to integrity check and
> repair a replica-pair after a system crash.
A replica system is automatically repaired to match its master, but this
doesn't help with the split brain scenarios that you are worried about.
I've never faced a spilt brain situation which involved more than two or
three messages (the outstanding log on an old master system). I suspect
that this is simply because I've never had to run an unreliable
replication engine which bails out on my production systems.
> c) MUST have a clean process to "soft-failover" to the
> replica machine, making sure that all replication
> events from the ex-master have been synchronised.
Something more than sync_shutdown_file plus automatic retries on
recent work files?
> d) MUST have replication start/restart automatically when
> the replica is available rather than requiring it be
> online at master start time.
Work in progress from Ken.
> e) SHOULD be able to copy back messages which only exist
> on the replica due to a hard-failover, handling UIDs
> gracefully (more on this later),
This is the hard one. I think that assigning a new UIDvalidity and new
UIDs for all the messages would be best as messages can then be sorted in
the replacement mailbox based on their arrival time. Actually this would
look remarkably like the new sync_combine_commit() on the replica side.
What I don't know is how we then synchronise back to the master. Up to now
the replication engine has been very careful about _not_ making changes on
the master, so that it only has the potential to mess up the spare system.
> alternatively as least
> MUST (to satisfy point 'a') notify the administrator
> that the message has different GUIDs on the two copies
> and something will need to be done about it (to satisfy
> point 'd' this must be done without bailing out
> replication for the remaining messages in the folder)
At the moment we replace messages (on the "master knows best" principle).
It would be easy enough to leave message in place and generate warnings
instead, although this would generate a lot of warnings, one for every bad
message every time that a given mailbox is updated.
> f) SHOULD keep replicating in the face of an error which
> affects a single mailbox, keeping track of that mailbox
> so that a sysadmin can fix the issue and then replicate
> that mailbox hand.
You could try disabling the MAILBOX -> USER promotion to see what happens:
the 3 x MAILBOXES retry will fix most transient problems caused by
mailboxes moving around, leaving just the permanent errors.
The MAILBOX -> USER promotion was originally there on the principle that a
mailbox disappearing under our feet was likely to appear somewhere else in
the same account (without shared mailboxes to worry about).
My nightmare scenario is a replication engine which carries on running in
the face of mboxlist corruption on the master: you could lose a lot of
mailboxes on the replica that way.
> g) MAY have a method to replicate to two different replicas
> concurrently (replay the same sync_log messages twice)
> allowing one replica to be taken out of service and
> a new one created while having no "gaps" in which there
> is no second copy alive (we use rsync, rsync again,
> stop replication, rsync a third time, start replication
> to the new site - but it's messy and gappy)
It would be easy enough to generate multiple replication log files.
MySQL keeps a single transaction log for multiple replicas, but that file
contains quite a lot of information about each transaction. In contrast
the Cyrus sync log is just a list of objects we need to pay attention to:
the files have much less state, particularly without duplicates.
--
David Carter Email: David.Carter at ucs.cam.ac.uk
University Computing Service, Phone: (01223) 334502
New Museums Site, Pembroke Street, Fax: (01223) 334679
Cambridge UK. CB2 3QH.
More information about the Cyrus-devel
mailing list