--On October 20, 2009 12:13:05 PM +0200 Cyril Servant <elfejoyeux@xxxxxxxxx> 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 ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
