On Thu, Jul 23, 2015, at 23:42, Nic Bernstein wrote:
>
This raises potential problems when one deploys replication within a
murder (Cyrus aggregation). Only one server may claim ownership of
any given mailbox, via a mupdate call, so an instance which is a
replica MAY NOT push updates to mupdate master, or mayhem will
ensue. Here's a commented section from /etc/cyrus.conf on a
replication master instance:
> ##
# Master sends mailbox updates to mupdate. Replication client runs on
# Master. Comment these 2 lines out on replicas
mupdatepush cmd="/usr/lib/cyrus/bin/ctl_mboxlist -m"
syncclient cmd="/usr/lib/cyrus/bin/sync_client -r"
> A nice daydream of mine envisions a world wherein mailboxes.db keeps
track of replica locations, as well, which would allow for the dual-
role operation Ellie describes.
Absolutely - and more to the point, the central mailboxes.db should
actually have keys like mailboxname@servername or something so that
values from one server don't overwrite values from another server. It
should always reflect the sum of the states of the backends. It would
remove a ton of ordering issues from XFER as well.
Bron.
--
Bron Gondwana
br...@fastmail.fm
