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

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.

Replication

• 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.

Sharding

• With the data segmentation – all data will be split into a few parts and this will improve each node’s performance as it will store only some part of the data and will not serve all requests.
• Using this approach – the write requests will go faster.
• See Partitioning: how to split data among multiple Redis instances and Redis Cluster data sharding.

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

• Redis community
• Redis replication
• Redis cluster tutorial
• Redis Cluster Specification
• Intro to Redis Cluster Sharding
• How to Setup Redis Cluster from Source
• Redis Replication vs Sharding
• Redis Cluster vs Redis Replication
• Redis Sentinel & Redis Cluster – what?
• What Redis deployment do you need?

Similar Posts

• Redis: replication, part 2 – Master-Slave replication, and Redis Sentinel
• What is: YAML – Its overview, basic data types, YAML vs JSON, and PyYAML