Handling failovers (rewrite)

[Ben Manes]

Oops, your right.  If you look at how the standard Java client handles it, it maintains a list of active and dead buckets.  When working with one key, you could successfully recover the way I mentioned.  However, with 2+ keys, you would not be able to detect that the change over occurred.

So yes, you'd need to broadcast an invalidation.  If you partition the caches into smaller caches, rather than sharing one big cache, then the client could prefix the name with the cache node.  You can detect the first request where the client makes a migration of the dead bucket back to the active list.  In that case, you can apply a flush() on your bucket_partitioned cache since you know its keys are invalid.  I'll have to think about this a little bit more, after the 4th, when the code is in front of me.  It may be possible to do it intelligently...

----- Original Message ----
From: Dustin Sallings <dustin at spy.net>
To: Ben Manes <ben_manes at yahoo.com>
Cc: memcached at lists.danga.com
Sent: Tuesday, July 3, 2007 11:43:48 PM
Subject: Re: Handling failovers (rewrite)



On Jul 3, 2007, at 23:29 , Ben Manes wrote:

Well, the way I would resolve it is to have the client delete the key associated in bucket_2 before storing the value into bucket_1.  The client is migrating the "dead" bucket back into the "alive" bucket at some point of time.  If the key points to a dead bucket, but that bucket is marked for becoming active again, it should take the extra step of recalculating the newKey_1 and deleting it before inserting key_1 into bucket_1.

This should resolve the issue without broadcasting messages, but requires that it is handled during the bucket lookup phase.



	Without recording every key store on every client for every node that was not the primary node for that key, you just can't do that.  You also can't assume node 2 was up when node 1 was down.  What if a key destined for node 1 went to node 3?



	The only options are to ignore the problem or broadcast invalidation on mutation.



	(I'm saying that in an extreme hoping someone will come up with something new and exciting).


 -- 
Dustin Sallings

 







       
____________________________________________________________________________________Ready for the edge of your seat? 
Check out tonight's top picks on Yahoo! TV. 
http://tv.yahoo.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20070704/7de89077/attachment.html