Home > Article > Backend Development > Introduction to the principles of Redis sentinel mechanism (picture and text)
Introduction to the principles of Redis sentinel mechanism (picture and text)
- 青灯夜游forward
- 2019-02-26 09:57:264800browse
The content of this article is to introduce the sentinel mechanism of Redis, so that everyone can understand the principle of the sentinel mechanism and how to implement it. It has certain reference value. Friends in need can refer to it. I hope it will be helpful to you.
)
Overview
Redis replication has a shortcoming. When the host Master goes down, we need Solve the switch manually, such as using slaveof no one. In fact, master-slave replication has not been implemented. High availability focuses on backup machines and uses the redundancy of the system in the cluster. When a machine in the system is damaged, other backup machines can quickly take over it to start the service.
Problems with master-slave replication
Once the master node goes down and the write service cannot be used, You need to manually switch, reselect the master node, and manually set the master-slave relationship.
So how to solve it? If we have a monitoring program that can monitor the status of each machine and make timely adjustments, turning manual operations into automatic ones. The emergence of Sentinel is to solve this problem.
The principle and implementation of the sentinel mechanism
Redis Sentinel
Redis Sentinel is a distributed architecture that contains several Sentinel nodes and Redis data nodes. Each Sentinel node monitors the data node and other Sentinel nodes. When it finds that the node is unreachable, it will mark the node offline. If the identified master node is the master node, it will also "negotiate" with other Sentinel nodes. When most Sentinel nodes believe that the master node is unreachable, they will elect a Sentinel node to complete automatic failover and at the same time Notify the Redis application side of this change in real time. The entire process is completely automatic and does not require manual intervention, so this solution effectively solves the high availability problem of Redis.
As shown in the figure:
Basic failover process
1) The master node fails. At this time, the two slave nodes lose connection with the master node, and the master-slave replication fails.
 "155114582447049Introduction to the principles of Redis sentinel mechanism (picture and text)")
2) Each Sentinel node discovers that the master node has failed through regular monitoring
3) Multiple Sentinel The nodes agree on the failure of the primary node and elect one of the nodes as the leader responsible for failover.
#4) The Sentinel leader node performed failover. The entire process is basically the same as our manual adjustment, but it is completed automatically.
5) After the failover, the entire Redis Sentinel structure re-elected a new master node.
Instance
Use docker to create the following redis container
redis-sentinel1 172.10.0.9 22530 -> 22530 sentinel redis-sentinel2 172.10.0.10 22531 -> 6379 sentinel redis-sentinel3 172.10.0.11 22532 -> 6379 sentinel redis-master2 172.10.0.5 6383 -> 6379 Master redis-slave2 172.10.0.6 6384 -> 6379 Slave redis-slave3 172.10.0.7 6385 -> 6379 Slave
Configuration
Sentinel's core configuration
sentinel monitor mymaster 127.0.0.1 7000 2
The name, IP and port of the monitored master node. The last 2 means how many Sentinels are found. problem, failover will occur. For example, if the configuration is 2, it means that at least 2 Sentinel nodes believe that the master node is unreachable, so this unreachable determination is objective. The smaller the setting, the looser the conditions for reaching the offline level, and vice versa. It is generally recommended to set it to half the Sentinel node plus 1.
sentinel down-after-millseconds mymaster 30000
This is the timeout (unit: milliseconds). For example, when you go to ping a machine and you still can't ping it after a long time, then it is considered to be a problem.
sentinel parallel-syncs mymaster 1
当 Sentinel 节点集合对主节点故障判定达成一致时，Sentinel 领导者节点会做故障转移操作，选出新的主节点，原来的从节点会向新的主节点发起复制操作，parallel-syncs 就是用来限制在一次故障转移之后，每次向新的主节点发起复制操作的从节点个数，指出 Sentinel 属于并发还是串行。1代表每次只能复制一个，可以减轻 Master 的压力。
sentinel auth-pass <master-name> <password></password></master-name>
如果 Sentinel 监控的主节点配置了密码，sentinel auth-pass 配置通过添加主节点的密码，防止 Sentinel 节点对主节点无法监控。
sentinel failover-timeout mymaster 180000
表示故障转移的时间。
技巧
1）Sentinel 节点不应该部署在一台物理“机器”上。
这里特意强调物理机是因为一台物理机做成了若干虚拟机或者现今比较流行的容器，它们虽然有不同的 IP 地址，但实际上它们都是同一台物理机，同一台物理机意味着如果这台机器有什么硬件故障，所有的虚拟机都会受到影响，为了实现 Sentinel 节点集合真正的高可用，请勿将 Sentinel 节点部署在同一台物理机器上。
2）部署至少三个且奇数个的 Sentinel 节点。
3个以上是通过增加 Sentinel 节点的个数提高对于故障判定的准确性，因为领导者选举需要至少一半加1个节点，奇数个节点可以在满足该条件的基础上节省一个节点。
【相关文章】
以上就是本篇文章的全部内容，希望能对大家的学习有所帮助。更多精彩内容大家可以关注php中文网相关教程栏目！！！
The above is the detailed content of Introduction to the principles of Redis sentinel mechanism (picture and text). For more information, please follow other related articles on the PHP Chinese website!