> A split read/write scheme will affect reliability if one of the write servers
> happends to be down... As I'm understanding it, Mysql's replication would
> survive this scenario. What I'd be getting is the ability to do local
> reads/writes and Mysql would simply propogate my writes. For the most part,
> data latency won't be a big deal for my applications unless we're talking
> HOURS. (and we're not, unless something is BAD wrong.)
The main pain point with circular replication is that MySQL has
absolutely no conflict resolution. You'll probably run into duplicate
key errors at some point, or just silent data divergence - if you're
not checking your servers consistency (using maatkit or some other
tool) you may not even notice. Circular replication is almost always
a bad idea and you'll see this being discouraged in remotely recent
> My research has turned up a package called Mysql Multi Master Manager(?),mmmm.
> My initial reading indicates that this tool won't work across different
> networks, right?
You shouldn't run mysql-mmm across networks for the most part. It
works by moving a floating IP between two mysql-replication masters,
using /sbin/ip and sending gratuitious arp to notify of the IP change
from server to server. I wouldn't try to use it with circular
replication w/ > 2 masters.