Handling failovers (rewrite)

[a.]

Isn't it true that a memcached server more likely "goes down"  
becaouse its machine has been restarted, or the process crashed?

So usually you'll end up with an empty server which does not have  
stale data.


a.



On Jul 4, 2007, at 8:43 AM, Dustin Sallings wrote:

>
> 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/20070704/8ede71b1/attachment-0001.htm