【Redis】の 主从复制 | 哨兵机制 | 集群cluster
1、主从复制
主从复制,是指将一台Redis服务器的数据,复制到其他的Redis服务器。前者称为主节点(Master),后者称为从节点(Slave);数据的复制是单向的,只能由主节点到从节点。
1.1 主从复制的作用
- 数据备份 主从复制实现了数据的热备份,是持久化之外的一种数据备份方式。
- 故障恢复 当主节点出现问题时,可以由从节点提供服务,实现快速的故障恢复;实际上是一种服务的冗余。
- 负载均衡 在主从复制的基础上,配合读写分离,可以由主节点提供写服务,由从节点提供读服务(即写Redis数据时应用连接主节点,读Redis数据时应用连接从节点),分担服务器负载;尤其是在写少读多的场景下,通过多个从节点分担读负载,可以大大提高Redis服务器的并发量。
- 高可用基础 除了上述作用以外,主从复制还是哨兵和集群能够实施的基础,因此说主从复制是Redis高可用的基础
1.2 主从复制实验
实验环境:
主 7-2 192.168.125.120
从 7-3 192.168.125.130
从 7-5 192.168.125.150
前期准备:
1、关闭防火墙
2、查看配置文件中,密码是否开启
7-2:主
sed -i 's/^bind 127.0.0.1/bind 0.0.0.0/' /apps/redis/etc/redis.conf
sed -i 's#^logfile .*#logfile /apps/redis/log/redis.log#' /apps/redis/etc/redis.conf
sed -i 's#^dir .*#dir /apps/redis/data/#' /apps/redis/etc/redis.conf
sed -i 's#^pidfile .*#pidfile /apps/redis/run/#' /apps/redis/etc/redis.conf
7-3:从1
[root@7-3 ~]# vim /apps/redis/etc/redis.conf
286 replicaof 192.168.125.120 6379 //在从节点上添加主的信息
[root@7-3 ~]# systemctl restart redis
[root@7-3 ~]# redis-cli
127.0.0.1:6379> info replication
# Replication
role:slave //从
master_host:192.168.125.120
master_port:6379
master_link_status:up //开启
7-5:从2
[root@7-5 ~]# vim /apps/redis/etc/redis.conf
286 replicaof 192.168.125.120 6379 //在从节点上添加主的信息
[root@7-5 ~]# systemctl restart redis
如果主节点有密码:
以上面为基础,从节点的设置中,还需要加入下面的命令:
7-3:从
masterauth 123456 //指明主节点的密码
7-5:从
masterauth 123456
验证:主从是否一致
7-2:主
127.0.0.1:6379> set name wxy
OK
127.0.0.1:6379> get name
"wxy"
7-3:从1
127.0.0.1:6379> get name
"wxy"
7-5:从2
127.0.0.1:6379> get name
"wxy"
2、级联+主从复制
前期准备:
1、不加密码
2、关闭防火墙
systemctl stop firewalld
setenforce 0
7-3:级联
[root@7-3 ~]# vim /apps/redis/etc/redis.conf
286 replicaof 192.168.125.120 6379 //主指向7-2
[root@7-3 ~]# systemctl restart redis
7-5:从
[root@7-5 ~]# vim /apps/redis/etc/redis.conf
286 replicaof 192.168.125.130 6379 //主指向7-3级联
[root@7-5 ~]# systemctl restart redis
3、哨兵 sentinel
哨兵模式的端口号是:26379
3.1 哨兵的原理和功能
主从切换技术的方法是: 当服务器宕机后,需要手动一台从机切换为主机,这需要人工干预,不仅费时费力而且还会造成一段时间内服务不可用。为了解决主从复制的缺点,就有了哨兵机制。
哨兵的核心功能: 在主从复制的基础上,哨兵引入了主节点的自动故障转移。
3.2 哨兵模式的作用
- 监控: 哨兵会不断地检查主节点和从节点、还有哨兵节点是否运作正常。
- 自动故障转移: 当主节点不能正常工作时,哨兵会开始自动故障转移操作,它会将失效主节点的其中一个从节点升级为新的主节点,并让其它从节点改为复制新的主节点。主从角色自动切换
- 通知(提醒): 哨兵可以将故障转移的结果发送给客户端。
哨兵结构由两部分组成,哨兵节点和数据节点:
- 哨兵节点:哨兵系统由一个或多个哨兵节点组成,哨兵节点是特殊的redis节点,不存储数据。
- 数据节点:主节点和从节点都是数据节点。
3.3 哨兵的原理
3.3.1 故障转移机制:
- 由哨兵节点定期监控发现主节点是否出现了故障 每个哨兵节点每隔1秒会向主节点、从节点及其它哨兵节点发送一次ping命令做一次心跳检测。如果主节点在一定时间范围内不回复或者是回复一个错误消息,那么这个哨兵就会认为这个主节点主观下线了(单方面的)。当超过半数哨兵节点认为该主节点主观下线了,这样就客观下线了。
- 当主节点出现故障,此时哨兵节点会通过Raft算法(选举算法)实现选举机制共同选举出一个哨兵节点为leader,来负责处理主节点的故障转移和通知。所以整个运行哨兵的集群的数量不得少于3个节点。
-
由leader哨兵节点执行故障转移,过程如下:
- 将某一个从节点升级为新的主节点,让其它从节点指向新的主节点,写vip会漂移到新的master;
- 若原主节点恢复也变成从节点,并指向新的主节点;
- 通知客户端主节点已经更换。
需要特别注意的是,客观下线是主节点才有的概念;如果从节点和哨兵节点发生故障,被哨兵主观下线后,不会再有后续的客观下线和故障转移操作。
3.3.2 主节点的选举:
- 过滤掉不健康的(已下线的),没有回复哨兵 ping 响应的从节点。
- 选择配置文件中从节点优先级配置最高的。(replica-priority,默认值为100)
- 选择复制偏移量最大,也就是复制最完整的从节点。
3.4 哨兵实验
实验环境:
主 7-2 192.168.125.120
从 7-3 192.168.125.130
从 7-5 192.168.125.150
三台服务器上既装sentinel,又装redis
实验前提:
1、安装redis
2、实现主从复制的效果
3、加上密码
4、关闭防火墙
实验步骤:
`加上密码:`
vim /apps/redis/etc/redis.conf //三台电脑都要执行此操作
masterauth '123456'
requirepass '123456' //加到最后一行就行
##注意:先开主 再开从
systemctl restart redis //重启的话,先重启主设备!!!
`编译安装如何获取sentinel.conf文件`
[root@7-2 ~]# cd /data/redis-5.0.7/
[root@7-2 redis-5.0.7]# cp /data/redis-5.0.7/sentinel.conf /apps/redis/etc/
[root@7-2 redis-5.0.7]# cd /apps/redis/etc
[root@7-2 etc]# chown redis.redis sentinel.conf
`修改哨兵配置文件`
[root@centos7 ~]# vim /etc/sentinel.conf
bind 0.0.0.0 #16行,监听端口,用于远程连接
port 26379 #21行,不用修改,默认的端口号
daemonize no #26行,默认是no,不用修改,如果是systemd 启动模式,修改后则会启动不了
pidfile "/apps/redis/run/sentinel.pid" #31行,指定pid文件
logfile "/apps/redis/log/sentinel.log" #36行,指定日志文件存放路径
dir "/tmp" #65行,工作目录不用修改,指定数据库存放路径
sentinel monitor mymaster 192.168.125.100 6379 2 #84行,指定该哨兵节点监控192.168.125.100:6379这个主机点,主节点名称是mymaster,最后的2的含义与主节点的故障判定有关:至少需要2个哨兵节点同意,才能判定主节点故障并进行故障转移。因为两个才是客观odown,只有一个属于主观sdown
sentinel auth-pass mymaster 123456 #87行,mymaster主节点名称,主节点密码123456
sentinel down-after-milliseconds mymaster 3000 #114行,判定主节点宕机的时间周期,默认是3000毫秒(3秒,1秒=1000毫秒)
sentinel parallel-syncs mymaster 1 #122行,从节点个数,发生故障转移后,可以同时向新master同步数据的slave的数量
sentinel failover-timeout mymaster 18000 #147行,所有从节点,指向新的主节点 所需的超时时间为18秒
`用下面的命令,查看修改文件内容:`
grep -vE "^#|^$" sentinel.conf
`远程拷贝:`
7-2:
scp /apps/redis/etc/sentinel.conf 192.168.125.130:/apps/redis/etc/
scp /apps/redis/etc/sentinel.conf 192.168.125.150:/apps/redis/etc/
`修改权限`
7-3:
chown -R redis.redis /apps/redis/etc/sentinel.conf
7-5:
chown -R redis.redis /apps/redis/etc/sentinel.conf
`准备service 文件:`
[root@localhost etc]#cat >> /lib/systemd/system/redis-sentinel.service <<eof
[Unit]
Description=Redis Sentinel
After=network.target
[Service]
ExecStart=/apps/redis/bin/redis-sentinel /apps/redis/etc/sentinel.conf --supervised systemd
ExecStop=/bin/kill -s QUIT $MAINPID
User=redis
Group=redis
RuntimeDirectory=redis
RuntimeDirectoryMode=0755
[Install]
WantedBy=multi-user.target
eof
`注意:先开主、再开从`
[root@localhost etc]# systemctl daemon-reload
[root@localhost etc]# systemctl start redis-sentinel.service
[root@localhost etc]# systemctl status redis-sentinel.service //查看是否running
[root@7-2 etc]# ss -natp | grep 26379
`先查看日志:`
tail -f /apps/redis/log/sentinel.log
`模仿主节点故障`
[root@7-2 etc]# systemctl stop redis
`观察哨兵机制选举过程:`
13663:X 10 Jul 2024 20:07:07.402 # +sdown master mymaster 192.168.125.120 6379 //sdown 主观认为下线
13663:X 10 Jul 2024 20:07:07.469 # +odown master mymaster 192.168.125.120 6379 #quorum 2/2 //odown 客观
root@7-5 etc]# redis-cli -a 123456
127.0.0.1:6379> info replication
# Replication
role:master //7-5成为了主
connected_slaves:1
slave0:ip=192.168.125.130,port=6379,state=online,offset=262040,lag=0
master_replid:48125d7fe47392e0401343a2d16d7f0c23ff89d6
master_replid2:95b7880cd9ff402d9a96cbfce65744a0ba8e0764
master_repl_offset:262040
second_repl_offset:198102
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:262040
127.0.0.1:6379>
小拓展:7-2原主 如果恢复,刚开始���还是主,但是过几秒钟后,就会变成从。
4、redis 集群 cluster
集群端口号是:16379
从节点 默认就是read_only只读
4.1 集群模式的数据分片
- Redis集群引入了哈希槽的概念
- Redis集群有16384个哈希槽(编号0-16383)
- 集群的每组节点负责一部分哈希槽
- 每个Key通过CRC16算法校验后对16384取余来决定放置哪个哈希槽,通过这个值,去找到对应的插槽所对应的节点,然后直接自动跳转到这个对应的节点上进行存取操作
4.2 命令行配置
命令 | 解释 |
---|---|
info replication | 查看主从状态 |
repliacaof | 添加主从配置 例子: repliacaof 192.168.91.100 6379(也可以用此命令,进行临时设置) |
CONFIG SET masterauth 123456 | 设置密码(临时修改) |
replicaof no one | 取消 主从配置 |
4.3 集群实验
在一台主机设备上,采用多实例方法,建立6个端口号,一主一从为1组,共分为3组
前期准备:
1、安装redis
2、关闭redis
3、关闭防火墙
systemctl stop firewalld
setenforce 0
- 新建集群文件夹
[root@localhost ~]#cd /apps/redis/
[root@localhost redis]#mkdir -p redis-cluster/redis600{1..6}
- 准备for循环
for i in {1..6}
do
cp /data/redis-5.0.7/redis.conf /apps/redis/redis-cluster/redis600$i
cp /data/redis-5.0.7/src/redis-cli /data/redis-5.0.7/src/redis-server /apps/redis/redis-cluster/redis600$i
done
- 开启群集功能
#其他5个文件夹的配置文件以此类推修改,注意6个端口都要不一样。
[root@localhost redis6001]#cd /apps/redis/redis-cluster/redis6001/
vim redis.conf
bind 0.0.0.0 #69行,监听所有网卡
protected-mode no #88行,修改,关闭保护模式
port 6001 #92行,修改,redis监听端口,
daemonize yes #136行,开启守护进程,以独立进程启动 如果是 systemd 启动不需要修改
cluster-enabled yes #832行,取消注释,开启群集功能
cluster-config-file nodes-6001.conf #840行,取消注释,并修改对应端口名称,群集名称文件设置
cluster-node-timeout 15000 #846行,取消注释群集超时时间设置
appendonly yes #700行,修改,开启AOF持久化
- 将改好的配置,复制到另外5个端口
[root@localhost redis6001]# cd /apps/redis/redis-cluster/redis6001
#先切换目录
#复制配置文件
for i in {2..6}
do
\cp -f ./redis.conf /apps/redis/redis-cluster/redis600${i}
done
[root@7-1 redis6001]# cd ..
[root@7-1 redis-cluster]# sed -i 's/6001/6002/' /apps/redis/redis-cluster/redis6002/redis.conf
[root@7-1 redis-cluster]# sed -i 's/6001/6003/' /apps/redis/redis-cluster/redis6003/redis.conf
[root@7-1 redis-cluster]# sed -i 's/6001/6004/' /apps/redis/redis-cluster/redis6004/redis.conf
[root@7-1 redis-cluster]# sed -i 's/6001/6005/' /apps/redis/redis-cluster/redis6005/redis.conf
[root@7-1 redis-cluster]# sed -i 's/6001/6006/' /apps/redis/redis-cluster/redis6006/redis.conf
- 启动redis节点
[root@localhost redis6001]#systemctl stop redis
# 先停止之前的服务
[root@localhost redis6001]#ss -natp |grep 6379
[root@localhost redis6001]#cd /apps/redis/redis-cluster/redis6001
# 切换目录
[root@localhost redis6001]#redis-server redis.conf
# 启动
#脚本去启动
for d in {1..6}
do
cd /apps/redis/redis-cluster/redis600$d
redis-server redis.conf
done
- 查看是否成功启动
[root@localhost redis6006]# ss -natp |grep "\b600[1-6]\b"
LISTEN 0 128 *:6001 *:* users:(("redis-server",pid=11022,fd=6))
LISTEN 0 128 *:6002 *:* users:(("redis-server",pid=11024,fd=6))
LISTEN 0 128 *:6003 *:* users:(("redis-server",pid=11026,fd=6))
LISTEN 0 128 *:6004 *:* users:(("redis-server",pid=11037,fd=6))
LISTEN 0 128 *:6005 *:* users:(("redis-server",pid=11039,fd=6))
LISTEN 0 128 *:6006 *:* users:(("redis-server",pid=11041,fd=6))
`修改权限:`
chown -R redis.redis /apps/redis/
- 启动群集
[root@localhost redis6006]# redis-cli --cluster create 127.0.0.1:6001 127.0.0.1:6002 127.0.0.1:6003 127.0.0.1:6004 127.0.0.1:6005 127.0.0.1:6006 --cluster-replicas 1
#六个实例分为三组,每组一主一从,前面的做主节点,后面的做从节点。下面交互的时候 需要输入 yes 才可以创建。
--replicas 1 表示每个主节点有1个从节点。
- 验证集群
[root@7-1 redis]# redis-cli -p 6001 -c //加-c参数,节点之间就可以互相跳转
127.0.0.1:6001> set name wt
-> Redirected to slot [5798] located at 127.0.0.1:6002
OK
127.0.0.1:6002> get name //从6001端口直接跳转到6002端口
"wt"
127.0.0.1:6002> cluster slots //查看节点的哈希槽编号范围
1) 1) (integer) 10923
2) (integer) 16383
3) 1) "127.0.0.1"
2) (integer) 6003
3) "5c120c05deaffb02dd7dc914aa56ffa039a8dcd8"
4) 1) "127.0.0.1"
2) (integer) 6004
3) "0781ab6e14c3b18abced8cfbdd8b2474e5ba1ed1"
2) 1) (integer) 0
2) (integer) 5460
3) 1) "127.0.0.1"
2) (integer) 6001
3) "5250574dae59d65838ee248b6a010b9ef3392d5b"
4) 1) "127.0.0.1"
2) (integer) 6005
3) "2517427e4eb23d0e1d7a9cdbeb108263d4e38fa5"
3) 1) (integer) 5461
2) (integer) 10922
3) 1) "127.0.0.1"
2) (integer) 6002
3) "b3841be73901a9af8e69e2b66292f3bb0e1c24d2"
4) 1) "127.0.0.1"
2) (integer) 6006
3) "5460b430767c41b46bade061042b37ab1c9945f1"
5、总结
什么是主从复制、哨兵模式以及集群模式?
-
主从复制: 主从复制是高可用Redis的基础,哨兵和集群都是在主从复制基础上实现高可用的。主从复制主要实现了数据的多机备份,以及对于读操作的负载均衡和简单的故障恢复。
缺陷:故障恢复无法自动化:写操作无法负载均衡:存储能力受到单机的限制。
-
哨兵模式: 在主从复制的基础上,哨兵实现了自动化的故障恢复
缺陷:写操作无法负载均衡;存储能力受到单机的限制:哨兵无法对从节点进行自动故障转移,在读写分离场景下,从节点故障会导致读服务不可用,需要对从节点做额外的监控、切换操作。
- 集群: 通过集群,Redis解决了写操作无法负载均衡,以及存储能力受到单机限制的问题,实现了较为完善的高可用方案。
转载自:https://juejin.cn/post/7389912762045480960