about the replication
robm at fastmail.fm
Wed Jan 23 23:35:41 EST 2008
> I ran my script last night on one of the back-ends. This one has 20928
> mailboxes. And 1067 are not in sync. From those, 897 users didn't have
> all their mailboxes replicated to the replica. The others had the same
> folder count, but one or more messages were not the same (or weren't
We also have a script which does this for all users every week. It checks
for each user that the following match:
1. Folder list
2. Folder subscriptions
3. Quota (total + used)
4. Sieve scripts
5. For every folder, status output for (messages uidnext unseen recent
6. For every message in every folder, flags + message sizes + GUID
All of those are reasonably quick since they access only meta-data. We also
check on a regular basis for a random sampling of messages that rfc822.sha1
on both sides match.
The script also waits for a few seconds and retries if there's any problems
(replication is non-synchronous, so there may be delays in differences
between both sides).
If there's a mismatch problem, the script can be set to:
1) Run a sync_client -u
2) Run a reconstruct on both sides
3) Completely delete the replica mailbox and run a sync_client -u to build a
complete new copy from scratch
One annoying thing we've found recently is that sync_client -u doesn't fix
quota problems, it seems the protocol doesn't include an absolute "set
replica quota to this" action. We'd been meaning to look into that but
hadn't got to it.
David: Don't suppose you could check that out? It would be nice if
sync_client -u could really fix every user problem, it's very close to that
right now, quota mismatches seems to be about the only thing it can't fix.
FYI, unfortunately at the moment this script is fairly closely tied to our
system (it uses a bunch of other modules to work out master/replica servers
for a user). It probably would be nice to factor that stuff out so others
could use it...
More information about the Cyrus-devel