Re: Two Servers, both masters and slaves of each other in Redis?

[Brian P O'Rourke]

Redis doesn't support multi-master configuration. The problem you'll
run into is when any sort of split happens in the link between the two
servers - slave will try to resync from master, discarding its own
local database. This will lead to unpredictable behavior and data
loss.


On Tue, Nov 13, 2012 at 4:14 PM, Dennis McEntire <dmce...@gmail.com> wrote:
> I might be wrong here, but is this possible? Two Redis servers, both are
> slaves of each other. I thought I tried this and it worked, and the data
> synchronized with each other. If a duplicate key was used, the key data
> would just be the newest entry. I have a production installation supporting
> an application where there is never any chance that a duplicate key would
> ever be used. Does this actually work or will it blow up somehow?
>
> The goal here is high availability, as it would be possible on the client
> side to select either server based on it's availability.
>
> Thanks in advance,
>
> Dennis
>
> --
> 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/-/89XyYiKqOUYJ.
> 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.

[Josiah Carlson]

It's even worse.

Say you have A and B. B is slave of A, initially. The moment that A
becomes a slave of B, B will initiate a dump, and send that to A. Upon
receiving the dump, A will load the dump, kill B's connection, which
will cause B to reconnect and re-slave. This will cycle until you kill
one, both, or change the slave configuration.

If you are lucky, you might be able to get a write in, maybe you can
get a quantum write (where you may be able to see the data or not,
depending on your timing), maybe you can see two versions of the data.

Long story short: don't do that, it doesn't work, doesn't do what you
expect, and is a REALLY bad idea.

Regards,
- Josiah

[Dennis McEntire]

Thank you everyone for the clarification on this -- I'm glad it's not as simple as I thought. I am in the process of trying out Redis Sentinel to see how it will offer an automated failover solution. Thanks again for the help!

Dennis

[Dennis McEntire]

One quick question in regards to this. Here's a simple sitation: We have one master and one slaveof the master. Replication works fine and does what it's supposed to do. But just to clarify:

1. If the master fails, and the connection is broken, the slave doesn't dump it's local copy of the data, correct?
2. We would need to promote the slave to a new master if the master dies, and I hope it keeps its data.

Does this sound correct? Maybe I missed something but from what you guys have written I get the idea that the slave might dump it's copy of the data if the connection is broken between itself and the master.

Thanks again in advance,

Dennis

[Marc Gravell]

Correct, when you promote a slave to master, it **does not** dump memory; you can do this manually by issuing a "slaveof no one" (iirc) to make sure it knows it isn't a slave. This is especially important from 2.6 onwards, where by default slaves are read-only. This (promoting a slave to master) is also one of the things that "sentinel" can do for you if you want.

Marc

To view this discussion on the web visit https://groups.google.com/d/msg/redis-db/-/b9YRm0MCmfIJ.

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.

--
Regards,

Marc