On Mon, 2007-03-26 at 01:59 -0500, Rob Gil wrote: > To sum this all up, HA and failover is really impossible with the > current method of ID delegation. What is possible however is: > -Single Master with slaves. (this seems to be useless however since > there is no functionality to separate reads and writes) > -Load Balancing IMAP/POP3 servers > > Am I correct in my conclusion here?
Yes. There is no in-application support for assigning message id's in a way that is compatible with anything other than "single master" and we do not yet have a way to throw reads at one database and writes at another. Even if we did, it would be a bad idea because there's a very high ratio of writes to reads, so you'd potentially write something to the master and read back an older derived value on the slave. When we do get to doing the serious clustering work, we'll probably use memcached to handle these sorts of ephemeral values. > It seems the scale of dbmail is really dependent on a single database > which is really a single point of failure. For the most part this is true, and it is the same limitation you have with filesystem based email storage. We haven't taken any steps backward, we've just taken a while to get into a position to take big steps forward :-) The scalability of that single database of email has already proven to be highly competitive with email on filesystems. The latter has had 20 years of development, while we've had about 5 years of experience with email in a database. Replicated filesystems have run around in circles for the past 20 years, while replicated databases are functional and getting better as we speak :-) > Thanks for all the responses, > ~Rob You're most welcome! As noted, we're just about in position to start making some seriously awesome leaps forward on the HA and replication issues, but we haven't started down that road yet as we're focusing on getting right what we do right now. Aaron > Aaron Stone wrote: > > 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 > > > > _______________________________________________ > DBmail mailing list > [email protected] > https://mailman.fastxs.nl/mailman/listinfo/dbmail _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
