Redis集群安装之哨兵集群

客官°小女子只卖身不卖艺 2024-03-17 11:27 62阅读 0赞

## 1.哨兵集群介绍及原理 ##

主从模式，当主节点宕机之后，从节点是可以作为主节点顶上来，继续提供服务的。但是有一个问题，主节点的`IP`已经变动了，此时应用服务还是拿着原主节点的地址去访问，此时就需要人工干预进行修改。哨兵恰恰就可以解决这个问题。

访问`redis`集群的数据都是通过哨兵集群的，哨兵监控整个`redis`集群。一旦发现`redis`集群出现了问题，比如主节点挂了，从节点会顶上来。但是主节点地址变了，这时候应用服务无感知，也不用更改访问地址，因为哨兵才是和应用服务做交互的。`Sentinel`很好的解决了故障转移，在高可用方面又上升了一个台阶，当然`Sentinel`还有其他功能。比如 主节点存活检测、主从运行情况检测、主从切换。`Redis`的`Sentinel`最小配置是 一主一从。

![在这里插入图片描述][0f91fdacbc2f4f0487690154fa73a0e1.png_pic_center]

### 1.1.`redis`哨兵模式原理 ###

哨兵模式建立在主从复制基础之上，会在每一个`redis`节点上打开一个`sentinel`监控，每个`sentinel`进程都有自己的端口号和`IP`，所有`sentinel`共享集群信息，集群中所有的`sentinel`都是可以通信的，当主库宕机后，主库上的`sentinel`就会向集群中的其他节点的`sentinel`发送信息说主库宕机了，需要在从库上选举`master`，这时每个节点上的`sentinel`会比较自己`redis`配置的`ID`号，比如`slave1`的`ID`号大，`slave1`就会选举为`master`作为主库，当故障的主库重新加入集群后，主库上的`sentinel`会向其他节点的`sentinel`询问谁是主库，这时`slave1`上的`sentinel`就会告诉主库上的`sentinel`说`slave1`是主库，重新加入集群的主库就会找`slave1`同步数据，如果重新加入的主库想再次成为主库，只需要执行提权命令就可以重新成为主库。

主从复制的时候程序配置`redis`地址的时候都是写死主库的地址，每次主库宕机都需要手动修改应用。

有了哨兵模式后，在程序代码中配置不是`redis`地址，而是配置的所有哨兵的地址，形成一个地址池，即使集群中一个哨兵坏掉了，还有其他两个哨兵，每次需要找`redis`写入数据时，程序首先会找哨兵进程，哨兵之间信息共享，会立马告诉程序谁是主库，这时程序拿到哨兵告诉它的`redis`主库地址，就会去找主库存数据，因此即使主库坏了，也不需要修改程序代码。

哨兵的配置文件在启动哨兵服务后，尽量不要去修改，因为哨兵会自动增加配置。

哨兵集群个数建议是奇数，比如3/5/7。

配置了哨兵后，当主库挂掉，哨兵选举了新库，会自动把配置文件修改为最新主库的地址。

### 1.2.哨兵的选举规则 ###

首选判断`slave-priority`权重优先级，谁的高谁当选为`master`主库，如果都一致，那么久比较各个节点的`id`，谁的大谁当选。

### 1.3.哨兵模式监控的原理 ###

*  每个`Sentinel`以每秒钟一次的频率，向它所有的**主服务器**、**从服务器**以及其他`Sentinel`实例 发送一个`PING`命令。
 *  如果一个实例（`instance`）距离最后一次有效回复`PING`命令的时间超过`down-after-milliseconds`所指定的值，那么这个实例会被`Sentinel`标记为**主观下线**。
 *  如果一个**主服务器**被标记为**主观下线**，那么正在监视这个**主服务器**的所有`Sentinel`节点，要以每秒一次的频率确认该**主服务器**是否的确进入了**主观下线**状态。
 *  如果一个**主服务器**被标记为**主观下线**，并且有足够数量的`Sentinel`（至少要达到配置文件指定的数量）在指定的时间范围内同意这一判断，那么这个该**主服务器**被标记为**客观下线**。

![在这里插入图片描述][f0d53beaef4b47ae96289b5b5c388fa4.png_pic_center]

在一般情况下， 每个`Sentinel`会以每 10秒一次的频率，向它已知的所有**主服务器**和**从服务器**发送`INFO`命令。当一个**主服务器**被`Sentinel`标记为**客观下线**时，`Sentinel`向**下线主服务器**的所有**从服务器**发送`INFO`命令的频率，会从10秒一次改为 每秒一次。`Sentinel`和其他`Sentinel`协商主节点的状态，如果主节点处于`SDOWN`状态，则投票自动选出新的主节点。将剩余的从节点指向新的主节点进行数据复制。

当没有足够数量的`Sentinel`同意**主服务器**下线时，**主服务器**的**客观下线状态**就会被移除。当**主服务器**重新向`Sentinel`的`PING`命令返回 有效回复 时，**主服务器**的**主观下线状态**就会被移除。

## 2.搭建哨兵集群 ##

### 2.1.集群结构 ###

这里我们搭建一个三节点形成的`Sentinel`集群，来监管之前的`Redis`主从集群。如图：

![在这里插入图片描述][a69cf9ea6d85406ab4873271637611fa.png_pic_center]

三个`sentinel`实例信息如下：

### 2.2.准备实例和配置 ###

要在同一台虚拟机开启3个实例，必须准备三份不同的配置文件和目录，配置文件所在目录也就是工作目录。

我们创建三个文件夹，名字分别叫`s1`、`s2`、`s3`：

# 进入/tmp目录
    cd /tmp
    # 创建目录
    mkdir s1 s2 s3

如图：

![在这里插入图片描述][1ddfb7fe995c4a93a489a2e3964b6448.png_pic_center]

然后我们在`s1`目录创建一个`sentinel.conf`文件，添加下面的内容：

# 哨兵sentinel实例运行的端口
    port 27001
    
    # 明确指定哨兵的ip
    sentinel announce-ip 10.0.4.10
    
    # 哨兵模式是否后台启动，默认no，改为yes
    daemonize yes
    
    # log日志保存位置
    logfile /usr/local/redis/sentinel/redis-sentinel.log
    
    ###核心配置
    # 核心配置。
    # 第三个参数：哨兵名字，可自行修改。（若修改了，那后面涉及到的都得同步） 
    # 第四个参数：master主机ip地址
    # 第五个参数：redis端口号
    # 第六个参数：哨兵的数量。比如2表示，当至少有2个哨兵发现master的redis挂了，
    #               那么就将此master标记为宕机节点。
    #               这个时候就会进行故障的转移，将其中的一个从节点变为master
    # sentinel monitor <master-name> <ip> <redis-port> <quorum>
    sentinel monitor mymaster 10.0.4.10 7001 2
    
    # 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供密码
    # 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码
    # sentinel auth-pass <master-name> <password>
    sentinel auth-pass mymaster 123456
    
    # 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒
    # sentinel down-after-milliseconds <master-name> <milliseconds>
    sentinel down-after-milliseconds mymaster 5000
    
    # 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行同步,这个数字越小，完成failover所需的时间就越长，但是如果这个数字越大，就意味着越多的slave因为replication而不可用。
    # 可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
    # sentinel parallel-syncs <master-name> <numslaves>
    sentinel parallel-syncs mymaster 1
    
    # 主备切换的时间，若在3分钟内没有切换成功，换另一个从节点切换
    # sentinel failover-timeout <master-name> <milliseconds>
    sentinel failover-timeout mymaster 60000
    
    # 哨兵sentinel的工作目录
    dir "/home/redis/s1"

然后将`s1/sentinel.conf`文件拷贝到`s2`、`s3`两个目录中（在`/home`目录执行下列命令）：

# 方式一：逐个拷贝
    cp s1/sentinel.conf s2
    cp s1/sentinel.conf s3
    # 方式二：管道组合命令，一键拷贝
    echo s2 s3 | xargs -t -n 1 cp s1/sentinel.conf

修改`s2`、`s3`两个文件夹内的配置文件，将端口分别修改为27002、27003：

sed -i -e 's/27001/27002/g' -e 's/s1/s2/g' s2/sentinel.conf
    sed -i -e 's/27001/27003/g' -e 's/s1/s3/g' s3/sentinel.conf

### 2.3.启动 ###

为了方便查看日志，我们打开3个`ssh`窗口，分别启动3个`redis`实例，启动命令：

# 第1个
    redis-sentinel s1/sentinel.conf
    # 第2个
    redis-sentinel s2/sentinel.conf
    # 第3个
    redis-sentinel s3/sentinel.conf

启动后：

![在这里插入图片描述][fa9eb8352e1e4481b5433ccad722982b.png_pic_center]

![在这里插入图片描述][b78316ff193646d89c0db8e252977bf9.png_pic_center]

![在这里插入图片描述][05689d6928164a8486ca9b247f4831d4.png_pic_center]

### 2.4.测试 ###

尝试让`master`节点7001宕机，查看`sentinel`日志：

![在这里插入图片描述][6da7c19bcb0441d08d1b3fdc922543eb.png_pic_center]

![在这里插入图片描述][46ec90e4ef9a42269d9e2bfac2fc008a.png_pic_center]

![在这里插入图片描述][23e706d720bb465abc2532348605fc16.png_pic_center]

日志解读：

`@` 字符之后的内容用于指定主服务器， 这些内容是可选的， 它们仅在 `@` 字符之前的内容指定的实例不是主服务器时使用。

*  `+reset-master <instance details>` ：主服务器已被重置。
 *  `+slave <instance details>` ：一个新的从服务器已经被`Sentinel`识别并关联。
 *  `+failover-state-reconf-slaves <instance details>` ：故障转移状态切换到了 `reconf-slaves` 状态。
 *  `+failover-detected <instance details>` ：另一个`Sentinel`开始了一次故障转移操作，或者一个从服务器转换成了主服务器。
 *  `+slave-reconf-sent <instance details>` ：领头（`leader`）的`Sentinel`向实例发送了`SLAVEOF host port`命令，为实例设置新的主服务器。
 *  `+slave-reconf-inprog <instance details>` ：实例正在将自己设置为指定主服务器的从服务器，但相应的同步过程仍未完成。
 *  `+slave-reconf-done <instance details>` ：从服务器已经成功完成对新主服务器的同步。
 *  `-dup-sentinel <instance details>` ：对给定主服务器进行监视的一个或多个`Sentinel`已经因为重复出现而被移除 —— 当`Sentinel`实例重启的时候，就会出现这种情况。
 *  `+sentinel <instance details>` ：一个监视给定主服务器的新`Sentinel`已经被识别并添加。
 *  `+sdown <instance details>` ：给定的实例现在处于主观下线状态。
 *  `-sdown <instance details>` ：给定的实例已经不再处于主观下线状态。
 *  `+odown <instance details>` ：给定的实例现在处于客观下线状态。
 *  `-odown <instance details>` ：给定的实例已经不再处于客观下线状态。
 *  `+new-epoch <instance details>` ：当前的纪元（`epoch`）已经被更新。
 *  `+try-failover <instance details>` ：一个新的故障迁移操作正在执行中，等待被大多数`Sentinel`选中（`waiting to be elected by the majority`）。
 *  `+elected-leader <instance details>` ：赢得指定纪元的选举，可以进行故障迁移操作了。
 *  `+failover-state-select-slave <instance details>` ：故障转移操作现在处于 `select-slave` 状态 ——`Sentinel`正在寻找可以升级为主服务器的从服务器。
 *  `no-good-slave <instance details>` ：`Sentinel`操作未能找到适合进行升级的从服务器。`Sentinel`会在一段时间之后再次尝试寻找合适的从服务器来进行升级，又或者直接放弃执行故障转移操作。
 *  `selected-slave <instance details>` ：`Sentinel`顺利找到适合进行升级的从服务器。
 *  `failover-state-send-slaveof-noone <instance details>` ：`Sentinel`正在将指定的从服务器升级为主服务器，等待升级功能完成。
 *  `failover-end-for-timeout <instance details>` ：故障转移因为超时而中止，不过最终所有从服务器都会开始复制新的主服务器（`slaves will eventually be configured to replicate with the new master anyway`）。
 *  `failover-end <instance details>` ：故障转移操作顺利完成。所有从服务器都开始复制新的主服务器了。
 *  `+switch-master <master name> <oldip> <oldport> <newip> <newport>` ：配置变更，主服务器的`IP`和地址已经改变。 **这是绝大多数外部用户都关心的信息。**
 *  `+tilt` ：进入`tilt`模式。
 *  `-tilt` ：退出`tilt`模式。

查看7002的日志：

![在这里插入图片描述][e7d1329d6bd241df97c175ef4421e4c1.png_pic_center]

查看7003的日志：

![在这里插入图片描述][56b55abbb3334043b5426588edb616ac.png_pic_center]

[0f91fdacbc2f4f0487690154fa73a0e1.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/6f5970574122439988ac8cd804c8d37d.png
[f0d53beaef4b47ae96289b5b5c388fa4.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/331add07ed2b4087977a0392e635419a.png
[a69cf9ea6d85406ab4873271637611fa.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/e248b100630c486b85c8583ca438b30c.png
[1ddfb7fe995c4a93a489a2e3964b6448.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/89b762300d2b464bb9d58a61089b2441.png
[fa9eb8352e1e4481b5433ccad722982b.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/1e298534b22649bfbcc26301f86a9c11.png
[b78316ff193646d89c0db8e252977bf9.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/ae056bad03c94c428ccb529aef789c2a.png
[05689d6928164a8486ca9b247f4831d4.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/0cb75c63612a44a9b6f3fb71458769bb.png
[6da7c19bcb0441d08d1b3fdc922543eb.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/7cefe360393942db9ae16fe89e37efa0.png
[46ec90e4ef9a42269d9e2bfac2fc008a.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/701b211bc3bc460798d0caf6157a11c9.png
[23e706d720bb465abc2532348605fc16.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/effb9e8483ac43bd96e30af4f6c6a550.png
[e7d1329d6bd241df97c175ef4421e4c1.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/d8b72e5623ca4f439206a9100d67925a.png
[56b55abbb3334043b5426588edb616ac.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/d2ad4acb97794eb9973c024043d3f65b.png