Handling failovers (rewrite)

[Dustin Sallings]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20070703/8a84115c/attachment.htm