4

I'm reading a lot of documentation around Redis network configurations, and I'm confused about how it seems the requirements in the architecture mental model I had, don't seem to map with the current options.

First of all: I don't need sharding, because scalability is not an issue at the moment. So one master for now (node M).

Second: I want redundancy, that is, if a master node fails, I want a second node to take over, and conduct the requests that the client is sending them. Let's call this the first slave: the fail-over slave (node FS).

Third: I also want another replica node, that is a slave but that only serves read-only queries. If a client connects to it, and the client tries to modify data, the node should give an error. Let's call this the second slave: the read-only slave (RS).

Last: I want fail-over for the read-only slave. That is, in case RS dies, I want another read-only slave to take over its tasks. Let's call this the fourth slave: the fail-over read-only slave (FRS).

Is there a way to configure Redis like this? Seems all deployment modes (was reading this article: https://blog.octo.com/en/what-redis-deployment-do-you-need/) have a single master except the Cluster one. Now, it seems my "FS" node would be a second master because it accepts write-queries, however, the Cluster configuration defaults to Sharding enabled and seems there's no normal way to disable it, unless I'm missing something.

2

From what I understand, redis sentinel will meet your needs.

You will have 1 master (M) and 3 slaves (FS, RS and FRS). Each of the slaves are connected to the same master.

You then deploy an odd number of sentinel processes that monitor the master. If the master fails, the sentinels will promote one of the three slaves to the new master.

Now, from your notes, you want to make the "FS" slave as the new master. Sentinel doesn't know "FS" is special, it can choose any of the 3 slaves as the candidate for the new master. To make "FS" special, you need to set "replica-priority" for each of the slaves. You don't want "RS" and "FRS" to ever become the master - so set replica-priority = 0 for both those nodes. Then sentinel will only consider "FS" when it is time to make a failover.

The other part of your question - what happens when "RS" dies? There is no failover mechanism for slaves - it just isn't needed. "RS" and "FRS" are just two read-replicas, both pointing to the same master. Clients should be configured to try one of the two replicas randomly - so you distribute load. If "RS" dies, the client simply tries "FRS". Since it is readonly - consistency of data does not matter.


For RS and FRS - set an additional property replica-read-only yes. That will ensure that writes fail.

You can use a non-sentinel setup if you wish. If you do so, the failover from M to FS won't happen automatically. If/When the master M goes down, you will have to a) detect it, b) mark FS as slaveof none, c) ensure all your redis clients start writing to the new master, and d) reconfigure RS and FRS to start following the new master. Sentinel does that automatically but has increased complexity. You can do it on your own manually easily as well.

  • thanks Sripathi, I have two further questions: when configuring RS and FRS as "replica-priority", if a client tries to do a "write" operation, will they refuse it? (remember, they are meant to be read-only); and last but not least: it seems Sentinel is the most complex setup to prepare because the client needs to be aware of it (as opposed to the other setups which are transparent to the client), judging by what I'm reading here: github.com/ServiceStack/ServiceStack.Redis/wiki/Redis-Sentinel (cannot I use a non-Sentinel setup that fits my needs?) – knocte Nov 14 '18 at 2:30
  • Edited the answer to respond to your questions – Sripathi Krishnan Nov 14 '18 at 2:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.