4

I am using redis version 2.8.3. I want to build a redis cluster. But in this cluster there should be multiple master. This means I need multiple nodes that has write access and applying ability to all other nodes.

I could build a cluster with a master and multiple slaves. I just configured slaves redis.conf files and added that ;

slaveof myMasterIp myMasterPort

Thats all. Than I try to write something into db via master. It is replicated to all slaves and I really like it.

But when I try to write via a slave, it told me that slaves have no right to write. After that I just set read-only status of slave in redis.conf file to false. Hence, I could write something into db. But I realize that, it is not replicated to my master replication so it is not replicated to all other slave neigther.

This means I could'not build an active-active cluster.

I tried to find something whether redis has active-active cluster capability. But I could not find exact answer about it.

Is it available to build active-active cluster with redis? If it is, How can I do it ?

Thank you!

Ahmet DAL
  • 4,445
  • 9
  • 47
  • 71

2 Answers2

2

Redis v2.8.3 does not support multi-master setups. The real question, however, is why do you want to set one up? Put differently, what challenge/problem are you trying to solve?

It looks like the challenge you're trying to solve is how to reduce the network load (more on that below) by eliminating over-the-net reads. Since Redis isn't multi-master (yet), the only way to do it is by setting up each app server with a master and a slave (to the other master) - i.e. grand total of 4 Redis instances (and twice the RAM).

The simple scenario is when each app updates only a mutually-exclusive subset of the database's keys. In that scenario this kind of setup may actually be beneficial (at least in the short term). If, however, both apps can touch all keys or if even just one key is "shared" for writes between the apps, then you'll need to bake locking/conflict resolution/etc... logic into your apps to consolidate local master and slave differences (and that may be a bit of an overkill). In either case, however, you'll end up with too many (i.e. more than 1) Redises, which means more admin effort at the very least.

Also note that by colocating app and database on the same server you're setting yourself for near-certain scalability failure. What will happen when you need more compute resources for your apps or Redis? How will you add yet another app server to the mix?

Which brings me back to the actual problem you are trying to solve - network load. Why exactly is that an issue? Are your apps so throughput-heavy or is the network so thin that you are willing to go to such lengths? Or maybe latency is the issue that you want to resolve? Be the case as it may be, I recommended that you consider a time-proven design instead, namely separating Redis from the apps and putting it on its own resources. True, network will hit you in the face and you'll have to work around/with it (which is what everybody else does). On the other hand, you'll have more flexibility and control over your much simpler setup and that, in my book, is a huge gain.

Itamar Haber
  • 47,336
  • 7
  • 91
  • 117
  • In my structure, I have two application running on different server. They are gonna both write into redis. Redises are gonna be on same server that applications on. If I have one instance that have write access, network will be loaded little more. I wanted to make redis active-active not to cause this problem. But I see, it is not available with version 2.8.3 – Ahmet DAL Jan 22 '14 at 08:31
  • Let me make sure I understand correctly: you have two physical/virtual servers, each running a different app. Each of the apps needs to access the same Redis database because they share the data. You don't want to have Redis on just one of the servers because you are worried about the network load, so you want to have a local Redis on each app server. Your apps will then write and read from their respective local instances and these local instances should somehow synchronize the data in a multi-master fashion. Correct? – Itamar Haber Jan 31 '14 at 17:03
  • Yes. This is exactly, what I was talking about – Ahmet DAL Feb 01 '14 at 00:15
  • That being the case, I think a simpler solution would to have Redis run off another (third) server. Besides being very KISS and readily supported by every Redis version, this architecture also makes sense in terms of looking forward and thinking about scalability. – Itamar Haber Feb 02 '14 at 20:01
1

Redis Enterprise has had this feature for quite a while, but if you are looking for an open source solution KeyDB is a fork with Active Active support (called Active Replica).

Setting it up is just a little more work than standard replication:

  1. Both servers must have "active-replica yes" in their respective configuration files
  2. On server B execute the command "replicaof [A address] [A port]" Server B will drop its database and load server A's dataset
  3. On server A execute the command "replicaof [B address] [B port]" Server A will drop its database and load server B's dataset (including the data it just transferred in the prior step)
  4. Both servers will now propagate writes to each other. You can test this by writing to a key on Server A and ensuring it is visible on B and vice versa.

https://github.com/JohnSully/KeyDB/wiki/KeyDB-(Redis-Fork):-Active-Replica-Support

John Sully
  • 239
  • 2
  • 2
  • 1
    Note I was initially blown away by master-master integration in KeyDB (a feature that cost $$$ for Redis Enterprise). Turns out though that KeyDB master-master lacks the complex CRDTs support that Redis has which means its quite basic and dangerous. In KeyDB the two or more masters can overwrite each other's data or worse swap changed data if it changes at the same time. In Redis's CRDT implementation you can even increment counters on both masters and resolve to the correct math on both of them. I'm hoping that CRDT support comes to KeyDB sooner than later but understand how complex it is. – Mauvis Ledford Aug 17 '21 at 10:46