unified murder gets mailboxes list truncated
janne.peltonen at helsinki.fi
Sat Jun 30 09:22:21 EDT 2007
On Sat, Jun 30, 2007 at 03:16:30PM +0300, Janne Peltonen wrote:
> b) run ctl_mboxlist -m -a
> 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.
Well. Running ctl_mboxlist -m -a didn't truncate the mailboxes list, but
it took relatively long to complete (21 minutes with only one cluster
member doing it - on the other hand, since the ctl_mboxlist wasn't busy
writing this time, the time required to do the ctl_mboxlist will
probably stay the same regardless of the number of members doing it).
Additionally, the -a option really does as it says - the local mailboxes
list is authoritative. That is, it's authoritative over the complete
murder (which I find very strange) - if I delete a remote folder from
the local mailboxes list, then do ctl_mboxlist -m -a, the master records
the deletion and propagates it forward... the mailbox disappears from
the complete murder.
So there seems to be no way to get a unified murder up and running so
that there isn't some risk of information loss - actually, I already
knew this; there is a constant running risk of information loss if the
mailboxes list on a running murder's mupdate master gets corrupted (the
corrupted list if propagated to all the members) and the backups are
lost. It'd be really really nice if somebody changed the ctl_mboxlist
and mupdate slave code so that if the murder config is unified, the
local server is authoritative on local mailboxes - and /only/ on local
I wonder if it's too late to convert my murder to a traditional one...
More information about the Info-cyrus