Transparent failover and restore?

Timo Ewalds timo at tzc.com
Sat Dec 18 23:31:14 PST 2004


Brad Fitzpatrick wrote:

>On Sat, 18 Dec 2004, Jon Valvatne wrote:
>
>  
>
>>I think the point is this: If you're using memcached in a way that means
>>losing a server will bring down the system, then you should probably be
>>looking at using the MySQL "redundant storage thing" instead of the
>>memcached "cache thing". Traditional usage of a cache usually means
>>losing parts or all of it is *not* fatal.
>>    
>>
>
>Exactly.
>
>Or do what LiveJournal does:  have a dozen memcached machines, each with
>about the same amount of cache.  So if you lose a machine, you only lose
>1/12th of the cache, until it re-hashes and populates over the next 10
>minutes.
>
>I suppose I see the arguments from the people who only have 2 machines
>and want good cache hit rate performance in the face of failure, but the
>cache coherency problems just seem too hard to re-implement when solutions
>already exist.
>
>Perhaps memcached atop NDB cluster (what MySQL Cluster is built on)
>would be interesting.  NDB would do the cache coherency across the
>cluster, and memcached could simply do the protocol handling and LRU
>maintenance and cache discarding...
>
>- Brad
>
>
>  
>

If cache speed isn't all that much of an issue, why not just run the 
cache off mysql cluster. Create a table of the form: key, expiry, flags, 
data (or whatever), primary on key, and cluster it across however many 
machines you want. You then keep your main database on normal mysql 
servers so size isn't an issue. It is still in ram and everything is off 
the primary key with no joins, so lookups shouldn't be all that slow 
either (though certainly slower than memcached). I guess you could even 
build it into the memcached api to automatically put add/set/remove to 
the mysql cache, and check there if you get a cache miss in memcached or 
you detect a server down. Depending on your usage, you could probably 
even get away with doing that on a normal mysql server instead of the 
cluster. I certainly had one table specific for caching before I found 
memcached, and it worked great, though it was a bit slower, especially 
if you didn't combine cache hits (ie SELECT ... WHERE key IN 
('key1','key2') ).

Timo


More information about the memcached mailing list