Jeroen van Aart wrote:
Hello,
Excuse me for posting this again, but now on imap-uw instead of
imap-use. I have given this quite some thought but haven't yet found a
satisfactory solution. Having multiple smtp servers and failover
servers is not a problem. But the problem is if the server which
contains the user's mailboxes fails, no amount of failover will help
as users still can't read their email.
Hence my question.
Is there any practical way to do replication using imap? So that every
imap action is mirrored to another server and you have in fact 2
identical copies of the mailboxes.
There are other things that you must consider in such a scenario:
* Email delivery from the MTA must go through the same replication
process and be synchronized with all of the other imap commands being
issued. This is required to ensure that message UIDs match exactly.
* Non-IMAP functions must be correctly replicated. These would include
user creation and management.
* Any process that attempts to implement such synchronous activity could
very easily make the system more fragile:
- Adding another failure point
- IMAP does not have a transactional system like a database where you
can "roll back" in the case of failure.
- The case of multiple-user simultaneous access to a mailbox will create
many problems as the sequence of imap commands actually executed on one
sever must match in order the exact sequence on the other server or you
may end up with inconsistent results. This imples a cross-process
synchroniation that is not currently in uw imap and which would cause
some significant potential bottlenecks.
I too wish there were some easy to apply protocol-level replication to
uw imap, but this seems like it will cause many more problems that it
will solve. Probably the only true solution to this issue is:
* Put the data on a san that is internally redundancy
* Connect the san to redundant servers with redundant HBA cards.
* Set this up with an automatic failover device which, on failure of the
main server, will switch the IPs of the machines and re-mount the san on
the backup server.
This provides no single point of failure, eliminates the need for
replication, and eliminates the lock bottlenecking with SAN use. It
also gets around the various bugs currently (RedHat v4 and lower anyway)
with GFS use and a shared SAN.
I'm still on the look out for better solutions. However, we subscribe
to the same philosophy that UW does ... divide you users on many
separate solid servers that in and of themselves are unlikely to fail.
If they do, you have backup hardware and recent data backups to recover
just the affected users. Ramp up redundancy with cost by adding
hot-spare servers with very recent backups (hourly or so) of the main
server or to the SAN solution above.
-Erik Kangas
LuxSci.com
If you check here it talks about replication for subversion, using
svnsync. On every commit an automatic update to a mirror will happen.
If the main svn server fails users can switch to the mirror and
continue. It's not email, but I was thinking a similar functionality
is possible using imap.
Thank you,
Jeroen
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
