Kevin Baker wrote:
2. The unique-id could be calculated with a date/time/sec/millsec base combined with a machine id added to the dbmail configuration to assure ascending and unique.This would allow for many machines to commit to their local mailstore with syncing handled by multi-master mysql replication. It would require that system clocks were in sync to maintain the correct ascending order. To handle the unlikely event that two messages were written to the same mailbox(folder) in the same millisecond for a specific user.. each machine could have its own 3 digit id that could be appended to the end of the unique id... keeping the correct sequence withouth any possibility of overlap.
This scheme is almost identical to how we operate our network of email filter servers. They're all tied together using MySQL and replication, and the master databases' tables receive replicated message log data from around 30 hosts. Each filter server generates message-ids based upon timestamp (1 sec resolution), machine ID and PID which in over three years of operation has never caused a conflict.
In addition, it's not uncommon for servers to become "disconnected" from the rest of the replication network, and the scheme just works -- when they reconnect, the message logs are resynchronised and everything just slots in together.
So, in my (somewhat qualified :) opinion a message ID scheme which concatenates timestamp to millisecond resolution with either machine ID or PID will survive replication between databases without a problem.
Simon. -- Simon Cocking <[EMAIL PROTECTED]> Network Operations MailGuard Pty. Limited Email anti-virus, anti-spam and content filtering Melbourne 68-72 York St South Melbourne VIC 3205 P +61 3 9694 4444 Sydney Level 39, 2 Park Street Sydney NSW 2000 P +61 2 9004 7889 http://www.mailguard.com.au/mg
smime.p7s
Description: S/MIME Cryptographic Signature
