redis clusters (Sentinel)

problem

Redis Sentinel master mode is how to ensure high availability depends find fault and failover main sentry

Outline

This article assumes that the reader of the main redis have been learned from replication. Redis Redis main sentry clusters provide a highly available , namely high availability is the main purpose of sentinel pigs mode, which is the complete list of the macro function Sentinel

Monitoring: monitoring the situation of examples
Notification: notification
Automatic failover: When Master abnormal offline, will automatically be elected
Configuration provider: to provide configuration information.

Precautions

In the configuration mode Sentinel a few things to note:

Examples of the at least three guaranteed
Since Redis uses asynchronous replication, therefore Sentinel + Redis distributed system can not guarantee a confirmed reservation written during the fault.
After opening Sentinel, Sentinel client also needs the support mode

work process

Distributed server layout

The master may be a layout Sentinel

This is the simplest layout, attached to the Sentinel instance, when an instance down, then the Sentinel will naturally fall down, while the figure quorum = 2is what this means, then explain in later chapters. This layout will be distributed two server "split brain" problem, as shown below

At this point you can see a replcation became the new master, and if the client at the moment of writing redis then the data will be lost, redis.conf two parameters can be set

min-replicas-to-write 1
min-replicas-max-lag 10

Using the above configuration, Redis instance when acting as a primary example, if you can not write at least one copy, will stop accepting written. Because the replication is asynchronous, and can not actually write means that the replica is disconnected, or no acknowledgment is sent asynchronously than the specified maximum number of seconds to delay us.

Another layout

Both the strengths and weaknesses can be seen behind the official website documents

流程

Sentinel 可以分为以下几个步骤

各个Sentinel认为 master 主观下线
多个 Sentinel 认为 master 客观下线
故障转移

检测主观下线状态

主观下线是什么意思呢？就是（站在Sentinel的角度）认为自己监听的 master 下线了，超过了某个心跳的时间没有回应。

检测客观下线状态

当Sentinel判定master 主观下线后，它就会去询问其他Sentinel是否他们也监控到master 下线了，当达到一定的数量，Sentinel 就会将服务器判定为客观下线，并对主服务器执行故障转移操作。而这个数量就是我们上面讲到的 quorum,上面的例子就是：当询问到有包括自己有两台 Sentinel 监控到master 下线了，那么就判定主服务器客观下线。

选举 Snentinel

为什么要选举 Snentinel 呢？现在主服务器下线了，那么需要选举一台 Sentinel 来进行协调工作，使得故障转移得以进行。那么如何选举呢？选举的方法和 Raft 的方式一样，本文不再重复，参阅参考资料。

故障转移

故障转移共分为下面几步

选出新的主服务器
修改从服务器的复制目标
将旧的主服务器变为从服务器第一步，选举新的主服务器的标准肯定是谁拥有最新的记录最有资格充当主服务器了（主从复制，复制一半主挂了），而第二步也很好理解，既然旧的主服务器已经挂了，新的被选出来，自然要修改从服务器的复制目标，最后旧的服务器变成从服务器。

底层实现

参阅以下链接

https://www.cnblogs.com/renpingsheng/p/9803838.html 我们也可以从上面的工作原理猜测，Sentinel 不仅要有连接 master和 replication的通信通道，还要有连接其他的Sentinel的通信通道，以便监控判定主服务器客观下线和其他功能。

实践部分

使用docker 搭建主从集群

实践部分参照以下链接，在此表示感谢！

https://www.cnblogs.com/bixiaoyu/p/10745874.html

我们将要搭建是这个布局的分布式 redis集群

先搭建docker ip相关。

 docker network create --subnet=172.60.0.0/16 mynetwork

搭建之前我们需要redis.conf 和 sentinel.conf 文件，获取方法可以去下载redis的config文件夹下拿到。

master 主服务器

然后执行

docker run -d -p 6900:6900   -v /home/docker_software/redis/redis.conf:/usr/local/etc/redis/redis.conf -v /home/docker_software/redis/data:/data  -v /home/docker_software/redis/sentinel_master.conf:/usr/local/etc/redis/sentinel.conf  --name redis-ip-m  --net=mynetwork --ip 172.60.0.2 docker.io/redis redis-server /usr/local/etc/redis/redis.conf --appendonly yes

-d : 后台运行
-p : 端口映射
-v : 挂载目录和文件，上面用于redis.conf 和 sentinel.conf 放进容器内，而/data 则是数据目录，因为 docker 停止后数据会丢失，所以/data 目录挂载在宿主机器中
redis-server : 启动的服务
/usr/local/etc/redis/redis.conf ：启动的配置（由于配置了挂载文件所以执行的挂载文件）
-ip : 指定ip地址
--appendonly yes : 运行参数，表明进行持久化

replication1 从服务器

修改redis.conf ,在最后一行加上

slaveof 172.60.0.2 6900 ##主从复制

执行

 docker run -d -p 6901:6901   -v /home/docker_software/redis/redis1.conf:/usr/local/etc/redis/redis.conf -v /home/docker_software/redis/data1:/data  -v /home/docker_software/redis/sentinel_r.conf:/usr/local/etc/redis/sentinel.conf  --name redis-ip-r1  --net=mynetwork --ip 172.60.0.3 docker.io/redis redis-server /usr/local/etc/redis/redis.conf --appendonly yes

另外一台从服务器也是同样的步骤，搭建完后是这样的：

[root@localhost redis]# docker ps 
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                              NAMES
7bc085663022        docker.io/redis     "docker-entrypoint..."   2 hours ago         Up 2 hours          6379/tcp, 0.0.0.0:6902->6902/tcp   redis-ip-r2
8eebf70c4a84        docker.io/redis     "docker-entrypoint..."   2 hours ago         Up 2 hours          6379/tcp, 0.0.0.0:6901->6901/tcp   redis-ip-r1
28e0f66cbd40        docker.io/redis     "docker-entrypoint..."   2 hours ago         Up 2 hours          6379/tcp, 0.0.0.0:6900->6900/tcp   redis-ip-m

共三台。

sentinel 监控

进入容器内，修改 sentinel.conf 文件，将

#sentinel myid b82a11362cfc53b1d8e552f04acada1d13946b11 commented 

Sentinel Monitor 6900 2 mymaster 172.60.0.2 

logfile "/ Data / Sentinel" address # Log

Comment out because the other two also specify the id from sentinel.conf server (set up when copied with a sentinel.conf), other configuration files to see conf explained.

then

/usr/local/bin/redis-sentinel /usr/local/etc/redis/sentinel.conf

The other two servers also start such a step, and then to take a look at our log log output address

We can see the other two sentinel also started.

Failover testing

We use

docker stop master container

The main server stop, look at the log what happens.

We can see from the server successfully become the new master server and the old primary server from the server, the experiment succeeded!

Reference material

https://redis.io/topics/cluster-tutorial/
https://www.cnblogs.com/renpingsheng/category/1317158.html
https://www.cnblogs.com/fan-gx/p/11463400.html
https://www.cnblogs.com/bixiaoyu/p/10745874.html (from the main building, we recommend a look)