Redis High Availability: Easy Guide to Setup Crucial Processes 101

Redis is a popular cache that uses an in-memory database that’s open-source and written entirely in C. Many often refer to Redis as a data structure, as its core data types are quite similar to those that you’d expect with other programming languages, including lists, strings, and sets.

Redis High Availability is most commonly used as a cache to store data that are frequently accessed. This allows Redis to be used as a powerful caching layer on servers, as it not only improves user experience and productivity but also results in faster load times and improves web app performance.

It’s generally straightforward to connect with a standalone Redis server. However, if you want to achieve High Availability, you will need to use Redis Sentinel. This is a process that automates and simplifies replication failover.

Redis Sentinel is great as it offers more granular monitoring into replica or master instances and even has a notification system that you can set up. To achieve Redis High Availability, you’ll want to use a master and slave configuration, via Redis Sentinel. Let’s discuss about the required concepts in detail.

Table of Contents

1. What is Master and Slave Replication?
2. What is a Command Line?
3. How to Configure for Redis High Availability?
4. Other Options Available to Configure for Redis High Availability
5. Conclusion

What is Master and Slave Replication?

When you create a master Redis server, you should know that several Redis slave servers can be deployed too, ideally on different nodes spread throughout numerous data centers. This way, in case the master is not reachable, any of the slave Redis servers can take its place. 

Ultimately, this allows for high availability, as data can be served with minimal to no interruption whatsoever. Since Redis is so incredibly simple, there are a number of tools that can be used to create and then manage a configuration that includes a master and slave Redis server.

However, the most popular solution for maintaining Redis High Availability is to use Redis Sentinels, which generally run as different processes to monitor master-slave sets. Currently, Sentinel 2 is the latest version, and you can run it using the following command:

Redis-sentinel /path/to/sentinel.conf

Before you start using Sentinel, it is imperative that you also deploy a configuration file, as the file is used to save the system’s current state, and in case of a restart, the configuration file will be used for reloading. Without a configuration file, Redis Sentinel will not start.

Configuring for Redis High Availability

The source distribution for Redis High Availability generally comes with a file known as sentinel.conf. Think of it as a sample configuration file that you can use to easily configure Redis Sentinel. 

But, if you want to configure this yourself, the code generally looks like this:

sentinel monitor master 127.0.0.1 6382 3
sentinel down-after-milliseconds master 60000
sentinel failover-timeout master 180000
sentinel parallel-syncs master 1

sentinel monitor flash 192.168.22.74 6380 3
sentinel down-after-milliseconds flash 10000
sentinel failover-timeout flash 180000
sentinel parallel-syncs flash 5

When setting up the configuration file, you have to highlight which masters you want Sentinel to monitor. This is done by giving a separate name to each master. Importantly, replicas don’t need a name, since they’re discovered automatically.

Then, Redis Sentinel will get to work, updating the configuration on its own with any new information about the replicas. The configuration file is edited and rewritten every time there’s a chance in the master-slave configuration, primarily during a failover.

The sample configuration above shows monitoring for two separate instances of Redis High Availability, each including a master and replicas (unstated figure). The master is entitled “master” and the other is called “flash.”

What is a Command Line?

To better understand the commands, let’s run through them one by one. The very first line tells Redis to start monitoring “master,” and the address is specified, along with the port. The quorum for this is set at 3. Essentially, the quorum dictates the number of Sentinels that should confirm that the master is unreachable, triggering the failover procedure.

Essentially, the quorum is important to decide the newly elected leader once the failover procedure is initiated. Essentially, if the quorum is set at 3, and there are 7 sentinel processes, three Sentinels must agree about the master not being reachable.

As a result, one of the three will then initiate the failover. Thus, this ensures that the failover process is always triggered.

Redis Sentinel Automatic Failover — Understanding The Process

To better understand Redis High Availability, Redis Sentinel, and the processes behind it, it’s important to know what’s going on underneath. Essentially, for Redis High Availability, Redis Sentinel regularly checks the Slave and the Master instances within the cluster. This way, in case a failure is detected in the Master node, the slaves must reach a quorum.

As soon as they do, the Sentinel then picks a Slave server and then promotes it to Master. The remaining Slave servers are then reconfigured, acknowledging the new Master instance.

Sentinel is an incredibly powerful distributed system and has multiple fail-safes to ensure that an appropriate slave instance is chosen as the master instance.

Other Options Available to Configure for Redis High Availability

There are a couple of other options that you should know about when dealing with the Sentinel configuration file when configuring for Redis High Availability. Generally, these include the following:

• Down-after-milliseconds
• Parallel-syncs

Down-after-milliseconds indicates the time, in milliseconds, for which a master must not be reachable before the Sentinel begins to evaluate the possibility of it being down.

Parallel-syncs define the number of replicas that can be reconfigured for use once the new master is selected as the failover process is completed. 

You also have the option to configure parameters during runtime when dealing with the Redis High Availability, i.e., the Redis Sentinel configuration file.

Conclusion

If you want a robust replication setup with Redis, using Sentinel is definitely important. Not only does it simplify the replication failover process, but it makes it easy to switch quickly and efficiently. This ensures that your data is always available and that there is always an instance available, you should absolutely consider using Redis Sentinel.

Redis is an extremely powerful database that offers support for multiple data structures. If you’re using Redis, you should configure it with Redis Sentinel for high availability. 

If you want to pull all your data into a data warehouse without writing a single line of code, try Hevo. Hevo lets you load data from different sources easily, moving it to its desired destination without requiring any code. If you’re using Redis, you can add Hevo Data to visualize all your data using a BI tool as well.

Hevo greatly simplifies the management process and the ETL processes for both destinations and the sources of data too.

Hevo Data, a No-code Data Pipeline can transfer real-time data from a vast sea of 100+ sources to a Data Warehouse, BI Tool, or a Destination of your choice. Hevo is a reliable, completely automated, and secure service that doesn’t require you to write any code!

Hevo, with its strong integration with 100+ sources and BI tools (Including 40+ Free Sources), allows you to not only export & load data but also transform & enrich your data & make it analysis-ready in a jiffy.

Want to take Hevo for a ride? Sign Up for a 14-day free trial and simplify your Data Integration process. Do check out the pricing details to understand which plan fulfills all your business needs.

Tell us about your experience of learning about the Redis High Availability Guide! Share your thoughts with us in the comments section below.