Initially, it was planned to write one small post with an example 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 distribution types, 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.
In the third part – the redis-py library examples with Redis replication and 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.
Limited by a host’s resources – its CPU and memory.
In case of such Redis instance will go down – all dependent services will be broken as well as there is no any availability or fault tolerance mechanisms.
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 of 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 of 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.
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>>>.
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.