Today's pop quiz: replication

[Bron Gondwana]

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 at 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
  brong at fastmail.fm
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20150804/48fd058f/attachment.html