Circular replication
bbroerman
with each one slaveof the other? The documentation talks only of
setting it up as a tree structure, but since slaves can have slaves as
well, it is theoretically possible to set it up as a ring...
Salvatore Sanfilippo
This setup does not work in Redis (see other recent thread in the
maling list about it), but the interesting thing is that it is a lot
less useful than it appears, and actually, you should not easily trust
database systems claiming to support circular replication (also called
master-master or multi-master mode), including MySQL.
The point is that, if there is not a solid merging strategy for
differences, there is no real deal here.
You have instance A and B in multi master setup.
Clients write and read against A or B, indifferently. Now there is
already a read-after-write concern, but let's assume that our design
tolerate that if you write in A the change may appear in B with some
delay, without issues for our application.
Now there is a network partition splitting A and B, and clients in two
subgroups Ca and Cb, where Ca clients can only talk with A, and Cb
clients cal only talk with B. During the partition time A and B get
two writes against the same key. in A it is set to "foo" and in B it
is set to B.
Now the partition is resolved and A and B can already chat together.
Let's assume that A and B queued writes to send to the other master.
Now what you need is a way to understand that the same data was
written during the partition and is now different in the two sides,
you also need to find who wins. There are the obvious latest-write
wins strategy, or client-side resolution and so forth.
This is already a mess showing how master-master is actually a
cluster, with *all* its complexities. But with Redis things go further
since we have commands that modify values in complex ways, like
appending an element to a list, so we need more interesting merging
strategies for different data types, and that will work fast even for
multi million aggregate data types.
So master-master is a complex cluster to work well, and now we should
ask ourselves how many databases claiming master-master are actually
able to do the right thing.
Cheers,
Salvatore
> --
> 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.
> For more options, visit this group at http://groups.google.com/group/redis-db?hl=en.
>
--
Salvatore 'antirez' Sanfilippo
open source developer - VMware
http://invece.org
"We are what we repeatedly do. Excellence, therefore, is not an act,
but a habit." -- Aristotele
Emanuele Rogledi
Josiah Carlson
On Sun, Feb 19, 2012 at 4:08 AM, Emanuele Rogledi <rog...@gmail.com> wrote:
> Do you think this is an acceptable scenario?
>
> ServerA -> Slave of ServerB
> ServerB -> Slave of ServerA
>
> By default i write always on ServerA, if something goes wrong on ServerA, i
> start write on ServerB
> and, when ServerA is restored, it get syncronized with ServerB and ServerA
> give back the "default virtual master role"
No, this does not work. Depending on your timing, you may not ever get
any data to actually be written to either of them, or you may get data
that alternates between two (or more) values. If you do certain
operations (rpush/lpush, append 'a', etc.), you may even cause Redis'
memory to grow without bound until it crashes itself or your system.
Or if you do other operations, Redis will try to consume as much
processor as it can on your two servers.
Circular replication does not work with Redis and was never intended
to work with Redis. If it "works" for some reason, it wasn't intended,
and I can just about guarantee that it will break at some point down
the line (could be seconds or days).
Regards,
- Josiah
