哨兵(sentinal)
哨兵是Redis集群架构中非常重要的一个组件,哨兵的出现主要是解决了主从复制出现故障时需要人为干预的问题。
1.Redis哨兵主要功能
(1)集群监控:负责监控Redis master和slave进程是否正常工作
(2)消息通知:如果某个Redis实例有故障,那么哨兵负责发送消息作为报警通知给管理员
(3)故障转移:如果master node挂掉了,会自动转移到slave node上
(4)配置中心:如果故障转移发生了,通知client客户端新的master地址
2.Redis哨兵的高可用
原理:当主节点出现故障时,由Redis Sentinel自动完成故障发现和转移,并通知应用方,实现高可用性。
- 哨兵机制建立了多个哨兵节点(进程),共同监控数据节点的运行状况。
- 同时哨兵节点之间也互相通信,交换对主从节点的监控状况。
- 每隔1秒每个哨兵会向整个集群:Master主服务器+Slave从服务器+其他Sentinel(哨兵)进程,发送一次ping命令做一次心跳检测。
部署
主机
1. 安装 参考:https://blog.csdn.net/zhuchunyan_aijia/article/details/78476151
2. 修改配置文件 vi /usr/local/redis/etc/redis.conf 主机: 168上
#1、redis默认不是以线程守护的方式运行的,如需要调整至线程守护的方式,请把
daemonize no => daemonize yes
#2、把默认端口6379改为其他
port 6379 => port 9500
#3、bind会限制能够访问redis的地址,默认(127.0.0.1)是指本地才能访问。如果要放开redis,如要搭建redis集群的话,要把bind注释掉;同时要把protected-mode从yes改为no
#bind 127.0.0.1
protected-mode yes => protected-mode no
#4、把PID文件名改成跟修改后的PORT一致
pidfile /var/run/redis_9500.pid
#5、设定日志文件路径
logfile "/var/run/redis/redis.log"
#6. 指定本地数据库存放目录
dir ./
#修改dir ./为绝对路径,
#默认的话redis-server启动时会在当前目录生成或读取dump.rdb
#所以如果在根目录下执行redis-server /etc/redis.conf的话,
#读取的是根目录下的dump.rdb,为了使redis-server可在任意目录下执行
#所以此处将dir改为绝对路径
dir /usr/local/redis
#7. 修改appendonly为yes
#指定是否在每次更新操作后进行日志记录,
#Redis在默认情况下是异步的把数据写入磁盘,
#如果不开启,可能会在断电时导致一段时间内的数据丢失。
#因为 redis本身同步数据文件是按上面save条件来同步的,
#所以有的数据会在一段时间内只存在于内存中。默认为no
appendonly yes
#8. 设置Redis连接密码,如果配置了连接密码,客户端在连接Redis时需要通过AUTH <password>命令提供密码,默认关闭
requirepass foobared
# 如果设置了密码:主从都要有requirepass 和 masterauth。因为哨兵模式下,主服务器会变成从服务器。
masterauth foobared
#9. redis默认有db0~db15之多,配置db
databases 16
3. 修改配置文件 vi /usr/local/redis/etc/redis.conf 主机: 181,129上
配置与168上一样,增加
#因为这里是以 192.168.31.168 这台作为主库,因此只需要修改 181 和 129 这两台从库的以下配置项(只需要修改两个从 redis 实例)
# 这里请注意,5.0 版本之前是使用 slaveof,5.0 版本之后的配置使用 replicaof,但是因为向下兼容的原则,就算你在 5.0 的版本中使用 slaveof 也不会有问题,但一般建议有新的就用新的吧,否则某天如果突然不支持旧的 slaveof 就 GG 了。
replicaof 192.168.31.168 9500
修改:
port 6379 => port 9501 和 9502 其实3台机器部署,端口可以一样
4. 启动服务,进入 3台redis机器中执行
redis-server redis.conf
检查是否启动成功:命令:ps -ef | grep redis
5、查看主从关系是否配置成功,执行命令:
bin/redis-cli -p 9500
auth 密码
info replication
[root@centos7a src]# ./redis-cli -h 192.168.31.168 -p 9500
192.168.31.168:9500> info replication
Replication
role:master
connected_slaves:2
slave0:ip=192.168.31.181,port=9501,state=online,offset=2235966,lag=1
slave1:ip=192.168.31.129,port=9502,state=online,offset=2235966,lag=1
master_replid:1df20ecc0df92307ef811e9bd81cc09e131725c7
master_replid2:0000000000000000000000000000000000000000
masterreploffset:2236538
........
[root@mimy-centos7b src]# ./redis-cli -h 192.168.31.181 -p 9501
192.168.31.181:9501> info replication
Replication
role:slave
master_host:192.168.31.168
master_port:9500
masterlinkstatus:up
masterlastio_seconds_ago:0
mastersyncin_progress:0
slavereploffset:2317523
........
[root@localhost src]# ./redis-cli -h 192.168.31.129 -p 9502
192.168.31.129:9502> info replication
Replication
role:slave
master_host:192.168.31.168
master_port:9500
masterlinkstatus:up
masterlastio_seconds_ago:1
mastersyncin_progress:0
slavereploffset:2336225
........
6、//主从复制配置好以后,再配置哨兵模式 修改每个 sentinel.conf
port 26379
# 是否后台运行 设置成后台运行
daemonize yes
# 运行时的pid文件
pidfile /var/run/redis-sentinel.pid
# sentinel日志文件
logfile "/var/log/sentinel.log"
# 工作目录
dir /tmp
# 这里定义主库的IP和端口,还有最后的2表示要达到2台sentinel认同才认为主库已经挂掉(即客观失效),后面科普
sentinel monitor mymaster 192.168.31.168 9500 2
# 主库在30000毫秒(即30秒)内没有反应就认为主库挂掉(即主观失效)
sentinel down-after-milliseconds mymaster 30000
# 若新主库当选后,允许最大可以同时从新主库同步数据的从库数
sentinel parallel-syncs mymaster 1
# 若在指定时间(即180000毫秒,即180秒)内没有实现故障转移,则会自动再发起一次
sentinel failover-timeout mymaster 180000
sentinel deny-scripts-reconfig yes
//如果设置了密码,这块是要写的
sentinel auth-pass mymaster 密码
7. 启动3台redis-sentinel
bin/redis-sentinel sentinel27269.conf
bin/redis-sentinel sentinel27270.conf
bin/redis-sentinel sentinel27271.conf
检查是否启动成功:命令:ps -ef | grep redis
查看哨兵信息:
/redis-cli -h 192.168.31.168 -p 26379
info sentinel
8. 启动顺序
使用以下命令启动 Redis 和 Sentinel,具体顺序为:Redis(主)-> Redis(从)->Redis(从)->Sentinel(1)->Sentinel(2)->Sentinel(3)
9. 验证数据同步
#1、一开始三台机都是同步的,没有数据的;
192.168.31.168:9500> KEYS *
(empty list or set)
192.168.31.181:9501> keys *
(empty list or set)
192.168.31.129:9502> keys *
(empty list or set)
#2、在主库插入(KEY1,CHAOS MONKEY)
192.168.31.168:9500> SET KEY1 'CHAOS MONKEY'
OK
#3、查询另外两个从库是否同步了
192.168.31.181:9501> get KEY1
"CHAOS MONKEY"
192.168.31.129:9502> GET KEY1
"CHAOS MONKEY"
从 129 这台机的日志(/var/run/redis/redis.log)看,数据正在从 168 同步到 129 的从库(截图一)。另外,相同的同步的行为也发生在从 168 到 181 的从库(截图二)。
10. 高可用验证
首先,我们通过命令“./redis-cli -h 192.168.31.168 -p 26379 info sentinel”随便从一台机看看 sentinel 的情况,目前主库是 192.168.31.168。
接着我们尝试模拟主库崩溃,先把 168 的主库停掉,然后通过 sentinel.log 日志发现主库已经从 168 换成 181。
首先,181 发现 168 下线,这是主观失效;因为我们在 sentinel.conf 中的设置了 sentinel monitor mymaster 127.0.0.1 6379 2 , 这里最后的 2 代表需要 2 个哨兵认为主库下线才算是真正下线(即客观失效)然后再进行选举;
接着,129 或者 168 的哨兵也发现 168 下线,已经达到 2 台,因此就把 168 主库设成下线(客观失效),开始选举;
接着,开始选举,最终 181 被选举成主库。
登录到 181 的 redis 上,通过 INFO REPLICATION 可以看到 181 也确实变成主库,129 变成 181 的从库
这个时候我们继续尝试一下新增 KEY,从以下结果可以看出 129 是能够正常从 181(新主库)同步数据
192.168.31.181:9501> keys *
1) "KEY1"
2) "KEY2"
3) "KEY3"
192.168.31.129:9502> keys *
1) "KEY3"
2) "KEY2"
3) "KEY1"
192.168.31.181:9501> set KEY4 BUTTERFLY
OK
192.168.31.181:9501> keys *
1) "KEY1"
2) "KEY4"
3) "KEY2"
4) "KEY3"
192.168.31.129:9502> keys *
1) "KEY3"
2) "KEY2"
3) "KEY4"
4) "KEY1"