Thanks for the response, Chad! As far as moxi proxy, would you recommend a front-facing stand-alone moxi proxy sitting in front of the cluster, or would a round robin DNS rotation with all of the nodes' with their built-in moxi instances suffice?
I'm not clear on what would be the best/safest for a memcache-only cluster. Any advice would be appreciated! On Wed, Dec 25, 2013 at 10:44 AM, Chad Kouse <[email protected]> wrote: > Memcache style buckets don't participate in replication so all keys and > values exist on a per node basis. In other words if you have 4 nodes and > one goes down you have lost 25% of your cache. > > To know which nodes contains the keys /values you want on a per-request > basis you need to use a consistent key hash algorithm. The preferred method > here is to use moxi as your proxy to the cluster (which I believe just uses > a libketama style hashing algorithm) - this maps a key to a particular > node. > --chad > > > On Wed, Dec 25, 2013 at 2:23 AM, Gregory Taylor <[email protected]>wrote: > >> I'm thinking about setting up a hosted memcache service using Couchbase, >> and am evaluating pain points and looking to get some answers. While I've >> read through a good chunk of the documentation, a lot of it seems focused >> on the regular Couchbase buckets. I had a few questions about the memcache >> bucket types in particular: >> >> - I saw mention that memcache buckets (and their keys) always live on >> a single node, unlike couchbase buckets. Is this true? >> - For the couchbase buckets, I see "strong consistency" is offered, >> though I'm not sure if this applies to memcache buckets (and to what >> extent). If my users are connecting via SASL+binary memcache protocol, is >> there ever a case where an immediate SET/GET of the same key will result >> in >> out-of-date values being returned by GET? >> - Do I need to point each user at a specific node in the cluster? >> Perhaps the one that their bucket resides on? I ask this because of the >> statement I saw about memcache buckets living on single nodes, though I am >> not sure this was correct or reflects the current state of things. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Couchbase" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Couchbase" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/couchbase/m-AznwLDGfg/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- Greg Taylor (864) 888-7964 http://gc-taylor.com -- You received this message because you are subscribed to the Google Groups "Couchbase" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
