painful mupdate syncs between front-ends and database server

[Michael Bacon]

--On October 20, 2009 12:13:05 PM +0200 Cyril Servant 
<elfejoyeux at gmail.com> wrote:

> Hello,
>
> Here we had a similar situation : more than a million mailboxes, and
> each MUPDATE sync was veeeeery long (when it succeeded). Now, we
> bypass the problem : we get rid of the MUPDATE (and the skiplist
> mailboxes.db). We use a home made mysql backend for mailboxes. We
> added write and read filters to this backend so front-end and back-end
> servers get the right value from mysql.
>
> With this configuration, we're no more in murder mode, we just use
> front-end cyrus (proxys), back-end cyrus, and mysql. We don't need
> MUPDATE any more, so we have no sync problems. Cyrus restarts are
> fast.

Thanks for sharing this.  I have wondered a couple of times how much work 
it would be to rip out the master-to-slave MUPDATE code, and replace it 
with some kind of OpenLDAP replication that's a little more widely 
deployed, then just let MUPDATE be exclusively for conversations between 
the backends and master.  It sounds like MySQL would be something similar. 
I know the FastMail guys have abandoned the murder architecture too, and I 
can kind of see why -- it seems like the Murder code spends a lot of time 
and energy avoiding situations which don't come up very often, such as 
duplicate mailbox names between back-ends.  Right now, I think we need the 
murder's ability to deal with the fact that we have no logical sorting of 
users across the backends, but I didn't know someone had gone away from the 
murder mode but was still using Cyrus front-ends (and not perdition or 
nginx), which we still need for the GSSAPI client support.

Michael Bacon
UNC Chapel Hill