On Mon, 2007-03-26 at 14:36 +1000, Josh Marshall wrote: > Aaron Stone wrote: > > It solves the unique ID problem for MySQL, but not for IMAP. > > Hi Aaron, > > Before I put these servers into production I should ask: What are the > implications of doing this for IMAP boxes? I assume it fails somehow, > but what are the symptoms? I might be better off to use a replicated > mysql / heartbeat setup with failover instead if this is a problem.
The problem is that the IMAP UID is a strictly increasing number. When the spec was written, they basically wrote the requirements around the implementation, which was UIDVALIDITY being the inode number of the mailbox file, and the UID being the offset in the file to the beginning of the headers for each message. This is also where there's a two step delete process for messages, but not for mailboxes. The mailboxes are just files. When you delete them, they are gone. But messages are offsets in the mailbox file. So first you add a \\Deleted flag and then later an EXPUNGE command. EXPUNGE would copy all non-\\Deleted messages to a new mailbox file, causing a change in UIDVALIDITY because the new file would have a different inode number. The new file is then renamed to the old file's name, which is one of the few atomic filesystem operations available in the Unix environment. If a message is delivered and is assigned 12345 on the odd server, then another message is delivered on the even server at 12344, it will not be seen by a client that saw the 12345 message and so it thinks all new messages must be at 12346 or above. Aaron _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
