Handling failovers (rewrite)

[Dustin Sallings]

  I tend to only look at the source to my own java client.  :)

  It doesn't matter how many keys you have.  If you have more than one node, you don't know who's put what where.

  There is no partial flush operation.  A full flush would be bad and a quiescent cluster would be a collossal waste.

  The closest you could get to a partial flush would be to generate a key prefix that you use consistently for "foreign" keys and then have that key change upon every connect of the owner client.

  Effectively, in your up-down-up-down scenario for a given key, the actual storage key would be different on the second lookup.

  The identifier would need to be consistent across all clients, so you'd need to store it in memcached as well.

  It's only a matter of assigning value to such a scenario.  I'm guessing it doesn't cause a lot of issues in many deployed apps.  Perhaps those with larger clusters could point out whether there's value in such a thing.

-- 
Dustin mobile.

-----Original Message-----
From: Ben Manes <ben_manes at yahoo.com>

Date: Wed, 4 Jul 2007 00:45:42 
To:Dustin Sallings <dustin at spy.net>
Cc:memcached at lists.danga.com
Subject: Re: Handling failovers (rewrite)


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:


	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