Memcached/repcached: the need for repcached

[PenguinWhispererThe]

Hi all,

I wonder what the added value for repcached is(http://repcached.lab.klab.org/).
It replicates the objects to both configured nodes. So you can read the cached value on all nodes even if it was added through the memcached on the other node.

In the normal memcached there is a constant hash algorithm so you will hit the correct server when reading a previously set value.
When this server goes down I assume you just "cache-miss" and get your data directly from the database and then cache it on another memcached node?

I would assume repcache would give some kind of HA however I don't see how this can't be accomplished by the normal memcached.
Ok, you loose cache but it will be cached on another node again. In that way it actually seems like repcached adds overhead.

Another thought I had is that if one very frequently executed query gets a hash that is on for example memcache server X that all subsequent clients that need the same data will also be sent to server X. So more load will go to that server.
Am I thinking right here? Is that the purpose of repcached? Maybe a workaround could be to just create a few hashes with the same data so you can be sure that those will approximately be balanced over the different memcached servers?

Note that I never used memcached/repcached but I'm trying to understand if we actually need this in our organisation. There seems to be an issue with a segmentation fault and I want to make sure I don't spend a lot of time while there might be a better solution. Repcached isn't maintained anymore either. So maybe it's better to look at a long term solution.

Thanks in advance!

[Roberto Spadim]

i think repcached is used with DRBD solutions

two servers, if one server get down the other 'hot server' take the 'cluster' ip address and start services without recreating the cache, with a low startup time between fail and hot server start

--

---
You received this message because you are subscribed to the Google Groups "memcached" group.
To unsubscribe from this group and stop receiving emails from it, send an email to memcached+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Roberto Spadim

[Les Mikesell]

On Tue, Aug 5, 2014 at 10:45 AM, PenguinWhispererThe
<th3pengui...@gmail.com> wrote:
> Hi all,
>
> I wonder what the added value for repcached
> is(http://repcached.lab.klab.org/).
> It replicates the objects to both configured nodes. So you can read the
> cached value on all nodes even if it was added through the memcached on the
> other node.
>
> In the normal memcached there is a constant hash algorithm so you will hit
> the correct server when reading a previously set value.
> When this server goes down I assume you just "cache-miss" and get your data
> directly from the database and then cache it on another memcached node?

Yes, that is the normal memcache approach, and depending on your hash
choice you can either 'just fail' for a portion of the hash range
until the node is back or rebalance across the remaining nodes. As
long as you have a reasonable large number of nodes and a reasonably
fast database you can tolerate having some nodes down some of the
time.

> I would assume repcache would give some kind of HA however I don't see how
> this can't be accomplished by the normal memcached.
> Ok, you loose cache but it will be cached on another node again. In that way
> it actually seems like repcached adds overhead.

It isn't necessary in the general case - which is probably why it is a
separate project. It might help if you have a small number of nodes or
a database that can't handle a flurry of cache misses.

--
Les Mikesell
lesmi...@gmail.com

[Hirotaka Yamamoto]

Hi,

memcached can be used for various purposes other than caching.

For instance, we store session data in our memcached clone ( https://github.com/cybozu/yrmcds ).

Thanks to its high performance, a single server can serve all (> 10 millions) sessions.

However, if the server crashes, all customers will be forced to sign-out.

Replication protects us from such disaster.

--

ymmt2005

[PenguinWhispererThe]

Not sure if that's the case. If it's repcached then you can read and write values to both nodes. So you have active-active.
DRBD is a shared block device. However repcached/memcached is in memory so not sure what those 2 have to do with each other.

Op dinsdag 5 augustus 2014 18:22:19 UTC+2 schreef rspadim:

[PenguinWhispererThe]

I understand that in most cases you don't need this. However to me it doesn't look like a seperate project (as it's bound to memcached, and can't be used "standalone"). Actually more like an enhancement/feature. In that case distros would distribute the binarie packages without this capability built-in. But for someone who wants to use it he could just configure it through make and compile. Probably somebody at memcached kept this feature out for some (probably good) reason.

Op dinsdag 5 augustus 2014 20:06:16 UTC+2 schreef LesMikesell:

[PenguinWhispererThe]

I found out we use it as some sort of temporary storage. So not actually as a layer in between. If one of the memcached nodes goes down we would loose this information (mostly only needed for a few minutes) and for compliancy we can't write this data to disk.

Op woensdag 6 augustus 2014 08:13:40 UTC+2 schreef Hirotaka Yamamoto: