Replication ?

[Nathan Nobbe]

Hi all,

I know I'll get blasted for not googling enough, but I have a quick question.

I was under the impression memcached servers replicated data, such that if i have 2 servers and one machine goes down the data would all still be available on the other machine.  this with the understanding that some data may not yet have been replicated as replication isn't instantaneous.

Can you clarify for me?

thx,

-nathan

[Roberto Spadim]

use repcache

2011/3/3 Nathan Nobbe <quicks...@gmail.com>:

--
Roberto Spadim
Spadim Technology / SPAEmpresarial

[Roberto Spadim]

more here:
http://repcached.lab.klab.org/

2011/3/3 Roberto Spadim <rob...@spadim.com.br>:

[Nathan Nobbe]

On Thu, Mar 3, 2011 at 2:44 PM, Roberto Spadim <rob...@spadim.com.br> wrote:

more here:
http://repcached.lab.klab.org/

This was the first thing that came up on google, just wanted to verify memcached doesn't replicate out-of-the-box.

thx,

-nathan 

[Roberto Spadim]

humm i will tell my experience....
there´s two ideas
one replication (like raid1)
other load balance (like raid0 stripe)

client side can load balance like 'raid0' (i don´t know if libmemcache
have this, in php i use it, and works well)
repcache works like 'raid1' (for cluster and HA i´m using it without
problems, and it´s very good!)
memcachedb have non volatile tools (use harddisk/ssd 'cache' with a berkley db)
there´s another memcache port but i don´t remember now, with more
features (web administration and others tools)

maybe in future we could put all in one package? i don´t know...

2011/3/3 Nathan Nobbe <quicks...@gmail.com>:

--

[Nathan Nobbe]

On Thu, Mar 3, 2011 at 3:02 PM, Roberto Spadim <rob...@spadim.com.br> wrote:

humm i will tell my experience....
there´s two ideas
one replication (like raid1)
other load balance (like raid0 stripe)

client side can load balance like 'raid0' (i don´t know if libmemcache
have this, in php i use it, and works well)
repcache works like 'raid1' (for cluster and HA i´m using it without
problems, and it´s very good!)
memcachedb have non volatile tools (use harddisk/ssd 'cache' with a berkley db)
there´s another memcache port but i don´t remember now, with more
features (web administration and others tools)

maybe in future we could put all in one package? i don´t know...

A friend has mentioned membase:

http://www.membase.org/

though I've hardly had a minute to investigate, it implements the memcache protocol, but it sounds like it may use something other than libmemcache on the backend.

-nathan 

[Matt Ingenthron]

Hi Nathan,

On 3/3/11 1:42 PM, Nathan Nobbe wrote:
> Hi all,
>
> I know I'll get blasted for not googling enough, but I have a quick
> question.

Here's a dime. Get yourself a web browser and bring me back $0.10
change. :) (said jokingly...)

>
> I was under the impression memcached servers replicated data, such
> that if i have 2 servers and one machine goes down the data would all
> still be available on the other machine. this with the understanding
> that some data may not yet have been replicated as replication isn't
> instantaneous.
>

There are a few memcached related things that do replication, but the
core memcached server itself does not replicate.

One is something related (forked?) from memcached called repcache. It
does it on the server side as clustered pairs.

One is something called Membase, which uses the memcached core (kinda
forked, aiming to put back), which has special hashing called vbucket
hashing. This can be transparent to the client though.

One is that libmemcached does replication from the client, but has
admittedly lots of interesting potential consistency issues depending on
what fails when and how much it actually fails.

I'll let you go further with that browser you just downloaded. :)

Matt

p.s.: full disclosure: I'm pretty heavily involved in Membase

[Roberto Spadim]

yeah that´s the other i forgot! :) membase
it works nice, but memcache / repcache and memcachedb can work like it

2011/3/3 Nathan Nobbe <quicks...@gmail.com>:

--

[Matt Ingenthron]

On 3/3/11 2:13 PM, Nathan Nobbe wrote:
> A friend has mentioned membase:
>
> http://www.membase.org/
>
> though I've hardly had a minute to investigate, it implements the
> memcache protocol, but it sounds like it may use something other than
> libmemcache on the backend.

It's a bit off topic for this list and should be discussed further over
there, but to avoid the kinds of consistency challenges and topology
change problems associated with repcached/libmemcached replication,
Membase took a very different approach with vbuckets and vbucket
hashing. Your browser will find you more. :)

Clients don't have to be aware of this, as moxi can abstract away the
details if the client doesn't know vbucket hashing.

FWIW, Trond Norbye who I think did the libmemcached replication work is
also a Membase guy.

Regards,

Matt

[Roberto Spadim]

humm membase = memcache+repcache+memcachedb

http://wiki.membase.org/display/membase/Membase+for+Memcached+Users

nice =)

2011/3/3 Matt Ingenthron <inge...@cep.net>:

--

[dormando]

I sound like a broken record about this, but I like restating things
nobody cares about;

- memcached doesn't do replication by default
- because not replicating your cache gives you 2x cache space
- and when you have 10 memcached servers and one fails...
- ... you get some 10% miss rate.
- and may cache 2x more crap in the meantime.

if your workload really requires cache data never disappear, you're
looking more for a database (mysql, NoSQL, or otherwise).

the original point (and something I still see as a feature) is the ability
to elastically add/remove cache space in front of things which don't scale
as well or take too much time to process.

For everything else there's
mastercard^Wredis^Wmembase^Wcassandra^Wsomeotherproduct

-Dormando

[moses wejuli]

...or better still, when one of your cache servers go down, you hit the databse (or other cache servers) till the broken one is fixed !!!

[Nathan Nobbe]

On Thu, Mar 3, 2011 at 6:42 PM, dormando <dorm...@rydia.net> wrote:

> Hi all,
> I know I'll get blasted for not googling enough, but I have a quick question.
>
> I was under the impression memcached servers replicated data, such that if i have 2 servers and one machine goes down the data would all still be
> available on the other machine.  this with the understanding that some data may not yet have been replicated as replication isn't instantaneous.
>
> Can you clarify for me?
>
> thx,
>
> -nathan

I sound like a broken record about this, but I like restating things
nobody cares about;

- memcached doesn't do replication by default
- because not replicating your cache gives you 2x cache space
- and when you have 10 memcached servers and one fails...
- ... you get some 10% miss rate.
- and may cache 2x more crap in the meantime.

if your workload really requires cache data never disappear, you're
looking more for a database (mysql, NoSQL, or otherwise).

hmm, i hear you here and am starting to wonder about the application of memcached which drove me to this question, namely php session storage.

it's often discussed on the php-general list the pros and cons of memcached in said application and i know many sites move to memcached to increase performance over a db backend.  however there is the issue of loosing the session if a memcached box goes down.  perhaps memcached isn't the most appropriate place for session storage as its not considered data that should be allowed to disappear.

i know its OT, but .. thoughts? :)

-nathan 

[Roberto Spadim]

hum...

memcached is a cache (developers don´t care about database)
memcachedb is a a database with memcache library protocol
membase is a database with memcache library protocol

if you want database features use membase or memcachedb

2011/3/4 Nathan Nobbe <quicks...@gmail.com>:

--

[Dustin]

On Mar 4, 9:11 am, Nathan Nobbe <quickshif...@gmail.com> wrote:

> i know its OT, but .. thoughts? :)

He captured thoughts about this a while back in a blog post that's
worth a read either way:

http://dormando.livejournal.com/495593.html

[moses wejuli]

guys, the creators of this much loved tool -- viz-a-viz memcache -- designed it with one goal in mind: CACHING!!

using sessions with memcache would only make sense from a CACHING standpoint, i.e. cache the session values in your memcache server and if the caching fails for some reason or another, hit your permanent storage system: RDBMS or No-SQL... obvioulsy, your caching server specs (and supporting environment like interconnect fabrics, Mbps download capacity, server durability, etc..) should reflect your user load + dat importance for efficiency, among other factors.. i generally use Memcache  (+ PHP) out of the box with this in mind and never found any earth-moving issues... For sessions particularly, i never found any issues.

I think it's vitally important to keep in mind what Memcache is for ... a CACHING TOOL.. and not a permanent storage system (also it's a Friday evening here in England so please excuse the language.. and any typos ;) )

Moses.

[dormando]

> guys, the creators of this much loved tool -- viz-a-viz memcache -- designed it with one goal in mind: CACHING!!
>
> using sessions with memcache would only make sense from a CACHING standpoint, i.e. cache the session values in your memcache server and if the
> caching fails for some reason or another, hit your permanent storage system: RDBMS or No-SQL... obvioulsy, your caching server specs (and supporting
> environment like interconnect fabrics, Mbps download capacity, server durability, etc..) should reflect your user load + dat importance for
> efficiency, among other factors.. i generally use Memcache� (+ PHP) out of the box with this in mind and never found any earth-moving issues... For
> sessions particularly, i never found any issues.
>
> I think it's vitally important to keep in mind what Memcache is for ... a CACHING TOOL.. and not a permanent storage system (also it's a Friday
> evening here in England so please excuse the language.. and any typos ;) )
>
> Moses.

As I pointed out in that blog post, it's also handy for achieving write
amplifications of less than 1.0 for more lossy data.

soooooooooooooooooooooooooooooooooooooo. it's more about matching the tool
vs your actual needs. most of the problem here has always been separating
perceieved requirements from actual requirements.

[Adam Lee]

On Mar 4, 2011 10:38 PM, "dormando" <dorm...@rydia.net> wrote:
> soooooooooooooooooooooooooooooooooooooo. it's more about matching the tool
> vs your actual needs. most of the problem here has always been separating
> perceieved requirements from actual requirements.

yeah, that's an incredibly important distinction.  i talk to a lot of people who seem to think that their data is so important, they can't possibly tolerate even a brief inconsistency. or that just because memcached *could* lose data means that it will. the truth is, we've been running a large (over 500GB on, at one point, up to 50 servers) installation and we've had very little data loss. generally, the only times a server went down were when we intentionally brought it down or the very rare hardware failure.

obviously, it's not a persistent datastore and you need to keep your permanent data somewhere, but for anything ephemeral or that can be easily queried or recomputed, memcached is an excellent and fairly reliable choice.

in fact, i would bet there are a lot of situations where a fairly high-traffic site chooses to store something like session in a slower but more "reliable" datastore because they "can't afford to lose the data," but end up with a lower QOS because the datastore can't keep up with the load and ends up with failled reads and/or writes.

awl

[eCern Admin]

Is anybody using any of the these technologies to handle user registration and authentication?

OK, there's oAUth but not all of our clients are happy with it.

I would like to hear ideas about replication solutions that are robust enough to ensure adequate response times and 100% availability for very heavy user registration and authentication of existing users.

Theory is OK but hearing about what you are actually doing would be better.

[Prachi Tripathi]

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you