What's the best possible email failover solution

[Danny MacMillan]

On June 21, 2004 11:20, Bill Moran wrote:
>
> ...
>
> Does anyone have a solution to provide real-time mirroring of IMAP
> folders?
>
> ...

Hi.  I know I'm a little late to the game, but I'm going to posit an 
alternative quite different from anything that's been suggested so far.

It seems to me it wouldn't be too much trouble to implement an IMAP server 
that does nothing but proxy IMAP sessions to multiple back end IMAP servers.  
IMAP commands that modify the mailstore could be forwarded to both (or all 
three, or n) backend IMAP servers, while commands that read from the mail 
store would simply pick one (either statically or dynamically) and use it.

The advantages of such a system are these:
1. It really is real-time.
2. Low overhead.
3. It is completely independent of your choice of back-end IMAP servers.
4. I thought of it, and it is therefore brilliant.

The most significant disadvantage is that you have to determine how to handle 
the case when the back-end servers disagree about the status of an update 
operation (e.g. a message was successfully stored in one back-end server but 
could not be stored in the other).  I doubt it would happen very frequently 
if things were set up correctly, but it would happen.  Handling this for the 
general case could be prohibitive in terms of implementation time, but even a 
rudimentary implementation solves your problem quite handily:

1. Identify one of the back end servers as the master, the other as the slave.
2. All reads are from the master.
3. All writes are to both master and slave.
4. In the case where the master and slave disagree about the status of a 
write, the master's status is taken to be gospel.
5. As a part of your normal daily backup, the slave shall be rsync'd to the 
master to overcome any discrepancies that might arise.
6. If the master goes down, the slave becomes the master.

This strategy would be no good if you wanted dynamic load balancing across the 
back end hosts, but you haven't identified that as your principal goal.  It's 
certainly more than 'good enough' as a real-time mirroring strategy that 
fills the gap between your 24-hour-apart total backups.

Hmm...as I write this it occurs to me that the different back-end servers 
would probably assign different message IDs to each message.  That would 
probably invalidate client caches if the slave were restored, which greatly 
reduces the utility of this method.  Still, I'm sure you can overcome that 
one tiny flaw in this otherwise perfect diamond.  :)

--
Danny MacMillan