Gordan Bobic wrote: > Sure, but this isn't really "losing" mail. It just means the client may > not see it unless the mailbox is fully refreshed. In case of the inbox, > I think this sort of thing may happen anyway (e.g. moving a message from > a different folder back into the inbox, or using difference clients from > different machines).
Wrong. Inserting a message (like when you move a message) into a mailbox will always create a new (higher) uid value. Losing email in a true multi-master setup - where message insertions on the same mailbox happen on both masters, beit through lmtp or imap - will be *very* common. Changing the uidvalidity of a mailbox - by changing the mailbox_idnr and thus forcing the client to rebuild the mailbox view - is not a solution for normal daily operations. In fact knowing when this would be required is not trivial. In short: A very bad situation that was discussed at great length many times already. There are solutions on the horizon: - build-in multi-master support using something like the token-ring global lock described in the wiki. - don't use multi-master. The first will require a new daemon that will act a distributed lock manager implementing a 2phase commit design. Difficult to do correctly, and I suspect a serious performance penalty. Better ndb support would be a more realistic approach. For the second solution to work while retaining the capability to scale out, all we need is supporting multiple database backends *at the same time*. That way, you can assign (groups of) users to separate backends. Such a backend can then be a master-slave setup, or a full star-based replication setup (like postgresql uses iirc). So separate sets of users are spread over separate sets of database clusters. Add in the ability to move users from one cluster to another, retain the global user namespace so users on different clusters still have access to eachothers' mailboxes if allowed by the acl, and you have a massively scalable enterprise setup. The second solution is my favorite since it builds directly on the work I've done with libzdb in 2.3.x. -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
