Distributed session store with planned failover ...

[James Robinson]

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 ].

----
James Robinson
Socialserve.com