Redis: Replication, Part 1 – An Overview. Replication vs Sharding. Sentinel vs Cluster. Redis Topology
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.
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
readrequests 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
writerequests 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
sentinelbinary orredis-serverin 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
writeoperations 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?