This article mainly introduces Redis Sentinel, the high-availability architecture of Redis, and explains from several aspects such as what it is, why it is used, automated process, and deployment.
What is Redis Sentinel?
Redis Sentinel is a high-availability implementation of Redis. It is a distributed architecture that includes several Sentinel nodes and Redis data nodes. Each Sentinel node monitors the data node and other Sentinel nodes. When the node is found to be unavailable, the program will Automated processing does not require manual intervention, thereby efficiently solving the high availability problem of Redis.
Why use it?
The traditional master-slave replication mode synchronizes the data changes of the master node to the slave nodes. This has two effects:
As a backup for the failure of the primary node
Reduce the ``read'' pressure of the master node
In the master-slave replication mode, once the master node fails, manual intervention is required to perform failover during this process. The real-time performance cannot be guaranteed due to manual intervention, and the operation process is also prone to errors, which increases the inconvenience of the entire process. Therefore, a highly available architecture needs to be introduced to automate the entire process of transfer.
Automated process
The transfer process is the same as the manual intervention logic of master-slave replication. Here we first look at the manual intervention process:
The master node (M) fails, and the replication of the slave nodes (S1, S2) is interrupted.
Perform
slaveof no onean S1 slave node as the new node.Update the client redis link to the new master node S1, restart
Start copying the data of the master node S1 from the node S2, and wait for the recovery of the previous master node M to copy the data of the new master node S1.
The difference between Redis sentinel and master-slave mode is to add Sentinel nodes for Redis node monitoring.
As shown in the figure, each Sentinel node finds that the master node is faulty through regular monitoring (the master is offline)
Multiple Sentinel nodes reach an agreement on the failure of the master node and select a leader to be responsible for failover
The process of transferring data is consistent with the logic of "manual intervention" above, but it is automated.
After the transfer is completed, node slave-1 (or slave-2) becomes the master node, and the original master becomes the slave node
It can be seen from the above that Redis Sentinel has monitoring notifications, master node failover, and configuration (client connection to Sentinel node) and other functions.
Deploy online
Here, our deployment architecture uses 3 Sentinel nodes, 1 master node, and 2 slave nodes to form the Redis Sentinel architecture.
First, we start the master and slave nodes normally
Configure sentinel conf file
The configuration file redis_sentinel.conf is as follows:
port 26379
bind 10.xx.xx.xx
sentinel monitor mymaster 10.xx.xx.xx 6379 2
# 表示配置需要监控10.xx.xx.xx:6379
# 2表示至少需要2个Sentinel节点统一，
# mymaster是主节点别名，防止挂了也可以找到主节点
sentinel auth-pass mymaster password # 需要的密码
sentinel config-epoch mymaster 0 #确认mymater SDOWN时长
sentinel down-after-milliseconds mymaster 5000
# mymaster多久不响应认为SDOWN
sentinel failover-timeout mymaster 60000
# 2次failover切换时间
dir "/etc/redis" # 定义目录存放
daemonize yes
pidfile "/var/run/redis/redis-sentinel.pid"
logfile "/var/log/redis/redis-sentinel.log"Do the service startup script redis-sentinel.sh in
/etc/init.d/And the script is executable
sudo service redis-sentinel start
some advices
All nodes of Redis Sentinel should be distributed on different physical machines.
Deploy at least three and an odd number of Sentinel nodes
The client connects to the sentinel node.