redis哨兵部署

本文详细介绍了如何配置和部署Redis哨兵系统以实现集群的高可用性。主要内容包括哨兵的主要功能,如监控、故障通知、故障转移和配置中心,以及哨兵节点间的通信和心跳检测机制。在实际操作中,通过修改Redis和Sentinel的配置文件,设置主从关系和哨兵监控,确保在主节点故障时能自动切换到从节点。最后,通过数据同步和高可用性验证,展示了哨兵系统的故障恢复能力。
摘要由CSDN通过智能技术生成

哨兵(sentinal)

哨兵是Redis集群架构中非常重要的一个组件,哨兵的出现主要是解决了主从复制出现故障时需要人为干预的问题。

1.Redis哨兵主要功能

(1)集群监控:负责监控Redis master和slave进程是否正常工作

(2)消息通知:如果某个Redis实例有故障,那么哨兵负责发送消息作为报警通知给管理员

(3)故障转移:如果master node挂掉了,会自动转移到slave node上

(4)配置中心:如果故障转移发生了,通知client客户端新的master地址

2.Redis哨兵的高可用

原理:当主节点出现故障时,由Redis Sentinel自动完成故障发现和转移,并通知应用方,实现高可用性。

  1. 哨兵机制建立了多个哨兵节点(进程),共同监控数据节点的运行状况。
  2. 同时哨兵节点之间也互相通信,交换对主从节点的监控状况。
  3. 每隔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"

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值