No, my client explicitly doesn't do failover. However, it still uses the ketama method, because of its benefits when you change your memcached cluster configuration. If a server goes down, you can remove it from your configuration and restart your entire app, without having to touch your remaining memcached servers, and they'll still contain most of your cached data mapped correctly. The difference is that this is a manual, controlled operation, as opposed to automatic recovery from failover, which means that you're probably better equipped to handle any cache synchronization issues. So it's still useful to implement the ketama method even though you don't have automatic failover.
It was also more fun to implement. /Henrik On Tue, Jun 23, 2009 at 15:54, Pau Freixes <[email protected]> wrote: > Hi > > On Tue, Jun 23, 2009 at 3:44 PM, Henrik Schröder <[email protected]>wrote: > >> Exactly, which is why the solution to avoiding cache synchronization >> errors is to simply not implement failover. In my client, I use the ketama >> method for server selection, but if a server fails, I just mark it as dead, >> and keep retrying it with a growing interval. As long as it's dead, all >> requests that would end up on that server simply misses. >> > > Then your implementation doesn't remapping points to close server ? But > that is the best of ketama implementation !, remapping only a keys affected. > If this is true you can use a more easy client side hash approximation > avoiding failover scheme ;) > > > -- > --pau >
