Simon Gray wrote: > Paul J Stevens wrote: >> But there is another reason in the imap requirements: UID values must be >> strictly ascending within a mailbox. >> > Rather than making the UID just an autoincrement, why not make it a > function with time? Therefore as long as the servers are time sync'd > (easy with ntp) you should be able to increment the number based on the > time, perhaps there is some way to concatenate the date? E.g. > > To have > Server A odd auto_inc > Server B even auto_inc > > new uid = sql concat(unix_timestamp(), UID) > > Therefore they should always increment and be unique between servers? > > Worth a thought or completely silly?
Worth a thought *and* not-quite-silly but it still wont do. In fact I did an implementation of this once. There will still be ample opportunity for one server to store a UID that is below the MAX(uid). *Any* chance of such an occurence is a fatal blow to your algorithm. My more fundamental conclusion was that the whole master-master dream is a myth: it doesn't solve anything. It doesn't scale at all. Does it offer higher throughput? Does it offer lower latencies? Does it offer higher reliablity? Does it offer higher availability? think about it. -- ________________________________________________________________ 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
