janne.peltonen at helsinki.fi
Thu Nov 30 10:20:50 EST 2006
On Wed, Nov 29, 2006 at 11:46:46AM -0500, Wesley Craig wrote:
> On 29 Nov 2006, at 10:46, Janne Peltonen wrote:
> >The part '... all "replicated" servers can serve the same mailboxes
> >from a
> >shared filesystem' attracted my attention. Is this the LB that is
> >reported not
> >to work with current murder/replication? Or is this something else?
> In the "replicated" mupdate_config, each backend (nothing to do with
> replication) is meant to serve data from a common mail spool, while
> maintaining a "replicated" copy of mailboxes.db. The changes to
> implement this IMAP_ENUM_MUPDATE_CONFIG_REPLICATED are isolated to
> imap/mupdate-client.c, effectively to just remove references to the
> backend server. So, this configuration would remove the various
> locking problems surrounding mailboxes.db, since each backend would
> be maintaining a separate copy. Any concerns related to locking in
> the mail spool would still be relevant, tho that locking is typically
> less esoteric. You'd need to have an mupdate master as well.
Now /this/ is an interesting feature. Does away with the need to share
the config dir... I think. LMTP delivery should work (with MUPDATE), the
same with duplicate delivery suppression.
Mm. Comparing this solution to sharing the configdir:
+no file locking issues, that is:
+no contention to mailboxes
+can use any database format
+can use duplicate delivery suppression
+officially supported, so won't stop working with future versions
-must use mupdate master -> SPOF? not if the mupdate master is an
-how synchronous will the metadata be?
So if I'm correct, to achieve a true single server image, you don't
actually have to sync anything but the mailboxes list... sieve,
delivery, dupl suppression etc. should "just work". Nice.
More information about the Info-cyrus