Is Read Replication Really Dying in Favor of Memcached?

I spent my Sunday working on my three presentations that I will be presenting at the upcoming MySQL Conference. About two hours ago, as I was reviewing my stuff, I told my lovely wife that I may talk in my sessions how replication for read scalability no longer makes sense in high traffic environments. I told her, I am probably going to vote in favor of investing in memcached vs read slaves for scaling reads.

Believe it, or not, she hammered me with all sorts of questions. I spent some time answering her questions. I scanned my brain to gather more evidence to support myself including that at work we are moving and staying away from replication as much as possible.

Then, I got busy writing the post about Facebook using MySQL replication to update Memcached. After publishing the post, I checked Planet MySQL and found Arjen discussing (and agreeing with) Brian Aker's post about "The Death of Read Replication."

At that point, I simply turned my MacBook screen towards my wife and smiled :)

I consider Brian's post a brave one from MySQL point of view as I can imagine not everyone at Sun/MySQL will be happy about this. I appreciate his can

However, what Brian says about replication, caching and memcached is very true. memcached is an incredibly important part of our infrastructure. It doesn't has painful latency of MySQL replication associated with it. It requires much less hassle to setup, reset and scale. Like Facebook and all other major Web 2.0 sites, we have a considerably large memcached farm that allows us to serve our ever increasing demand.

P.S. Just to be clear, I highly favor using master-master replication for high availability and a small number of slaves. I just don't favor investing money in slaves alone for scaling reads.

P.P.S. I will leave you with a quote from Arjen's post:
"What needs to be fixed is distributed writes. And economically!"