People probably know about memcached (http://memcached.org/) and its high performance name-value based memory object cache interface. Its main purpose is to provide an easy to use distributed caching engine in a multinode environment. Have you ever wanted to let memcached handle replication?

If you'd like to add high-availability capabilities, you're advised to let the client (-library) handle replication of your data throughout all nodes. Let's say using memcached as storage backend for php sessions is configured as follows:

Now sessions get distributed (not replicated) through both nodes. As soon one node goes down you'll loose all that data. As long you only use memcached as a performance booster and distributor of some "cacheable" data that should not hurt: The lost data gets filled up as they did whilst creating the cache entries.

To replicate your session data you'll need to use a custom session handler that connects to each of these nodes on its own... for replication. Same if you'd like to write some own cached objects to your beloved memcached. Still your application needs to know all nodes to write to.

Ease up replication by letting memcached work it out as repcached

These issues might confuse developers that just want to focus on their application and don't want to care so much about HA, load-balancing and scalability. With repcached at least a 2-node HA-Solution can be setup easily and transparently.

A simple patch adds fancy master-master replication to your memcached. Now you'll only need to connect to your local memcached which than handles replication on its own.

So you're application may remain dump and simple, using your local POSIX filesystem (which might be replicated by DRBD, GlusterFS, etc) your local Database (you guessed it: "which handles replication on its own") and connecting to a lokal instance of your "memcached-cluster". That setup opens up some more simple and transparant options for an easy and lightweight HA-Scalability.

Installation, configuration and testing a 2-node cluster

First grab a copy of the repcached patch or even download the pre-patched memcached-source from http://repcached.lab.klab.org/. There is a dependency on libevent which might need to be resolved prior to installation.

Don't worry too much about a previously installed memcached.dep package. This manual install will just install a binary in /usr/local/bin/memcached letting your "original" memcached untouched in /usr/bin/memcached.

In contrast to the debian package you might like to provide command-line optionsby using a simple default configuration in /etc/default/memcachedrep (rep => 'replication'), ie:

Try that vice-versa and have fun! And finally tear down one of these nodes after you pushed some more values into memory. The running node still keeps responding with _all_ data - excellent.

The real fun part is, that next as soon you start up the unavailable node again it gains all the "lost" data from the other master. Go ahead try on your own. Same will happen if you now tear down the other node and bring it back up again. Even data that was set to one node whilst the other node was down will get added to the upcoming node after startup.

That setup is capable of a 2-node-replication setup only - yet. Think of building a 4-node cluster with a kind of raid10 setup where replication and distribution is combined... or something. Well at least in that 2-node HA-Setup repcached performes like a charm.

Personally I'd like to try a circle of 3 nodes next :) (maybe together with heartbeat to close any lack in that circle).