Libmemcached 1.0.16 SET does not replicate

Bug #1204148 reported by cube45
This bug affects 2 people
Affects Status Importance Assigned to Milestone

Bug Description

I am currently trying to test libmemcached but I am facing a strange behaviour:

Let's say we have two memcached servers (A and B) and a data d.
I want to put this data on the servers so that it will be available.
The key hash seem to designate the node A as the primary and B as the replicate.
If B is down, the data is written only on A.
But if A is not up, d is not automatically written to B and is lost.

Is this what was intended?
I saw some lines on that let me suppose that if the first node does not succeed in saving the data, then it is not saved at all.

I'm using libmemcached 1.0.16 with binary protocol, CAS support and number of replicas to 1


cube45 (90724-x)
description: updated
Revision history for this message
Yuriy Chernyshov (thegeorg) wrote :

Well, according to documentation, replication works only in case of cache misses (e. g. if one of the server was overflown with data and removed some values from the cache).

Server failure isn't the case for the replication to work around.

Revision history for this message
cube45 (90724-x) wrote :

Where did you find this information on the doc?

Here is what i've read from the doc:
If you just want “a poor mans HA”, you may specify the numbers of replicas libmemcached should store of each item (on different servers). This replication does not dedicate certain memcached servers to store the replicas in, but instead it will store the replicas together with all of the other objects (on the ‘n’ next servers specified in your server list).

This is the behaviour that I get if everything is fine:
The value is stored on A,A+1... according to the key hash and NUMBER_OF_REPLICAS set

However, when I tried to read a value stored in A and A+1 and if A is down, the value is correctly retrieved from A+1

Revision history for this message
Nagy Attila (mrbig) wrote :

This is an old ticket, but somewhat still actual for version v1.0.18

Here's my finding, but I'm might mistaken:

 - replicas do work only with BINARY protocol.
 - replicas are built only with the SET operation. ADD operation does not replicate for obvious reasons
 - DELETE is not replicated (hmm is this a bug?)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.