On 2014-05-30 06:49, Arnt Gulbrandsen wrote:
I should elaborate.
The mailbox ID and message UID (a number) form a natural complex
primary key. If two separated masters write to the database, then they
will either have a problem merging because of conflicting primary
keys, or the clients will have a cache accuracy problem. However, I
know a way around it, with probably even very good performance.
At rejoin time, each mailbox has to be considerd on its own. If there
are new messages on one side, fine. If there are on both but the new
messages are marked 'recent' on one side, then the 'recent' messages
can be renumbered and all is well. If there are new, non-recent
messages on both sides (this should be very rare), then IMO both sides
need renumbering so those UIDs are no longer used, and the mailbox
uidvalidity needs to be increased and current IMAP sessions
terminated. That should make both well-behaved and common IMAP clients
update their caches correctly.
A few days work, not more.
I remember doing a MySQL master-master setup a few years back and there
was a hack to have different increments for autoincrementing columns.
One server is 10, 20, 30, etc. The other is 5, 15, 25, etc. That would
prevent split brain from causing a conflict, but I have zero clue if
that's actually good database design.
Note: I don't need this functionality right now; it's just something I
was dreaming about if I ever had the chance to redesign the mail server
infrastructure at work. Though another issue altogether is finding away
to automatically migrate the old sieve scripts at time of migration...
