cyrus replication : master to replica and replica to master

[Jon .]

On Wed, Oct 21, 2009 at 9:20 PM, Rob Mueller <robm at fastmail.fm> wrote:
...

> The difference between "in theory this would work" and the practice of
> actually doing it are huge. Basically it works only if you are 100% sure
> that only one side is ever being accessed at a time. eg. IMAP/POP/LMTP/etc.

...

> In other words, DON'T DO THIS.
>
> Rob

What are the particular bits that could conflict and have undesirable
results? Metadata, messages, entire mailboxes? In this hypothetical
active/active configuration, what exactly what could an IMAP client
potentially do to create undesirable results?

Would it be a huge undertaking to timestamp data that is to be
replicated to another Cyrus daemon for the receiving Cyrus daemon to
know which conflicting pieces of data to drop in favor of newer data?

Right now I have a client who needs 130 or so users on a private mail
server and has two cheap 1U Dell servers to work with. Ideally they
are to be put in physically distanced data-centers for redundancy to
one another.

Combined with the hypothetical replication of timestamped data
describe above, wouldn't setting the fqdn imap.example.com to resolve
two IP addresses so users' IMAP clients can fall back should an IMAP
storage server be unavailable (with at least the most recent data
replication of any kind is able to provide) make for a much simpler
and more elegant solution than DRBD, clustered filesystems, or
introducing more machines just for load balancing / resolving to an
available IMAP daemon? Also, wouldn't timestamps also hypothetically
resolve the inevitable split-brain situations clients would create?