Redis集群哨兵模式搭建
(1)前言
在日常开发中,保证redis的高可用的稳定性是非常必要的,工作中最常见的redis集群模式就是M-S-S一主两从模式,使之满足主从复制、读写分离。通常M-S-S模式的集群大致可分为一主二仆、薪火相传、反客为主、哨兵等,其中哨兵模式可靠性和稳定性最好,所以在大多公司的redis集群都采取哨兵模式。
(2)简介
哨兵模式(Redis-Sentinel)是官方推荐的高可用解决方案,当redis在做master-slave的高可用方案时,假如master宕机了,redis本身(以及其很多客户端)都没有实现自动进行主备切换,而redis-sentinel本身也是独立运行的进程,可以部署在其他与redis集群可通讯的机器中监控redis集群。
(3)特点
1、不时地监控redis是否按照预期良好地运行;
2、如果发现某个redis节点运行出现状况,能够通知另外一个进程(例如它的客户端);
3、能够进行自动切换。当一个master节点不可用时,能够选举出master的多个slave(如果有超过一个slave的话)中的一个来作为新的master,其它的slave节点会将它所追随的master的地址改为被提升为master的slave的新地址。
4、哨兵为客户端提供服务发现,客户端链接哨兵,哨兵提供当前master的地址然后提供服务,如果出现切换,也就是master挂了,哨兵会提供客户端一个新地址。
(4)伪集群搭建
LZ电脑配置受限,不能一次开三个虚拟机,所以只能在一台机器上模拟,伪集群实在就是其多个redis进程,保证其端口不互相冲突即可,这里我们就以端口7001、8001、9001为例
先看一看LZ的redis安装目录(/usr/local/redis)
2017-11-03_162535.png
4.1 redis安装
略
4.2 创建配置文件
我们在/user/local/redis下创建一个集群配置相关的目录lvfangRedis,并复制redis.conf配置文件7001.conf、8001.conf、9001.conf
2017-11-03_165108.png4.3 修改配置
分别修改7001.conf、8001.conf、9001.conf配置中的
7001.conf
bind 0.0.0.0
daemonize yes
pidfile /var/run/redis_7001.pid
logfile "7001.log"
dbfilename 7001dump.rdb
其他默认... ...
8001.conf
bind 0.0.0.0
daemonize yes
pidfile /var/run/redis_8001.pid
logfile "8001.log"
dbfilename 8001dump.rdb
其他默认... ...
9001.conf
bind 0.0.0.0
daemonize yes
pidfile /var/run/redis_9001.pid
logfile "9001.log"
dbfilename 9001dump.rdb
其他默认... ...
4.4 添加哨兵配置
创建文件 sentinel.conf ,并添加内容: sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 7001 1
#创建哨兵配置文件
touch sentinel.conf
#写入内容
sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 7001 1
2017-11-03_180451.png
4.5 启动各个节点redis进程
#启动redis后台进程
[root@hadoop bin]# ./redis-server ../lvfangRedis/7001.conf
[root@hadoop bin]# ./redis-server ../lvfangRedis/8001.conf
[root@hadoop bin]# ./redis-server ../lvfangRedis/9001.conf
#启动redis终端进程
[root@hadoop bin]# ./redis-cli -p 7001
[root@hadoop bin]# ./redis-cli -p 8001
[root@hadoop bin]# ./redis-cli -p 9001
#查看各个终端集群角色信息
info replication
1.png
2.png
3.png
4.png
我们可以发现,现在每一个节点的redis进程的角色的是master角色,接下来我们应该执行哨兵配置调整角色
4.6 启动各个节点redis进程
启动哨兵配置
./redis-sentinel ../lvfangRedis/sentinel.conf
2017-11-03_184606.png
4.7 分配角色
将8001和9001节点的redis均设置为7001的子节点
#设置8001
127.0.0.1:8001> slaveof 127.0.0.1 7001
OK
127.0.0.1:8001>
#设置9001
127.0.0.1:9001> slaveof 127.0.0.1 7001
OK
127.0.0.1:9001>
设置完成后 ,我们会发现在启动sentinel哨兵配置文件的终端窗口分别打印节点入队信息
2782:X 03 Nov 19:39:43.305 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
2782:X 03 Nov 19:39:43.314 # Sentinel ID is f59f5f574aee944c983ce19b8b2d0162d2c476e4
2782:X 03 Nov 19:39:43.314 # +monitor master ARF 127.0.0.1 7001 quorum 1
2782:X 03 Nov 19:44:04.274 * +slave slave 127.0.0.1:8001 127.0.0.1 8001 @ ARF 127.0.0.1 7001
2782:X 03 Nov 19:44:24.373 * +slave slave 127.0.0.1:9001 127.0.0.1 9001 @ ARF 127.0.0.1 7001
2017-11-03_185011.png
4.8 查看角色
在三个终端分别键入 info replication查看对应节点所在集群的角色,这时候我们发现8001和9001的角色已经变味slave,而master则还是7001.
7001日志信息
127.0.0.1:7001> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=8001,state=online,offset=33031,lag=0
slave1:ip=127.0.0.1,port=9001,state=online,offset=33031,lag=1
master_repl_offset:33031
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:33030
127.0.0.1:7001>
8001日志信息
127.0.0.1:8001> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:7001
master_link_status:up
master_last_io_seconds_ago:2
master_sync_in_progress:0
slave_repl_offset:28055
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:8001>
9001日志信息
127.0.0.1:9001> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:7001
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:28979
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:9001>
2017-11-03_185733.png
4.9 测试主从复制 读写分离
在7001主节点上写,看看是否可以在8001和9001上读取
分别在8001和9001上写,看看有没有写的权限
2017-11-03_190121.png测试ok,过
4.10 测试高可用
模拟master节点突然down机,看看是否会选举出新的master节点进行集群工作
shutdown 7001看看哨兵日志,并查看8001和9001的角色
2017-11-03_190440.png
哨兵日志
2782:X 03 Nov 19:39:43.305 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
2782:X 03 Nov 19:39:43.314 # Sentinel ID is f59f5f574aee944c983ce19b8b2d0162d2c476e4
2782:X 03 Nov 19:39:43.314 # +monitor master ARF 127.0.0.1 7001 quorum 1
2782:X 03 Nov 19:44:04.274 * +slave slave 127.0.0.1:8001 127.0.0.1 8001 @ ARF 127.0.0.1 7001
2782:X 03 Nov 19:44:24.373 * +slave slave 127.0.0.1:9001 127.0.0.1 9001 @ ARF 127.0.0.1 7001
2782:X 03 Nov 20:03:16.408 # +sdown master ARF 127.0.0.1 7001
2782:X 03 Nov 20:03:16.409 # +odown master ARF 127.0.0.1 7001 #quorum 1/1
2782:X 03 Nov 20:03:16.409 # +new-epoch 1
2782:X 03 Nov 20:03:16.409 # +try-failover master ARF 127.0.0.1 7001
2782:X 03 Nov 20:03:16.411 # +vote-for-leader f59f5f574aee944c983ce19b8b2d0162d2c476e4 1
2782:X 03 Nov 20:03:16.411 # +elected-leader master ARF 127.0.0.1 7001
2782:X 03 Nov 20:03:16.411 # +failover-state-select-slave master ARF 127.0.0.1 7001
2782:X 03 Nov 20:03:16.511 # +selected-slave slave 127.0.0.1:9001 127.0.0.1 9001 @ ARF 127.0.0.1 7001
2782:X 03 Nov 20:03:16.511 * +failover-state-send-slaveof-noone slave 127.0.0.1:9001 127.0.0.1 9001 @ ARF 127.0.0.1 7001
2782:X 03 Nov 20:03:16.569 * +failover-state-wait-promotion slave 127.0.0.1:9001 127.0.0.1 9001 @ ARF 127.0.0.1 7001
2782:X 03 Nov 20:03:17.137 # +promoted-slave slave 127.0.0.1:9001 127.0.0.1 9001 @ ARF 127.0.0.1 7001
2782:X 03 Nov 20:03:17.137 # +failover-state-reconf-slaves master ARF 127.0.0.1 7001
2782:X 03 Nov 20:03:17.199 * +slave-reconf-sent slave 127.0.0.1:8001 127.0.0.1 8001 @ ARF 127.0.0.1 7001
2782:X 03 Nov 20:03:17.663 * +slave-reconf-inprog slave 127.0.0.1:8001 127.0.0.1 8001 @ ARF 127.0.0.1 7001
2782:X 03 Nov 20:03:17.663 * +slave-reconf-done slave 127.0.0.1:8001 127.0.0.1 8001 @ ARF 127.0.0.1 7001
2782:X 03 Nov 20:03:17.734 # +failover-end master ARF 127.0.0.1 7001
2782:X 03 Nov 20:03:17.734 # +switch-master ARF 127.0.0.1 7001 127.0.0.1 9001
2782:X 03 Nov 20:03:17.734 * +slave slave 127.0.0.1:8001 127.0.0.1 8001 @ ARF 127.0.0.1 9001
2782:X 03 Nov 20:03:17.734 * +slave slave 127.0.0.1:7001 127.0.0.1 7001 @ ARF 127.0.0.1 9001
2782:X 03 Nov 20:03:47.799 # +sdown slave 127.0.0.1:7001 127.0.0.1 7001 @ ARF 127.0.0.1 9001
2017-11-03_190624.png
8001角色 9001角色
######8001#######
127.0.0.1:8001> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:9001
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:13630
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:8001>
######9001#######
127.0.0.1:9001> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=8001,state=online,offset=14540,lag=0
master_repl_offset:14540
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:14539
127.0.0.1:9001>
2017-11-03_190956.png
我们可以看到当前集群的节点只剩8001和9001,而且9001充当的master角色,并且主从复制 读写分离正常。
4.11 测试down机节点再次进入
我们此时在此加入7001节点,再看主从角色会不会有所改变
7001日志
[root@hadoop bin]# ./redis-server ../lvfangRedis/7001.conf
[root@hadoop bin]# ./redis-cli -p 7001
127.0.0.1:7001> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:9001
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:35278
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:7001>
此时我们发现7001再次加入后扮演slave角色,而9001确定了master角色,并且在哨兵日志中也有加入日志
2017-11-03_191452.png以上就是我们redis集群的哨兵模式环境搭建