You wouldn't be able to separate reads and writes because the IMAP/POP3 servers are so much faster than the database replication that even something as simple as moving a message from one folder to another would appear to have failed but then suddenly take effect a few seconds later. The delay would get worse as the load went up, making a medium load system appear even laggier and buggier than a heavily loaded one.
Allowing a slave to step up to master status presents another problem because at the time of resynchronization, you are likely to find that changes were committed to the failed master before they could be propagated. This leaves the sequence numbers in a perfect position to collide and cause a full halt of all replication until manually restored (this is further explained in the MySQL manual). I've been thinking about this problem, and it might be possible to eliminate the auto_increment fields, using only the unique id of each message as its handle. It's just a thought, and would require a lot of work to implement the full semantics to maintain referential integrity, but might be a good place to start. [enable soapbox] If you *must* have five 9's, then you need to get a *budget* for five 9's. [set soapbox=off] Aaron On Thu, 1 May 2003, Michael Shuler wrote: > >From what I can tell MySQL can only have one master server that can take > writes but many slave replicating servers that can be used for reads. If I > can only write to one then I would think to optimize performance I would > want to only write to the master and do all my SELECTs to a cluster of slave > replicating servers. Does dbmail support using 2 or more different IPs for > reading vs. writing? > > > > Any suggestions on how to handle a master MySQL server failing and having a > slave automatically taking over as master, or being able to write to any of > the MySQL servers in the cluster? I'm trying to build a 99.999% (or better) > uptime system. Oracle will let you write to any server in the cluster so > you can use a Foundry switch or any layer 4 solution to load balance and > handle failover..their SQL solution is awesome but at about $100K it is way > out of my reach. Any suggestions would be VERY appreciated. > > > > Mike > > > > PS: Before I get told to look at the message archives Yes, I looked at them > but I never actualy saw any specific answers. > >
