Home > datacenter, memcached, MySQL > Death of MySQL read replication highly exaggerated

Death of MySQL read replication highly exaggerated

April 16, 2008

I know I’m a little late to the discussion, but Brian Aker posted a thought-provoking piece on the imminent death of MySQL replication to scale reads.  His premise is that memcached is so cool and scales so much better, that read replication scaling is going to become a think of the past.  Other MySQL community people, like Arjen and Farhan, chimed in too.

Now, I love memcached.  We use it as a vital layer in our datacenters, and we couldn’t live without it.  But it’s not a total solution to all reads, so at least for our use case, it’s not going to kill our replica slaves that we use to scale reads.  

Why?  Because we still need to do index lookups to get the keys that we can extract from memcached.  And we have to do lots of those indexed queries.  Most of the row data lives inside of memcached, so this turns out to be a great solution, but we still need read slaves to provide the lists of keys.  Bottom line is that we still use read replication heavily – but we use it for different things that we did in years past.

And then, of course, there’s the issue of memcached failure.  For us, it’s very rare, and thanks to the way memcached works, it rarely hampers system performance, but when a node fails and needs to be re-filled, we have to go back to disk to get it.  And doing that efficiently means read slaves again.

For us, memcached plus MySQL replication is true magic.  Brian’s a very smart guy, and I realize he wrote the post to get people thinking and talking about the issue, but at least for us, read slaves are here to stay. :)

  1. April 16, 2008 at 5:22 pm | #1

    Sounds like you’re using a two-fetch method – use MySQL for sorting, limiting, whatever else to get a list of IDs, then do read-through caching for the bulk of the row data using memcached and fill in the missing from the DB. Is that correct? That’s been my strategy so far too, nice to know if other people have adopted it successfully :)

  2. April 25, 2008 at 11:45 pm | #2

    At Newzbin, we operate the other way around; we have our own custom C daemon doing sorting, limiting, filtering etc, and giving us a list of ID’s to go ask MySQL for. We could squeeze memcached in there too, but I don’t think it’s going to be much of a win; primary key lookups aren’t exactly tough :)

    We use the same framework for stream processing, so we can do alerts for users when a search matches something new (or starts matching something old that’s changed that they’ve not seen before).

    My main concern with replication, aside from it being awkward making sure you’re talking to a current enough slave (we use a serialized counter to checkpoint critical db changes), is any long write queries on the master get serialized on slaves; have a 50s long “DELETE FROM BigTable WHERE created_at < really_old”? Well, now all your slaves are gonna sit doing that and nothing else for a minute or more, so you either give users stale data or hammer your master.

    I guess we need some sort of service which replicates queries like this async. Hurray, more infrastructure ;)

  3. November 6, 2009 at 4:01 pm | #3

    Love it! You got me so excited to get one and start shooting video!

  4. asdfasd
    January 10, 2010 at 6:39 am | #4

    This all-in-one Blu ray Video Converter helps you rip movies from Blu-ray disc and convert Blu-ray M2TS video to HD videos like HD AVI, HD DivX/Xvid, HD MP4, MOV, HD WMV, and general videos like AVI, WMV, MPEG, MP4, MOV, ASF, FLV, MKV, SWF and other formats with high quality. This Blu-ray Video Converter also helps extract audio from Blu-ray movies and convert to MP3, WMA, AAC, M4A and other files.

Comments are closed.
Follow

Get every new post delivered to your Inbox.

Join 33 other followers

%d bloggers like this: