On Thu, Jun 28, 2007 at 01:57:57AM +0300, Janne Peltonen wrote:
> I'm running a unified murder and have been experiencing a strange
> problem. I shut down a cluster member cleanly, then start the member
> again, run ctl_cyrusdb -r and ctl_mboxlist -m, all goes well (even if
> the ctl_mboxlist -m takes a long time), the services start - the mupdate
> slaves starts to synchronize with the mupdate master, and, at the
> beginning, throws away all records of remote mailboxes! Only after it
> has synchronized with the master does it know how to proxy to other
> murder members. Now what might be wrong here?
Of course.
It wasn't the mupdate slave that did the truncating.
It was the ctl_mboxlist -m that did it.
Now I wonder. ctl_mboxlist -m truncating the local ("backend") mailboxes
list to contain only local mailboxes makes perfect sense - in a
/traditional/ murder. But mine is a unified murder.
There /is/ the line
mupdate_config: unified
in my imapd.conf. So the ctl_mboxlist -m has all the information it
requires /not to truncate the mailboxes list to contain only local
mailboxes/.
So what is the preferred way to go about the initial mupdatepush in a
unified murder?
a) skip running the ctl_mboxlist -m at all
OR
b) run ctl_mboxlist -m -a
Option a) might cause the mupdate slave that is started in the services section
of cyrus.conf to delete all local mailboxes from the mailboxes list in
case there is a corrupted mupdate master running. On the other hand,
this is quite a small added risk - if the mupdate master mailboxes list
is ever corrupted while the slaves are running, the slaves will delete
the mailboxes from their lists... This seems to me to be a bit of a bug
in a unified murder: I think that the slaves should refuse to delete
local mailboxes in a unified murder. (Fortunately, the actual mailbox
directories don't seem to get deleted, so the situation can be easily
saved from mailbox list backups.)
Option b) might be more interesting (I haven't tried it out yet). The
man page says that "assume the local mailboxes file is authoritiative,
that is, only change the mupdate server, do not delete any local
mailboxes. USE THIS OPTION WITH CARE, as it allows namespace collisions
into the murder" - now I wonder whether the remote mailbox entries will
still be deleted... Well, I'd better try it out next. Reports to follow.
(There is still the option c), that is, run the ctl_mboxlist -m
normally, wait for minutes to hours (depending on disk load) for the
mailboxes list to get truncated, then a similar amount of time for it to
get repopulated with remote mailboxes - now you might see why I'm not
really considering this option.)
(And then there's the option d), that is, somebody changing the
ctl_mboxlist -m behaviour in the unified config. I myself don't have the
time to get this closely acquaintated with Cyrus code; production
deadline is way too close.)
--Janne
--
Janne Peltonen <janne.peltonen@xxxxxxxxxxx>
----
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
