> On Mon, Oct 19, 2009 at 03:34, dormando <dorma...@rydia.net> wrote: > > http://blogs.sun.com/trond/date/20090625 > ^ client side replication. > > I like this and feel it's more powerful, since tt scales past two severs > implicitly, and you can enable/disable it per key or key type. So instead > of halving your effective cache, you can make a decision that some bulk of > data is easier to recache than others. > > > Ah ok, I see. It's an improvement over failover with consistent hashing, > because when you fail over, your data already exists on the failover server, > on a per-key basis, at the cost of storing the item > multiple times, every time. Hm, that would work extremely well together with > parallel requests, which is also something I'd like to add to my client. And > as Trond writes, he uses it for the binary > protocol only so he can do quiet sets that work properly. > > I'm still partially against failover because of the synchronization issues > with automatic recovery from failover, but adding replication really only > affects automatic failover and makes that case > slightly nicer, so it's definitely something to consider if I start adding > failover support. I'll add it to my todo-list in any case, there's a bunch of > stuff I'd like to implement if I could find the > time and the urge to do it. :-)
Heh... There're a few use cases that get me. One is new users who're bolting memcached on to deal with horrific backend responsetime/etc. If they're not too huge they can reduce cache efficiency by half and not bankrupt themselves. Then over time remove keys from the replicated scenario. For larger folks it'd hopefully be used sparingly. -Dormando
