Redis cluster supporting synchronous replication to slave(s) ?

[fj]

Hi all,

Reading the cluster-tutorial (http://redis.io/topics/cluster-tutorial) it mentions: 

“Note: Redis Cluster in the future will allow users to perform synchronous writes when absolutely needed.”

Can anyone one tell me if this is still future plans or if this has actually been implemented by now?
If not, is this in the near pipeline and expected available before release of production redis-cluster?

I'm interested in replicating writes to at least one other node in the cluster and having the remote write acknowledged before the client is acknowledged.

Best regards,

Flemming

[Salvatore Sanfilippo]

Hello Flemming,

Redis Cluster supports synchronous replication using the WAIT command,
documented here: http://antirez.com/news/66 (sorry official man page
still missing).

While WAIT is a fine implementation of synchronous replication, it
does not change the fact that Redis Cluster is not strongly
consistent, even when you consider writes to be executed only when
WAIT returns success.

So basically:

1) WAIT make sure the write is replicated to N nodes.
2) Because of this, it is less likely that Redis Cluster will elect a
slave missing writes.
3) However Redis Cluster only runs an "informal" protocol between
slaves to pick the best candidate, it does not guarantee anything, so
the system is not linearizable.
4) Also WAIT is a form of synchronous replication, so you can't expect
Redis-alike latency using it (but you can expect high ops/sec if you
have high concurrency).

I hope this helps,
Salvatore

> --
> You received this message because you are subscribed to the Google Groups
> "Redis DB" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to redis-db+u...@googlegroups.com.
> To post to this group, send email to redi...@googlegroups.com.
> Visit this group at http://groups.google.com/group/redis-db.
> For more options, visit https://groups.google.com/d/optout.



--
Salvatore 'antirez' Sanfilippo
open source developer - GoPivotal
http://invece.org

"One would never undertake such a thing if one were not driven on by
some demon whom one can neither resist nor understand."
— George Orwell

[fj]

Hello Salvatore,

Thanks a lot for responding.
This is indeed an exciting addition to Redis.
I like the fact that the client can decide per type of transaction (e.g. critical/non-critical) if you want to have the extra safety (and latency) as opposed to configuring the master to always wait for x replica responses before sending the ack to the client.

My initial thoughts was to run with just a single replica for each master instance, but I'm guessing this is not enough if I want to use the WAIT command.
I guess I will need at least 2 replicas per master instance.

Otherwise what will happen in the situation where I have master and one replica in case the master goes down and the slave is promoted to be new master.
Until the dead master comes back up again there is no replica at all and WAIT will always return 0 I guess?

If I have 2 replicas per master and do WAIT 1, I can afford one of the replicas to be down.

Is this correct?

Best regards,

Flemming

[Salvatore Sanfilippo]

On Fri, Sep 19, 2014 at 1:55 PM, fj <flemmi...@gmail.com> wrote:
> My initial thoughts was to run with just a single replica for each master
> instance, but I'm guessing this is not enough if I want to use the WAIT
> command.
> I guess I will need at least 2 replicas per master instance.
>
> Otherwise what will happen in the situation where I have master and one
> replica in case the master goes down and the slave is promoted to be new
> master.
> Until the dead master comes back up again there is no replica at all and
> WAIT will always return 0 I guess?
>
> If I have 2 replicas per master and do WAIT 1, I can afford one of the
> replicas to be down.

Exactly. The case where you have two nodes (master + slave) and you do
WAIT 1, you actually mean "write this info into 2 nodes".
Since you have just 2 nodes, those are ALL the nodes, so the system is
only available when all the nodes are reachable, and is not able to
tolerate any failure.

Salvatore

[Varun Shankar]

Hi Salvatore,

I have a few doubts. We have our own logic for sharding data, we don't want Redis to shard for us. We run multiple standalone Redis servers, each hosting one shard. What we are looking forward to, is High Availability with 'strong consistency'. We want to implement master-slave replication with the guarantee that in case the master goes down and a replica is promoted, we never loose any data.  

What Redis tool(s) do we need?

The blog here (http://antirez.com/news/66) reads: 

The new implementation of Sentinel already elects the slave with the best replication offset 
available, assuming it publishes its replication offset via INFO (that is, it must be Redis 
2.8 or greater), so a good setup can be to run an odd number of Redis nodes, with a Redis 
Sentinel installed in every node, and use synchronous replication to write to the majority 
of nodes. As long as the majority of the nodes is available, a Sentinel will be able to 
win the election and elect a slave with the most updated data.

Does that mean Redis Sentinel with synchronous replication (using WAIT) ensures Strong consistency?

Also the Sentinel documentation here (http://redis.io/topics/sentinel) says this about 'synchronous replication':

Redis currently is not able to use any of the above systems, and is currently outside the development goals.

But redis does support 'synchronous replication' using WAIT (as mentioned here: http://antirez.com/news/66), right? Does that mean the doc is out dated?

[The Baldguy]

On Thursday, November 19, 2015 at 3:15:03 AM UTC-6, Varun Shankar wrote:

Hi Salvatore,

I have a few doubts. We have our own logic for sharding data, we don't want Redis to shard for us. We run multiple standalone Redis servers, each hosting one shard. What we are looking forward to, is High Availability with 'strong consistency'. We want to implement master-slave replication with the guarantee that in case the master goes down and a replica is promoted, we never loose any data.  

Redis does not provide strong consistency, even with the WAIT command. If you genuinely need a *distributed* system with Strong Consistency, Redis is not for you. Deep down even w/WAIT Redis replicated is still eventually consistent.

Because of various failure scenarios it can not be guaranteed that you can't lose data during a failover. Specifically think of a partition - either in software or networking (or software defined networking as is found in the various cloud providers). Because of this partition possibility it is possible for some clients to write to the original master during the failover. 

Consider also what a two node pod with WAIT causes to happen after a failover. After the failure of the master the newly promoted master is the sole node in the pod and if you properly require *your code* to not accept as written writes where the data was not written to the slave node (and thus revert writes where they did happen) as well you now have no availability instead of high availability. It doesn't really get better with three nodes, either. With three you either sacrifice strong consistency by not requiring all nodes or you sacrifice availability at all by requiring the write go to all three nodes. As with two when one fails you no longer have a system capable of providing that strong consistency because the partition or node failure will mean you can not write data. Despite common claims, you can not sacrifice partition tolerance. For a more thorough examination of the question see http://codahale.com/you-cant-sacrifice-partition-tolerance/ where you will find the quote: "You cannot, however, choose both consistency and availability in a distributed system.".

While many, especially non-technical pointy haired bosses, will claim you need 100% consistency guarantee (AND availability) it isn't really needed in the vast majority of cases (most banks don't even have it. A bank account is actually "eventually consistent"). I would recommend diving deeper in that requirement you will probably find there is in fact a window of consistency allowable. If not, then a Redis pod or Redis Cluster deployment will not meet your requirements.

Cheers,

Bill

[The Baldguy]

But redis does support 'synchronous replication' using WAIT (as mentioned here: http://antirez.com/news/66), right? Does that mean the doc is out dated?

 Synchronous replication was only one of the required conditions. The doc is still correct until and unless all the requisite conditions are in place.