Handling failovers (rewrite)

[Ben Manes]

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.

----- 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:21:31 PM
Subject: Re: Handling failovers (rewrite)



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

This is obviously a small edge case and it would be difficult for the client to know that it needs to expire the value in bucket_2.  More than likely the stale data is benign, but I believe the scenario is valid.



	I've been thinking about this for a little while.  I don't know how valuable it is.  I've been thinking about adding a mode in my client that would do this.



	Basically, it'd be easy to broadcast invalidation messages for all servers in a cluster before issuing a mutation command.  Especially so when using UDP.



	This would drive up the load on the server, and give the client more work to do as well, so it'd be most important where you keep items for a long time and don't trust your memcached servers to run for very long.


 -- 
Dustin Sallings

 







      ____________________________________________________________________________________
Fussy? Opinionated? Impossible to please? Perfect.  Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20070703/d37871fc/attachment-0001.html