文章目录

前言
一. 哨兵群集理论
二. 环境搭建（一主二从三哨兵）
- 1. 准备三台设备，都安装redis 5.0.7 版本
- 2. 修改redis配置文件
- 3. 重新启动，加上配置文件,使其生效
- 4. 配置slave1，slave2 ,同样配置
- 5. 测试主从复制
- 6. 从安装包复制哨兵配置文件到bin目录
- 7. 各节点配置 sentinel.conf
- 8. 执行启动哨兵，让其后台运行
- 手动关闭master ，测试哨兵监控
- 9. 发现自动将master 切换为 192.168.100.18 了,切换成功
- 10. 将原先的master 修复之后，自动变为了从，而且其身上的哨兵监控的地址也会自动改变（哨兵会自动加入群集）
三 . 哨兵故障恢复的原理

前言

一. 哨兵群集理论

1、哨兵简介:Redis Sentinel
Sentinel(哨兵)是用于监控redis集群中Master状态的工具，其已经被集成在redis2.4+的版本中是Redis官方推荐的高可用性(HA)解决方案。
2、作用
1)：Master状态检测
2)：如果Master异常，则会进行Master-Slave切换，将其中一个Slave作为Master，将之前的Master作为Slave
3)：Master-Slave切换后，sentinel.conf的监控目标会随之调换
3、工作模式
1)：每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令
2)：如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值，则这个实例会被 Sentinel 标记为主观下线。
3)：如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。
4)：当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态，则Master会被标记为客观下线。
4、主观下线和客观下线
主观下线：Subjectively Down，简称 SDOWN，指的是当前一个Sentinel 实例对某个redis服务器做出的下线判断。
客观下线：Objectively Down，简称 ODOWN，指的是多个 Sentinel 实例在对Master Server做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，然后开启failover

二. 环境搭建（一主二从三哨兵）

1. 准备三台设备，都安装redis 5.0.7 版本

hostnamectl set-hostname redis-master
hostnamectl set-hostname redis-slave1
hostnamectl set-hostname redis-slave2
//安装
yum install -y gcc gcc-c++ make

//解压安装包，make编译
tar zxvf redis-5.0.7.tar.gz -C /opt/
cd /opt/redis-5.0.7/
make
make PREFIX=/usr/local/redis/ install

[root@promote redis-5.0.7]# cd utils/ #一直回车到最后只修改路径
[root@localhost utils]# ./install_server.sh

输入的是可执行文件的路径

Selected config:
Port           : 6379
Config file    : /etc/redis/6379.conf
Log file       : /var/log/redis_6379.log
Data dir       : /var/lib/redis/6379
Executable     : /usr/local/redis/bin/redis-server
Cli Executable : /usr/local/redis/bin/redis-cli
Is this ok? Then press ENTER to go on or Ctrl-C to abort.
Copied /tmp/6379.conf => /etc/init.d/redis_6379
Installing service...
Successfully added to chkconfig!
Successfully added to runlevels 345!
Starting Redis server...
Installation successful!
[root@redis-master utils]#
安装完毕！

确认服务启动

[root@redis-master utils]# netstat -natp | grep 6379
tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN      24254/redis-server

//创建软链接，优化服务

ln -s /usr/local/redis/bin/* /usr/local/bin/

2. 修改redis配置文件

[root@redis-master utils]# vim /etc/redis/6379.conf
bind 0.0.0.0
protected-mode no # 将加密保护关掉。此时外部网络可以直接访问

3. 重新启动，加上配置文件,使其生效

[root@redis-master utils]# /etc/init.d/redis_6379 restart
Stopping ...
Redis stopped
Starting Redis server...
[root@redis-master utils]#

4. 配置slave1，slave2 ,同样配置

vim /etc/redis/6379.conf

5. 测试主从复制

在master 创建KEY
[root@redis-master utils]# redis-cli
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> set name sha
OK
127.0.0.1:6379> get name
"sha"
127.0.0.1:6379>

在 slave1 查看

[root@redis-slave1 utils]# redis-cli
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> get name
"sha"
127.0.0.1:6379>

在 slave2 查看
[root@redis-slave2 utils]# redis-cli
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> get name
"sha"
127.0.0.1:6379>

6. 从安装包复制哨兵配置文件到bin目录

cp /opt/redis-5.0.7/sentinel.conf  /usr/local/redis/bin/
常用配置选项意义：
protected-mode no  #关闭保护模式
 
port 26379  #端口号
 
dir /tmp   #目录
 
sentinel parallel-syncs mymaster 1    #故障迁移的时候，复制的从服务器的个数
 
sentinel failover-timeout mymaster 180000  #故障迁移所需时间，也就是主服务器挂了之后，选举新服务器的时间，如果这个时间还没能选举出来，那么就算选举失败
 
sentinel deny-scripts-reconfig yes
 
sentinel monitor mymaster 192.168.74.129 6379 2 #这个是指哨兵监视哪个redis集群，这里监视的是192.168.124.20，6379是端口号，最后的2表示，如果主服务器挂了，3个哨兵中有2个投票选新的服务器，那么就可以进行故障迁移，选出了新的服务器
 
sentinel down-after-milliseconds mymaster 3000  #sentinel认为“主线下线”的一个阀值。

Vim  /usr/local/redis/bin/sentinel.conf

7. 各节点配置 sentinel.conf

Master 配置
最好配置为其IP地址

slave 1 配置

slave2 配置

8. 执行启动哨兵，让其后台运行

redis-server /usr/local/redis/bin/sentinel.conf  --sentinel  &      


[root@redis-master bin]# redis-server /usr/local/redis/bin/sentinel.conf --sentinel &

手动关闭master ，测试哨兵监控

redis-cli shutdown

9. 发现自动将master 切换为 192.168.100.18 了,切换成功

10. 将原先的master 修复之后，自动变为了从，而且其身上的哨兵监控的地址也会自动改变（哨兵会自动加入群集）

三 . 哨兵故障恢复的原理

 选出领头哨兵后，领头哨兵将会开始对主数据库进行故障恢复。步骤如下:

首先领头哨兵将从停止服务的主数据库的从数据库中挑选一个来充当新的主数据库。

序号	挑选依据
1	所有在线的从数据库中，选择优先级最高的从数据库。优先级通过replica-priority参数设置
2	优先级相同，则复制的命令偏移量越大(复制越完整)越优先
3	如果以上都一样，则选择运行ID较小的从数据库

2.选出一个从数据库后，领头哨兵将向从数据库发送SLAVEOF NO ONE命令使其升格为主数据库，而后领头哨兵向其他从数据库发送 SLAVEOF命令来使其成为新主数据库的从数据库，最后一步则是更新内部的记录，将已经停止服务的旧的主数据库更新为新的主数据库的从数据库，使得当其恢复服务时自动以从数据库的身份继续服务

Redis集群单点fail故障恢复

如果单点单机fail，单机重启后直接利用redis启动命令，redis-server [redis.conf路径] 重启后会自动回到集群中。

本文地址：https://blog.csdn.net/BIGmustang/article/details/109630739

redis群集搭建—哨兵模式(理论加实例)