redis在我们工作中是非常重要的,由于网络的不可靠性,随时会有故障发生,所以使用单机的redis存在机器宕机的危险,此时我们可以给redis做一个主从复制,用一个从服务器作为备份机器。
本次搭建是在centOS7上面进行搭建,我们首先上传一个redis5.0+的安装包到服务器上,解压之后,由于本次暂时是模拟搭建,所以只在一台服务器上进行搭建,
首先将redis5.0bin目录下的redis.conf文件复制一份为redis6380.conf
cp redis.conf redis6380.conf
然后去修改redis6380.conf里面的配置
#修改端口
port 6380
pidfile /var/run/redis_6380.pid
logfile "6380.log"
#创建一个存放日志log的路径
dir /usr/local/redis‐5.0/data/6380
3、配置主从复制
replicaof 192.168.56.102 6379 # 从本机6379的redis实例复制数据
replica‐read‐only yes
同时要把主配置文件和6380的配置文件的bind进行修改 注释掉 bind 127.0.0.1
#bind 127.0.0.1
启动两个redis实例
#启动redis主服务
./redis-server redis.conf
#启动redis从服务
./redis-server redis6380.conf
接下来启动查看一下redis线程实例
ps -ef|grep redis
两个线程启动完毕。
接着我们去主线程里面插入一个数据,然后在从线程里面也可以看到了。
[root@localhost bin]# ./redis-cli -p 6379
127.0.0.1:6379> set helloredis hello
OK
127.0.0.1:6379>
[root@localhost bin]# ./redis-cli -p 6380
127.0.0.1:6380> get helloredis
"hello"
127.0.0.1:6380>
上面 我们成功的搭建了如何配置一个主从的redis实例,但是如果主服务器宕机了,从服务器是无法提供写服务的,所以相当于无法对外提供服务,为了解决高可用的问题,这里我们需要对主从的架构配置redis的哨兵,能够实现redis实例的选举。
按照上面的方式重新搭建一个6381的实例,实现一主两从的架构。
但是当在创建第二个实例的时候遇到了一个问题。第二个从节点无法被主节点绑定
然后最后找到原因就是因为上面把bind隐藏的原因 所以后面去主节点里面把配置修改为开放全部端口
bind 0.0.0.0
问题解决了。
接下来搭建哨兵
复制一份sentinel.conf文件
cp sentinel.conf /usr/local/redis/config/sentinel‐26379.conf
修改里面的配置信息
port 26379
daemonize yes
pidfile "/var/run/redis‐sentinel‐26379.pid"
logfile "26379.log"
dir "/usr/local/redis/data"
# sentinel monitor <master‐name> <ip> <redis‐port> <quorum>
# quorum是一个数字,指明当有多少个sentinel认为一个master失效时(值一般为:sentinel总数/2 +1)
#,master才算真正失效
sentinel monitor mymaster 192.168.56.102 6379 2
接下来启动哨兵进程
./redis-sentinel ../config/sentinel‐26379.conf
查看进程
看一下我的bin目录
看一下redis目录 可能和有的小伙伴不太一样
按照上面的方式再配置26380和26381另外两个哨兵吧
然后我们进入一个sentinel里面去查看一下Info信息
./redis-cli -p 26381
info
发现出了一个问题 明明配置了三个sentinels 怎么上面显示sentinels=1呢? 后来发现在配置文件中有sentinel myid这一行 当时复制的时候也复制过来了,我们把这行注释掉
修改了文件之后分别进入26380和26381执行shutdown命令 关闭然后再从新启动redis-sentinels实例。
启动后,进入sentinel实例里面就可以看到有三个sentinel了
redis的哨兵架构这里也已经搭建完毕了。