Libmemcached 1.0.16 SET does not replicate

[m6w6]

• Reported as: lp:1204148
• Reported by: lp:~90724-x
• Reported at: 2013-07-23T15:44:32Z

Imported from Launchpad using lp2gh.

---

Hi,
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 storage.cc 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

Regards,
cube45

[m6w6]

• Comment by: lp:~thegeorg:
• Created at: 2013-08-01T11:50:58Z

---

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.

[m6w6]

• Comment by: lp:~90724-x:
• Created at: 2013-08-01T12:15:00Z

---

Where did you find this information on the doc?

Here is what i've read from the doc:

MEMCACHED_BEHAVIOR_NUMBER_OF_REPLICAS
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

[m6w6]

• Comment by: lp:~mrbig:
• Created at: 2017-04-21T10:26:54Z

---

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?)

[m6w6]

A few things to note here:

• right, this replication is only available in binary protocol mode
• right, it only replicates SET (not ADD)
• it should, though, replicate DELETE requests (at least according to source and tests)

Those facts should be documented, if they ain't already.

• but, if the SET on the primary fails, it won't be replicated to the "replicas" (for obvious reasons)
• unfortunately, there's another but: if the DELETE on the primary fails, it will still be replicated to the "replicas" (because ... reasons?)

The term HA in docs is misleading, I think.