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