Distributed session store with planned failover ...
jlrobins at socialserve.com
Thu Jun 29 17:03:35 UTC 2006
On Jun 29, 2006, at 12:47 PM, David Ulevitch wrote:
> This is how it works.... or do I no get what you wrote? -david
Nope. Currently, if I take the python client to be representative of
the 'average' client, the key is hashed to a _single_ server out of
the currently available pool known working to the client. So, when a
server takes a hit, all of the keys that would have hashed to it now
hash to one of the others, which [ initially ] won't have that data
stored, causing a flood of cache misses and deep DB reads.
The proposal changes things to have a client hash to an ordered pair
of servers, writethrough to both, and read from the first then
possibly the second. If it had to read from the second server, then
it is the responsibility of the client to writeback to the first
[ preferred ] server.
So, in normal mode on a memcache read-mostly site, little to no
additional work. You could then take a hit, either planned or
unplanned, on any one of the three servers and not suffer the flood
of additional memcache misses and deep DB reads. And when the dead
server gets resurrected, it gets populated slowly over time from the
other memcaches as well as deep DB reads.
End result is a little extra pain on writes, but much smoother
operation in the case of single machine failure [ or reboot to get a
new kernel running ].
More information about the memcached