> Do you want geographic redundancy or do you want to scale reads? > In this case you're talking about scaling reads for a bunch of > apps all running together. If you want performance in that case, > then first you'd want to isolate the apps from each other.
Geographic redundancy is my primary goal. Geographic redundancy also by its very nature helps boost performance of reads because you have more than one server from which to read. Each web site hosted on this group of servers has an "A" record that points to all three servers - so, foo.com has A records for 1.2.3.4, 2.3.4.5 and 3.4.5.6. Using round-robin DNS, the connections for clients are distributed across all three geographically redundant servers using poor-man's load balancing. > Geographical redundancy is different: a dns record with a zero > ttl, with a master->slave replication setup. Point the record a > the master and if it fails, change the dns entry to point to the > slave. Your applications never need to know about replication. Except I'm not just making my database geographically redundant, but my web server and applications as well. Each server runs mySQL, Apache and PHP. PHP connects to "localhost" on each server. Using your method (which by the way requires human intervention to activate), only the mySQL would be redundant. And your solution does not balance reads across all mySQL servers. > That's the great thing about open source software and > techniques. They're like building blocks, and you can put them > together however you want. I find this much more preferable to > the all-in-one black-box solution. You find it preferable to handle your database redundancy with something other than your database server? Any mySQL is black-box? I was pretty sure mySQL was open source. Anyhow, you have actually proven my point: mySQL has already provided the building blocks of master/slave replication. Now I'd like to see an addition to that protocol (upstream updates) and bam, we've got a whole new replication methodology that fills the needs of a set of people whose needs were not met by multi-master replication or mySQL cluster. At any rate, this part of the discussion is getting very off-topic. My original suggestion pertained to a new way of doing replication that I'd like to see in mySQL. If you don't like my idea, don't use the feature if and when it ever comes into being. Tim Gustafson Baskin School of Engineering UC Santa Cruz t...@soe.ucsc.edu 831-459-5354 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
