1. 关闭3个哨兵
编辑关闭哨兵脚本(以主节点160为例)
vi sentinel-stop.sh
i
关闭脚本内容
cd /usr/local/src/redis160/bin
redis-cli -a root -p 26379 shutdown
Esc
:wq
sudo chmod -R 777 sentinel-stop.sh
./sentinel-stop.sh
ps -ef | grep redis
163和164分别编辑好脚本文件,并执行
2. 清空之前Redis服务的测试数据
3. 关闭3个Redis服务
4. 配置6台服务的的redis.conf
cp /usr/local/src/redis-6.0.16/redis.conf /usr/local/src/redis160/bin/
y
vi /usr/local/src/redis160/bin/redis.conf
:set nu
68 === 绑定的IP注释掉,表示任何主机都可以连接该Redis
87 === 保护模式(yes-需要790行设置密码;no-不需要密码)
protected-mode yes
91 === 端口号,不修改(或修改成自己喜欢的端口)
port 6379
224 === 后台运行,no修改成yes
daemonize yes
260 === 配置日志文件位置
logfile "/usr/local/src/redis160/redis_6379.log"
395 === 主库密码,都设置root
masterauth root
790 === 保护模式关闭,注释该行; 保护模式打开, requirepass 密码
requirepass root
860 === 最大内存
maxmemory 512MB
891 === 内存淘汰策略
maxmemory-policy volatile-lru
1227 === 集群配置开启,放开注释
cluster-enabled yes
1235 === 集群配置文件,放开注释
cluster-config-file nodes-6379.conf
1241 === 集群超时时间(15秒),放开注释
cluster-node-timeout 15000
可选操作 : 如果想开启多线程,最好参照官方建议修改
默认情况下,多线程是被禁用的,我们建议仅在拥有至少4个或更多内核的机器中开启它,并至少保留一个备用内核
开启8个以上的线程不太可能有多大帮助.我们再次建议仅当你的机器真的出现性能问题时才开启多线程,因为Redis实例会消耗相当多的
CPU时间,否则使用多线程没有任何意义
所以举个例子,如果你的机器有4个核心,建议用2到3个线程,如果有8个核心,建议用6个线程.为了能够启用多线程,请使用下面的配置指令
1021 === 多线程数,注释放开
io-threads 数字
1030 === 开启多线程,注释放开
io-threads-do-reads yes
Esc
:wq
touch /usr/local/src/redis160/redis_6379.log
firewall-cmd --query-port=6379/tcp
firewall-cmd --zone=public --add-port=6379/tcp --permanent
firewall-cmd --reload
开启集群总线端口,当前redis端口+10000
firewall-cmd --query-port=16379/tcp
firewall-cmd --zone=public --add-port=16379/tcp --permanent
firewall-cmd --reload
根据上面的配置依次配置另外5台服务
…
5. 启动6台redis服务
./redis-start.sh
6. 编写开启集群脚本,并执行
vi cluster-start.sh
i
脚本内容
cd /usr/local/src/redis160/bin/
redis-cli -a root --cluster create 192.168.109.160:6379 192.168.109.161:6379 192.168.109.162:6379 192.168.109.163:6379 192.168.109.164:6379 192.168.109.165:6379 --cluster-replicas 1
Esc
:wq
./cluster-start.sh
7. 错误分析
7.1 某一台redis服务数据没有清空
解决方案 : 先清理数据,之后再执行脚本
7.2 slots分布不正确
解决方法 : 通过fix修复
/usr/local/src/redis160/bin/redis-cli -a root --cluster fix 192.168.109.160:6379
修复完成后,通过check来检查
/usr/local/src/redis160/bin/redis-cli -a root --cluster check 192.168.109.160:6379
8. 进入redis客户端,查看主从关系
/usr/local/src/redis160/bin/redis-cli -a root
info replication
164主库,160从库
161主库,165从库
162主库,163从库
9. 测试高可用
本来设想160服务作为主库,但目前是从库,对164服务执行宕机操作,切换主库为160
debug segfault
exit
9.1 角色已经切换,只是没有从库
9.2 启动164服务,顺利挂载
10. 测试分区容错
10.1 完成 第 3 篇 : SpringBoot整合Redis-3主3从
10.2 通过redis客户端,查看数据的存储情况
11. 集群宕机测试
11.1 准备依次宕机 160,164,测试
11.2 重启160和164,之后同时宕机161,162,测试
上面两种情况都可以通过重启redis服务恢复正常