Click here to Skip to main content
14,217,056 members
Click here to Skip to main content
Technical Blog
Posted 29 Mar 2019


1 bookmarked

Redis: Replication, Part 1 – An Overview. Replication vs Sharding. Sentinel vs Cluster. Redis Topology

Rate this:
0.00 (No votes)
Please Sign up or sign in to vote.
0.00 (No votes)
29 Mar 2019     CPOL    
In this post – some quick overview, a brief explanation about differences in Redis data storage, topology examples. In short terms but with links to detailed documentation and other useful posts on other resources.

Initially, it was planned to write one small post with an example of how to create a Redis replication but as I read more and more details – I wanted to describe more and more about it, so eventually I split this post into two parts.

In this one – some quick overview, a brief explanation about differences in Redis data storage, topology examples.

In short terms but with links to detailed documentation and other useful posts on other resources.

In the second part – a couple of examples of how to configure a simple replication and replication with Redis Sentinel.

Redis Replication vs Sharding

Redis supports two data sharing types replication (also known as mirroring, a data duplication), and sharding (also known as partitioning, a data segmentation). In this – Redis Cluster can use both methods simultaneously.


  • Is a data coping overall Redis nodes in a cluster which allows to make requests to one or more slave nodes and making data persistence if some of those nodes will go down, providing a High Availability.
  • Using this approach – the read requests will be faster.
  • See Replication and Redis Cluster master-slave model.


Redis Sentinel vs Redis Cluster

Redis Sentinel

  • Was added to Redis v.2.4 and basically is a monitoring service for master and slaves.
  • Also, can send notifications, automatically switch masters and slaves roles if a master is down and so on.
  • Might have a sense to be used for a bare master-slave replication (see below) without full clustering.
  • It works as a dedicated daemon using a sentinel binary or redis-server in the sentinel mode.
  • Will perform nodes reconfiguration if the master went down – will choose a new master from the slaves left.
  • Requires at least three Sentinel instances to have a quorum for a new master election and to decide if one of a Redis node goes down.

Redis Cluster

  • Was added to Redis v.3.0 and represents a full clustering solution for segmentation, replication, and its nodes management.
  • Will perform data synchronization, replication, manage nodes access persistence if some will go down.
  • The Sentinel usage in the Redis Cluster case doesn’t make sense as Cluster will do everything itself.
  • See Redis Sentinel & Redis Cluster – what? and Redis Sentinel Documentation.

Redis Topology

One Redis Instance

  • The simplest and most classical case.
  • Simple in running and configuration.
  • Limited by a host’s resources – its CPU and memory.
  • In case such Redis instance will go down – all dependent services will be broken as well as there is no availability or fault tolerance mechanisms.

Master-Slave Replication

  • One master which has multitype slaves attached.
  • Data will be updated on this master and then the master will push those changes to its replicas.
  • Slaves can talk to the master only and can’t communicate with other slaves, but still can have their own slaves.
  • Slaves are read-only nodes – no data changes can be performed there unless this wasn’t configured explicitly (see the second part of this post).
  • In case any node will go down – all data still will be available for clients as data is replicated over all nodes.
  • Simple in configuration but the write operations are limited by the master’s resources.
  • In case the master will go down – you’ll have to manually reconfigure slaves and change slave to master roles for one on them.
  • Also, clients need to know which they have to use for writes operations.

Redis Sentinel

  • Already described above but a few more words here.
  • Similarly to the Redis Replication – Sentinel has one Master instance which has a priority when deciding on a Redis master’s elections.
  • I.e., in case of one Redis Master and two slaves and if Sentinel Master works on the same host where Redis Master is running and this host will go down – Sentinel will choose Sentinel’s new Master instance and those two Sentinels instances need to decide which Redis slave will have to become a new Redis Master.
  • During this – a Sentinel’s Master will have more weight in such an election.
  • Keep in mind that not every Redis client able to work with Sentinel, all client can be found here>>>.

Redis Cluster

And the most powerful solution – the Redis Cluster.

  • Has a few master instances and each can have one more – up to 1000 – slaves.
  • Will take care of data sharding, replication, synchronization, and failover operations.
  • Must have at least 6 Redis nodes – 3 for masters and three for slaves.
  • Can redirect clients requests to a necessary master or slave host – but the client must have an ability to work with Redis Cluster.

Related Links

Similar Posts


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Ukraine Ukraine
DevOps, cloud and infrastructure engineer. Love Linux, OpenSource, and AWS.

Comments and Discussions

-- There are no messages in this forum --