A few questions

Hi there!

For your first question, it is actually the client library that takes care of the sharding, not the server. If you supply the client with a list of 3 IP addresses, it will run every request through a hashing algorithm that decides where the key will lie. i.e. if you have serverA, serverB, and serverC in the configuration, when you make a request for key1 the client library will put that key on one of the three servers. key2 may go to another server. When that client (or another one) asks for the same key, the same hashing algorithm is applied to the same list of servers and you end up in the same place. Make sense? The memcached.org faq ([url]http://code.google.com/p/memcached/wiki/FAQ[/url]) has information about this and more.

As far as handling failures go, this becomes a bit more client-library dependent. There are also configuration parameters that can affect how your clients behave when there is a failure. Most clients under default configurations will automatically stop using a memcache server if it is detected as unavailable (either immediately, or after some fixed number of retries). This will lead to some rehashing of keys, but in general, operation will continue without causing your page loads to timeout (assuming you can relatively quickly repopulate the lost data). The nuances really come into play not for failover, but for failback. Some people don't want memcache servers automatically failed back into the pool since you can get into a flapping scenario that can prolong any issues. Others do want auto-failback for the ease of management.

Another option entirely is to use the proxy port (11212 instead of 11211). Although a bit slower, this will allow you to better handle hashing of keys and failures of servers. By going through the proxy port, you are relying upon the server to handle the hashing for you and so making any request for any key from any server will return the right result. In this case, you don't have to supply your clients with all the IP's, and if a server fails, the rest of the data is still available regardless of how your client side hashing may change.

Thanks for the answers Perry, I think the proxy port is what I must have been thinking of, so does using that solve the problem of failback as well? Failback will definitely be the main issue for our app, as if outdated data is suddenly re-introduced into the cache it will cause errors on the client.

How large is the performance hit from using the proxy port? I'm guessing it will more or less double the response time as it's effectively performing another memcache get on the server? That is entirely acceptable for the benefits it provides though.

Thanks again for the help, I might be back soon with some questions about membase - just found your site at the weekend and I'm very excited about using your products!

Yes, using the proxy port will handle failback better since you will always have only one location for a given piece of data (even if that changes by adding/removing servers).

The performance hit is dependent upon the traffic load and object sizes...definitely worth profiling within our own environment.

Glad I could help, let me know if you have any other questions.

Perry