Is Redis Replication Strong?

[CharSyam]

Hi. everyone.

I am curious about redis replication.

I heard that redis replication is async. at that time Does it guarantee consistency between master and slave?

otherwise, I just might understand that it is similar to mysql's async replication.

and if replication operation fails at that time, what happen? retry? or discard?

thank you.

[Dvir Volk]

On Tue, Jul 10, 2012 at 6:00 PM, CharSyam <char...@gmail.com> wrote:

Hi. everyone.

I am curious about redis replication.

I heard that redis replication is async. at that time Does it guarantee consistency between master and slave?

it guarantees eventual consistency, not immediate consistency. but most of the time it is near immediate. 

and if replication operation fails at that time, what happen? retry? or discard?

 

if a slave disconnects, it will do a full resync with the master once it reconnects. you can control whether while resyncing it will server the old data or not.

you can read a whole lot about it here, it will give you all the info you need.

have fun!

http://redis.io/topics/replication

thank you.

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To view this discussion on the web visit https://groups.google.com/d/msg/redis-db/-/ggq14O10DAkJ.
To post to this group, send email to redi...@googlegroups.com.
To unsubscribe from this group, send email to redis-db+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/redis-db?hl=en.

[CharSyam]

Thanks dvirsky.

I worry about this situation.

I suppose that I run 2 Redis server using replication.

Master successfully processed a request, but M fails before M sent replication message to S.

and I changed S to M. at the time. the data will be lost. 

Of course, I already know it is common situation with async-replication

I just want to know that Is there another way to enhance consistency?

Thank you.

thank you.

To unsubscribe from this group, send email to redis-db+unsubscribe@googlegroups.com.

[Hampus Wessman]

Hi!

CharSyam skrev 2012-07-10 17:46:
> Thanks dvirsky.
>
> I worry about this situation.

That's good. You should. It depends on your application whether
asynchronous replication is acceptable or not.

>
> I suppose that I run 2 Redis server using replication.
>
> Master successfully processed a request, but M fails before M sent
> replication message to S.
>
> and I changed S to M. at the time. the data will be lost.
>
> Of course, I already know it is common situation with async-replication
>
> I just want to know that Is there another way to enhance consistency?
>

You're actually talking about durability here. There is only one way to
make sure you don't lose data on a failover and that is to use
synchronous replication of some sort. If the master returns success
before it knows that the command has arrived at the slave, then it will
always be possible that the master fails and the write is lost when
doing a failover (even though the client was told that the write
succeeded!).

When it comes to consistency, please keep in mind that it can mean a few
different things. The data at the slave is always "internally"
consistent in Redis (just like an RDB snapshot is too). What I mean is
that you will never see e.g. half-completed or reordered operations
applied at the slave. Due to asynchronous replication, the master and
the slave is not necessarily consistent in regard to each other, however
(the slave can lag behind). This kind of consistency is only required if
you need to send requests to both the master and the slave (and need
e.g. a write to the master to be guaranteed to show up in a subsequent
read to the slave). One way to implement this is to use synchronous
replication.

Redis does not support synchronous replication (at the moment) and
frankly, it's not primarily designed to be used when data durability is
extremely important. For maximum durability, you can use "appendfsync
always" in the configuration file and (if you need even more) you can
use e.g. DRBD to synchronously replicate the filesystem between two
machines (or use a SAN with synchronous replication built-in). This way
you will need to reload the data from (the replicated) disk on another
machine when doing a failover. Be warned, it will be slow! This is the
only (simple) way to guarantee zero data loss on a failover with Redis,
AFAIK.

Cheers,
Hampus

>
> On Tuesday, July 10, 2012 11:08:20 PM UTC+8, dvirsky wrote:
>
>
> On Tue, Jul 10, 2012 at 6:00 PM, CharSyam <char...@gmail.com
> <mailto:char...@gmail.com>> wrote:
>
> Hi. everyone.
>
> I am curious about redis replication.
>
> I heard that redis replication is async. at that time Does it
> guarantee consistency between master and slave?
>
>
> it guarantees eventual consistency, not immediate consistency. but
> most of the time it is near immediate.
>
>
> and if replication operation fails at that time, what happen?
> retry? or discard?
>
> if a slave disconnects, it will do a full resync with the master
> once it reconnects. you can control whether while resyncing it will
> server the old data or not.
>
> you can read a whole lot about it here, it will give you all the
> info you need.
> have fun!

> http://redis.io/topics/replication <http://redis.io/topics/replication>

>
>
>
>
>
> thank you.
>
>
> --
> You received this message because you are subscribed to the
> Google Groups "Redis DB" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/redis-db/-/ggq14O10DAkJ

> <https://groups.google.com/d/msg/redis-db/-/ggq14O10DAkJ>.

> To post to this group, send email to redi...@googlegroups.com

> <mailto:redi...@googlegroups.com>.

> To unsubscribe from this group, send email to

> redis-db+u...@googlegroups.com
> <mailto:redis-db%2Bunsu...@googlegroups.com>.

> For more options, visit this group at
> http://groups.google.com/group/redis-db?hl=en

> <http://groups.google.com/group/redis-db?hl=en>.

>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Redis DB" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/redis-db/-/hX3PCTyTVsgJ.

> To post to this group, send email to redi...@googlegroups.com.
> To unsubscribe from this group, send email to

> redis-db+u...@googlegroups.com.

[Salvatore Sanfilippo]

On Tue, Jul 10, 2012 at 5:46 PM, CharSyam <char...@gmail.com> wrote:

> I worry about this situation.
> I suppose that I run 2 Redis server using replication.
> Master successfully processed a request, but M fails before M sent
> replication message to S.
> and I changed S to M. at the time. the data will be lost.

Here there are two issues. One is that you need synchronous
replication semantic before replying with an OK code, so that for
instance the client can show that a money transaction successfully
happened, and no one can change this after the fail over.

The other is, that, if you need this, you also need to have this
guarantees on the master, that means that you need AOF with "always"
fsync policy, basically trashing Redis performances (inevitably).

In my opinion there are two simple possibilities here:

1) For this kind of data where you need this kind of durability, use a
traditional RDBM system with synchronous replication.
2) Alternatively for the functions of your application that are in
need of this kind of safety, write wrapper functions that write on the
master and check on the slave before returning an OK code, and that
even try to undo the operation on the master if the slave is not
reachable.

Cheers,
Salvatore

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

Beauty is more important in computing than anywhere else in technology
because software is so complicated. Beauty is the ultimate defence
against complexity.
— David Gelernter

[CharSyam]

Thanks to Hampus and Salvatore.

To be honest, I already know the answer. 

because it is the same with Mysql's replication(mysql's default replication is async, of course we can use sem-sync or if you use other rdms, you can use sync-replication too ) but your answers are more detail than I expect. thank you very much.

but I want to verify my thought. and I am sure, in the case of mission critical, i have to be careful.

Salvtore, When do you release sentinal and cluster? 

Thank.

[Salvatore Sanfilippo]

On Wed, Jul 11, 2012 at 10:29 AM, CharSyam <char...@gmail.com> wrote:

> Salvtore, When do you release sentinal and cluster?

I'm writing a message about this to the group right now :) Thanks.

[guru singh]

Hi Salvatore,

I would like to discuss point number 2 in the possibilities you mention above.
We are building our project with redis as the primary datastore,
therefore I am also interested in minimizing data loss in case of
master failing before sending replication data to slave.
We have 3 instances on AWS EC2, 1 master, 2 slaves with AOF
persistence on the slaves
What I am doing is that in cases, where write commands are being
executed on the master I ensure that I read the value from slave (just
of the last written key) before returning OK. In case the slave is not
reachable, I roll-back the changes in the master and return 500 error
code to the user.
I haven't load tested this so I cant speak of performance.
What do you think of this approach?

Questions:
1) What is the most efficient way to do a read on the slave to ensure
it is up-to-date with the master?
Check once or loop 2-3 times?
2) This setup means that in order for the application to stay up and
not respond with HTTP 500 error codes, the master and at least one
slave will *always* have to be a up. Is there a better approach than
this?

Regards
Gurteshwar

> --
> You received this message because you are subscribed to the Google Groups "Redis DB" group.

> To post to this group, send email to redi...@googlegroups.com.

> To unsubscribe from this group, send email to redis-db+u...@googlegroups.com.

[qyloxe]

Hmm, we already have AOF. What if we add to every record in AOF incremental value, unique at single node level. The AOF would change to a journal file. At the time of inconsistency between nodes, the slave could synchronize only records/keys changed after last known unique id from master node.

Q