<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>On Thu, Jul 23, 2015, at 23:42, Nic Bernstein wrote:<br></div>
<blockquote type="cite"><div>
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:<br></div>
<pre>##
# 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"<br></pre><div>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.<br></div>
</blockquote><div> </div>
<div>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.<br></div>
<div> </div>
<div>Bron.<br></div>
<div> </div>
<div id="sig567075"><div class="signature">--<br></div>
<div class="signature"> Bron Gondwana<br></div>
<div class="signature"> brong@fastmail.fm<br></div>
<div class="signature"> </div>
</div>
<div> </div>
</body>
</html>