master - master replication. will it ever happen?

56 views
Skip to first unread message

Paolo Denti

unread,
Aug 3, 2018, 6:16:03 PM8/3/18
to Redis DB
Hi,
does anybody have news regarding the potential development of active/bidirectional replication?

I understand it is not a priority and that many issues are to be addressed regarding active replication.
However geographic server distribution is more and more critical for middle to big sized systems. Horizontal scalability without geographical distribution is not really 100% effective.

Using a centralized server is not an effective solution because of latency
Using a master/slave solution is not working when you need to read & write in every location

We are heavily struggling with the issue and we are thinking, after waiting for a long time for the feature, to move to two separate distributed systems (one for messaging and one for distributed cache) because of the issue that it looks will never be addressed.

Something like Galera for MariaDB will ever be in the Redis plans? I read it was in alpha stage at 4.x but I see no news after 5.0 RC4

Chris Stanaway

unread,
Aug 3, 2018, 6:56:41 PM8/3/18
to redi...@googlegroups.com

--
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 https://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.

Paolo Denti

unread,
Aug 3, 2018, 8:19:39 PM8/3/18
to Redis DB
Thanks,
the issue was opened over 3 years ago, at version 2, and still open. it looks to me it will never go anywhere, or at least it has a very low priority

A multi data center is today a very common topology, that cannot, unfortunately, be managed.

Itamar Haber

unread,
Aug 4, 2018, 5:29:03 AM8/4/18
to Redis DB
Hello Paolo,

It would be interesting to learn about the use case for a master/master geo-distributed Redis deployment that you need, and the need for it. A distributed cache that provides local latencies is, for example, indeed becoming a common request.

From what I know about Redis' roadmap, improvements to the multi-dc replication story are planned but do not include a multi-master option.

That said, my employer offers the commercial version of Redis that includes a CRDT-based Active/Active replication.

Cheers,

To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+unsubscribe@googlegroups.com.

To post to this group, send email to redi...@googlegroups.com.
Visit this group at https://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.



--

Itamar Haber
Technicalist Evangenly

Phone: +972.54.567.9692

Redis Labs


Paolo Denti

unread,
Aug 4, 2018, 11:08:16 AM8/4/18
to Redis DB
Hi Itamar

this is the scenario

Application servers, located in different data centers, in different availability zones, pushing values into a worldwide distributed cache.

The issue is: we all know that the different data centers, as it is normally, can suffer temporary connection issues between them, it just happens. So having a centralized master, everyone pushing values from another AZ, is subject to delays or unavailability (everyone suffers from that, GCP, AWS, ... everyone).
So every application server today is in the bast case slowed down by the network latency. And sometimes heavily affected by overseas connection issues, even if rare and short, so you need to put in place a retry strategy.

A desirable scenario could be:
- every application server connects (both for write and reads) to a specific IP, located in the same data center
- all the masters synchronize themselves

The synchronization among the masters could happen in two different ways, configurable, depending on the use case needs:
- synchronous
- asynchronous

In synchronous mode, the write is considered completed after all the other masters get the update (slower write but consistent)
In asynchronous mode, the write is considered completed as soon as the master gets the write. The synchronization between the masters can be carried out afterwise (fast write as the read but potentially not consistent reads from the other application servers).

The second mode is much more interesting than it looks. Usually, a geo partitioning between app servers is logical a partitioning of data as well. If I manage a certain set of data because located in my region, it is totally acceptable that the whole system gets an update of the data not in a transactional way (any kind of one-way data logging, even if incremental, is an example of acceptable usage for asynchronous mode).

I hope it makes sense

Paolo

Itamar Haber
Technicalist Evangenly

Phone: +972.54.567.9692

Redis Labs


Itamar Haber

unread,
Aug 4, 2018, 12:29:34 PM8/4/18
to Redis DB
Lots of sense, thanks. Which of the Redis data structures are used in your distributed cache?

To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+unsubscribe@googlegroups.com.

To post to this group, send email to redi...@googlegroups.com.
Visit this group at https://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.

Paolo Denti

unread,
Aug 4, 2018, 1:09:45 PM8/4/18
to Redis DB
today not many types
- simple values
- lists
- ordered sets

Actually, I followed your suggestion regarding CRDT-based Active/Active replication. And from the specs point of view, it is exactly what I was looking for.
However, it is overkill. And not overkill because of too many features but overkill because all our system is based on shell deploy scripts, installing, expanding, configuring, ...
It looks to me that your product is exactly designed as an enterprise system, web interface, setup, ... and that is something we do not want to use.

Our desired (and current) approach for new server deploy is very agile, everything is a set of scripts that, just as a principle:
- deploy new servers
- install and configure basic distro
- downloads and installs additional software
- patches configuration files
- restarts the daemons
- ...
and I guess that your product is not compatible with our approach, even if perfectly aligned with our intended usage

Itamar Haber

unread,
Aug 4, 2018, 3:08:27 PM8/4/18
to Redis DB
Thanks for the input!

and that is something we do not want to use

Fair enough - I always try to be the last person who'd push you that way :P

To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+unsubscribe@googlegroups.com.

To post to this group, send email to redi...@googlegroups.com.
Visit this group at https://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.

Nick Farrell

unread,
Aug 6, 2018, 3:13:27 AM8/6/18
to Redis DB
I wonder whether redis streams could be used to support the async model? I haven't thought it through, but something like this:

each 'remote' node creates a redis stream. Each time there is a global state change, it is appended to the stream, along with its old value (or a more complex CAS marker, if preferred)
a listener on the central node subscribes to all remote nodes' streams. Whenever a value is received, it is processed, updating the central value, if it passes the CAS consistency check
(optional) set up each remote node as a redis slave, which will automatically sync whatever changes are made centrally.

This is a bit hacky, and depends on your use case, but it is one option which allows remote nodes to access the last-known upstream value, as well as queue changes for ingestion later on.

Reply all
Reply to author
Forward
0 new messages