Date: Tue, 22 Jun 2004 12:03:13 -0600 From: Danny MacMillan <flowers@users.sourceforge.net> To: freebsd-questions@freebsd.org Cc: Bill Moran <wmoran@potentialtech.com> Subject: Re: What's the best possible email failover solution Message-ID: <200406221203.13704.flowers@users.sourceforge.net> In-Reply-To: <20040621132006.2b1a296f.wmoran@potentialtech.com> References: <20040621132006.2b1a296f.wmoran@potentialtech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200406221203.13704.flowers>