Redis databases can store small, short-lived, and complex objects that persist for months. Regardless of the complexity and size of the objects, continuous availability of those data is a must to provide seamless back-end service to the client.Usually, the standalone Redis installation is easy to configure and utilize. But it is not the best option to use in an environment where node failures can occur. Data durability can be retained with Redis append-only file(AOF) feature in Redis but is not the ideal solution for high availability. Similarly, the Redis RDB files can be used as a backup option which is a point-in-time representation of the data. Both of these options do not address the problem of sudden Redis node failures.So, Redis introduced several built-in features to support the high availability of Redis databases discussed in the following section.

Database Replication

Database replication is the fundamental technique behind making a database system fault-tolerance and continuously available. Replication copies data from the master database(primary database) to one or more slave databases(replicas) that ensure the data is accessible at any time if a master node fails. This process is coupled with an automatic failover process which promotes a new master from the available replica nodes when the master node fails.

Built in Redis Replication

Redis started supporting replication from its earliest versions and immensely improved. The standalone version supports basic replication with the slaveof command by converting an existing node to a slave of the primary database node. Also, the Redis sentinel feature enables replication with a more advanced failover feature. In addition, the Redis cluster supports a rich set of high-availability features for more distributed and large database systems.

Basic Redis Replication with slaveof Command

One of the fundamental ways to achieve the Redis replication is by using the slaveof command.

It is one step away from making a Redis instance a slave node. The following line should be added to the config file of the particular instance:

Use Case

The following example demonstrates a scenario where a given Redis instance is configured to be a slave node of a master node that runs in the 127.0.0.1 address at the 7000 port.

With this configuration, the master database will copy all the data to the slave node which ensures the slave is an exact copy of the primary database node.

Once the master node is up and running at 127.0.0.1 and port 7000, Let us start the other instance whose configuration file contains the slaveof configuration. The new instance will run at port 7001.

The new instance is started successfully and synced with MASTER runs at 127.0.0.1(port 7000).

If you write some data to the master node, those can be read from the slave as follows. It means master and replica have been synced properly.

Writing data to the master node runs at the port 7000 as follows.

Reading data from the slave node runs at the port 7001 as shown in the following:

With this setup, when the Redis master fails, we already have an exact copy of the primary database running at port 7001. Similarly, you can configure multiple slaves for a given master node. The only drawback in this setup is that you need to manually take care of the failover process.

Pros

• Easy and less time-consuming to set up.
• This setup will work as long as a single master node is available and even without a single slave node.
• Possible to automate with configuration management tools.

Cons

• The master failover process is not automated.
• Since the reads are asynchronous, stale reads can occur.
• Master and slave utilization is not equal due to the sharding is not supported.

High Availability with Redis Sentinel

Redis sentinel was introduced to deal with the drawbacks of the previous solution. Redis Sentinel is a distributed system that acts as an advanced high-availability solution for Redis along with other features like notification provider, monitoring tools, and configuration provider for clients.

The Sentinel is capable of promoting a slave to a master node automatically without any human intervention. The master failover process starts if the specified maximum number of sentinel nodes(Quorum) agree that the master node is not reachable. So, the availability of the sentinel nodes is important. However, it is recommended to use a separate sentinel cluster to run sentinel nodes separately from master nodes. With this setup, Redis clients first talk to the sentinel node and ask for information about the currently running master node. Then only the clients will work with the current master.

It is possible to start a Redis server in sentinel mode as shown in the following command:

As shown in the following output, the server has been started in sentinel mode.

Furthermore, Redis sentinels can be collocated with the Redis servers as well.

Pros

• Automatic failover feature
• Simple and less time-consuming to configure

Cons

• Sentinel needs a separate cluster if not collocated with the Redis server nodes
• Master and slave node utilization is unbalanced due to no sharding option available
• Redis Sentinel is a distributed system and involves a considerable amount of maintenance

High Availability with Redis Clustering

With the latest Redis releases, a cluster component was added to the Redis stack. It supports:

• Sharding
• Replication
• High availability

So, the Redis cluster addresses several aspects that are missing in previous solutions. It became hugely beneficial for large enterprises that generate and store a large amount of data. Because sharding distributes your data among multiple masters, each having a subset of the whole key space. It gives you a massive performance boost.

At the same time, replication is available in Redis clusters where you can configure multiple slave nodes for a given master. Usually, a cluster node should contain exactly one Redis server instance. But it is possible to configure cross-replication by deploying multiple instances in a single node.

In addition, the automatic failover option is provided by the Redis clusters where the slave node will promote to a master. In a cluster setup, the quorum is not required to promote a new master node or sharding to work. The master node quorum is only necessary for the whole cluster to run.

So, the Redis cluster solution can be seen as an all-in-one solution for those who are looking for sharding, replication, and high availability in their applications.

Pros

• Supports sharding which gives a performance boost when querying Redis data store.
• Provides automatic failover solution
• Master-replica support

Cons

• Maintaining a cluster might be a considerable amount of work
• Lack of library support

Conclusion

Redis supports high availability with standalone Redis, Redis Sentinel model, and built-in cluster component. All three solutions have their pros and cons as discussed above. Overall, Redis sentinel is the go-to option if you are only looking for high availability and do not care about performance. But if you are looking for a balance between performance and high availability with cross-replication, no doubt, the Redis cluster is the best among all three.