Aaron Stone wrote: > On Fri, 2007-03-30 at 13:44 +1000, Jake Anderson wrote: > >>> Perdition would solve the IMAP UID problem, but it doesn't help with the >>> plain old auto_increment collisions... >>> >>> >>> >> Yeah thats what i was thinking, to me thats just part of multi master >> replication. >> > > This is *the* core issue of multimaster. There are decades of work on > distributed lock management to figure out who gets to make what changes > to which critical data structures. > > And all those helpful people have done the work for us, aren't we lucky ;-> The only "danger" i see is doing admin tasks, everything else is no different to a single db server. >> Although... you wouldn't really need multi-master as each server really >> is the "real deal" with all reads and writes being done on it. The >> backup will only be used if the master is gone. It might still be an >> idea to set it with the auto_increment value (in mysql at least, i don't >> know about postgres), just incase you get a "split brain" situation. >> > > "The backup will only be used if the master is gone." is *the* core > issue! Split brain is a very real, very serious problem. > > STOMITH stands for "Shoot The Other Man In The Head" and involves > physically cutting power to the other machine to prevent a split brain. > In other words, the problem is serious enough that otherwise sane people > consider it a lesser risk to yank the power than allow a split brain. > > Again, its a solved problem, yes it has to be implemented but thats a matter of following recipes. With seperate auto-increments then there should be no collisions of auto ID's, and with all writes to one DB there should be no collisions on guids.
>>> If we combined Perdition with per-server auto_increment id windows, then >>> I think we'd be onto something! >>> >>> Aaron >>> >> Thats what i was thinking. >> postfix can direct mail to a host based on a database lookup. >> > > Can it? Point me to some docs and/or sample configs. If this can be made > to work, then we really would have a single namespace horizontally > scalable setup that we could recommend. > I read it somewhere specifically but from my readings of http://www.postfix.com/transport.5.html and http://www.postfix.com/ldap_table.5.html (or you could use sql rather than ldap) then i believe basically that postfix can look up a transport map per user, by writing the query to do so. dbmail has LMTP listening on the network, postfix looks up a transport map for said user (from its local replicated database?) and delivers it (after scanning?) to the correct server for that user. ultramonkey sitting in front of it to loadbalance your inbound smtp/content scanning servers. What would be handy is to have a tool that would let you add a server to the pool and would then move users onto it to spread the load. (presumably making that users account inactive during the changeover period)
_______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
