On 07/23/2015 01:14 AM, ellie timoney wrote:
Is the file format of the sync log defined anywhere? I assume it
>correlates with a set of commands. (Not that this is important to a
>user: it may as well be opaque, but it made me wonder!)
I'm a bit confused about this myself. Each time I go digging into the
code my understanding flips back the opposite way.
I think, either:
* the sync log contains all the information needed to reproduce what's
happened (e.g. if a message has arrived, the sync log will contain the
message itself); OR
* the sync log contains just enough to identify things that have changed
(e.g. if a message has arrived, the sync log contains a message id of
some sort), and the sync_client processing the log just uses the log to
discover which things to sync, but then uses the actual mailbox to
construct the changes to send to the replica.
Either way I haven't seen any documentation on the sync log format. I
suspect it's either the raw sync protocol or some subset thereof?
Okay, I'll bite. Here's what a bit of a sync_log looks like:
MAILBOX user.newjersey
MAILBOX user.support
USER onlight
USER nic
USER admin
USER randy
MAILBOX user.randy.Trash
USER lynn
MAILBOX user.lynn.Trash
It's basically a list of either users or mailboxes which have been
altered. When sync_log is enabled, all of the daemons which might alter
a mailbox or user will write a line to this log each time they do so.
That means the obvious suspects -- imapd, pop3d, timsieved, lmtpd, etc.
-- but also cyr_expire and friends (as in the USER...MAILBOX couplets at
the end of the sample).
- a single cyrus instance may be the primary server for some users but a
replica server for other users
Are you sure about that? How does one specify the users for which such
an instance would play each role? A single HOST may run separate
instances, which may perform these different roles, but I cannot fathom
how to configure a single instance to do both at once for different user
cohorts.
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.
Cheers,
-nic
--
Nic Bernstein n...@onlight.com
Onlight llc. www.onlight.com
219 N. Milwaukee St., Ste. 2A v. 414.272.4477
Milwaukee, Wisconsin 53202 f. 414.290.0335
