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? > > It seems the scale of dbmail is really dependent on a single database > which is really a single point of failure. > > Thanks for all the responses, > ~Rob Perhaps try postgres? I don't know for sure but i believe it doesn't have the clustering limitation mysql has.
Your other option is a perdition proxy in front of your mail servers (perhaps ultramonkey that so you can HA that point) Then run your databases in replications of 2 (or more). mmmm yes that could work. Tell perdition that users with a name starting with A are on server 1 B is on server 2 servers A and B are full up dbmail stacks. tell the *databases* in dbmail to replicate to each other. The uid's will increment non sequentially but as each *users* uid will go up sequentially (ie all db reads and writes to/from/for that user hit the one DB) all should be well. your HA comes in when a server fails, you tell perdition (and your smtp routing) that the user is on the non failed server. Emails that come in during the change over could stuff up but well tough, the connections are going to drop anyway. There is no performance benefit to the user being on the other server (its actually a performance hit) you do it simply for redundancy. But then I spose any increase in redundancy is going to cause a performance hit as you have another machine doing the same job when it could be doing a different one. Please make all donations payable to Jake Anderson, cash only l->
_______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
