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 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.
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.
Redis Sentinel vs Redis Cluster
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 nodes goes down
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.
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 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.
Originally published at RTFM: Linux, DevOps and system administration.