> 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 188.8.131.52, 184.108.40.206 and 220.127.116.11. 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.
Baskin School of Engineering
UC Santa Cruz