redis主从复制，redis哨兵，redis集群

d1906989080

于 2024-08-23 17:17:44 发布

阅读量976

点赞数 23

文章标签： bootstrap 前端 html

本文链接：https://blog.csdn.net/d1906989080/article/details/141470731

版权

Redis高级

一、Redis持久化

Redis数据保存在内存中，为避免关闭程序后数据的丢失，就需要将数据保存到磁盘文件上。

1.1 持久化策略

持久化策略包含

AOF：默认每秒对数据进行持久化
RDB：按条件触发持久化操作，满足任意一个条件

1.2 配置持久化

可以在redis.conf中配置持久化如：RDB

1) 900 1            900秒中修改至少1个键
2) 300 10           300秒中修改至少10个键
3) 60 10000         60秒中修改至少10000个键

启动AOF的配置

appendonly yes   开启AOF  
appendfsync everysec  每秒保存
    - no 不进行保存，由操作系统实现刷新，快
    - aways 每个键修改后都会保存，慢，安全
    - everysec 每秒保存一次

我们如何选择RDB和AOF呢？

视业务场景而定：

允许少量数据丢失，性能要求高，选择RDB
只允许很少数据丢失，选择AOF
几乎不允许数据丢失，选择RDB + AOF

二、Redis淘汰策略

Redis中的数据太多可能导致内存溢出，Redis会根据情况淘汰一些数据。 Redis的内存上限：64位系统，上限就是内存上限；32位系统，最大是4G

2.1 配置内存

配置最大内存：

max-memory  配置0就是无上限（默认）

2.2 淘汰策略

配置淘汰策略

maxmemory-policy

策略类型：

- noevication               不淘汰（默认）
- volatile-ttl              在将过期键中淘汰存活时间短的键
- volatile-lfu              在将过期的键中淘汰使用频率较少的键
- volatile-lru              在将过期的键中淘汰很久前使用的键
- volatile-random           在将过期键中随机淘汰
- allkeys-random            在所有键中随机淘汰
- allkeys-lfu               在所有键中淘汰使用频率较少的键
- allkeys-lru               在所有键中使用LRU算法淘汰比较少使用的键 （推荐）

三、Redis的主从同步

1.1 主从同步介绍

虽然Redis可以实现单机的数据持久化，但无论是RDB也好或者AOF也好，都解决不了单点宕机问题，即一旦单台redis服务器本身出现系统故障、硬件故障等问题后，就会直接造成数据的丢失，因此需要使用另外的技术来解决单点问题。

1.1.1 redis主从复制的特点

1） 主数据库可以进行读写操作，当读写操作导致数据变化时会自动将数据同步给从数据库
2） 从数据库一般都是只读的，并且接收主数据库同步过来的数据
3） 一个master可以拥有多个slave，但是一个slave只能对应一个master
4） slave挂了不影响其他slave的读和master的读和写，重新启动后会将数据从master同步过来
5） master挂了以后，不影响slave的读，但redis不再提供写服务，master重启后redis将重新对外提供写服务
6） master挂了以后，不会在slave节点中重新选一个master

1.2 部署redis主从同步

要求：关闭防火墙和selinux

1.2.1 IP地址的基本规划

IP地址	主机名	角色
192.168.1.100	master.com	master
192.168.1.101	slave1.com	slave1
192.168.1.102	slave2.com	slave2

1.2.2 安装redis

此部分，请参考前面第二部分的的安装部署过程

1.2.3 配置master

1）将bind的IP地址修改成0.0.0.0，表示所有人都可连接

2）开启守护进程模式

3)设置验证密码

当然，既然用到主从了，那说明对redis依赖非常高，还有几个参数需要根据服务器配置来设置

客户端最大连接数（maxclients），默认是10000，可根据需求更改

5)内存策略，如果内存足够用则不用管，如果内存不够用，建议设置最近最少使用策略（LRU）,默认是内存不够则报错

6)配置完后,启动redis

[root@master redis-4.0.9]# /usr/local/src/redis-4.0.9/src/redis-server /usr/local/src/redis-4.0.9/redis.conf 
[root@master ~]# ps -ef |grep redis
root       1464      1  0 20:13 ?        00:00:00 /usr/local/src/redis-4.0.9/src/redis-server 0.0.0.0:6379
root       1469   1441  0 20:13 pts/0    00:00:00 grep --color=auto redis
[root@master ~]#

1.2.4 配置slave

注意：

1)前3步和master的配置是一致的

2)配置所属主服务器ip和端口

3)slave1和slave2配置一致

3)配置所属主服务器的密码（再次强调，要将密码设置非常复杂，这里只是演示）

4)需要注意的是，从服务器通常是只读，所以要配置只读（默认是只读，不要更改即可）

1.2.5 启动redis

[root@master src]# ./redis-server /root/redis-6.0.16/redis.conf 

[root@slave1 src]# ./redis-server /root/redis-6.0.16/redis.conf 

[root@slave2 src]#  ./redis-server /root/redis-6.0.16/redis.conf 

注意：先启动master，再启动slave。

[root@master src]# netstat -antup|grep 6379
tcp        0      0 192.168.1.100:6379      0.0.0.0:*               LISTEN      2896/./redis-server 
[root@master src]#

1.2.6 测试

1.2.6.1 登录master服务器

[root@master src]# ./redis-cli -h 192.168.1.100
192.168.1.100:6379> auth 123456
OK
192.168.1.100:6379> set a 100
OK
192.168.1.100:6379> set b 200
OK
192.168.1.100:6379> keys *
1) "a"
2) "b"

1.2.6.2 登录从服务查看

[root@slave1 src]# ./redis-cli -h 192.168.1.101
192.168.1.101:6379> auth 123456
OK
192.168.1.101:6379> exit
[root@slave1 src]# ./redis-cli -h 192.168.1.101
192.168.1.101:6379> auth 123456
OK
192.168.1.101:6379> keys *
1) "b"
2) "a"
192.168.1.101:6379> get a 
"100"

可以看到已经设置成功了,如果有多个从服务器,也可以如此设置,可以减少从服务器读取数据的压力.

1.2.7 master查看同步情况

192.168.1.100:6379> info Replication
# Replication
role:master         #节点的角色
connected_slaves:2  #从节点个数
#state=online表示从节点在线,offset=238 从节点同步偏移量 表示从节点已经同步了多少数据量, lag=1 表示同步落后, lag=0 同步没有落后
slave0:ip=192.168.1.101,port=6379,state=online,offset=3203,lag=1
slave1:ip=192.168.1.102,port=6379,state=online,offset=3203,lag=1
#服务器的复制ID,redis每次重启ID都不一样
master_replid:0ec052d16f77fdee33f87e2071643f32cc157eb9
#第二服务器复制ID，用于故障转移后的PSYNC，用于集群等高可用之后主从节点的互换
master_replid2:0000000000000000000000000000000000000000
#master发送复制偏移量
master_repl_offset:238
#第二master服务器的发送复制偏移量
second_repl_offset:-1
#复制缓冲区状态
repl_backlog_active:1
#复制缓冲区的大小（以字节为单位）
repl_backlog_size:1073741824
#复制缓冲区的偏移量，标识当前缓冲区可用范围
repl_backlog_first_byte_offset:1
#复制缓冲区中数据的大小（以字节为单位）
repl_backlog_histlen:238

1.2.8 slave 查看同步情况

192.168.1.101:6379> info replication
# Replication
role:slave
master_host:192.168.1.100
master_port:6379
#Master的连接状态（up/down）
master_link_status:up
#最近一次主从交互之后的秒数
master_last_io_seconds_ago:1
master_sync_in_progress:0
#从服务器的同步偏移量
slave_repl_offset:3581
#从服务器的优先级
slave_priority:100
#从服务器只读
slave_read_only:1
connected_slaves:0
#主服务器的复制ID
master_replid:0ec052d16f77fdee33f87e2071643f32cc157eb9
master_replid2:0000000000000000000000000000000000000000
。。。。。


#Redis主从复制的从服务器只能读数据
192.168.1.101:6379> set c 300
(error) READONLY You can't write against a read only replica.
192.168.1.101:6379>

1.2.9 模拟master宕机

[root@master src]# ./redis-cli -h 192.168.1.100 
192.168.1.100:6379> auth 123456
OK
192.168.1.100:6379> shutdown

观察slave1的复制状态

[root@slave1 src]# ./redis-cli -h 192.168.1.101
192.168.1.101:6379> auth 123456
OK
192.168.1.101:6379> info replication
# Replication
role:slave
master_host:192.168.1.100
master_port:6379
master_link_status:down   #表示无法连接Master
master_last_io_seconds_ago:-1
master_sync_in_progress:0
slave_repl_offset:4099
master_link_down_since_seconds:16
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:0ec052d16f77fdee33f87e2071643f32cc157eb9
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:4099
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:421
repl_backlog_histlen:3679

#数据查看正常
192.168.1.101:6379> get a 
"100"

1.2.10 停止主从同步

REPLIATOF NO ONE 指令可以取消主从复制

192.168.1.101:6379> REPLICAOF no one
OK
192.168.1.101:6379>

四、哨兵模式

2.1 主从同步的缺陷

主从架构无法实现master和slave角色的自动切换，即当master出现redis服务异常、主机断电、磁盘损坏等问题导致master无法使用，而redis高可用无法实现自故障转移(将slave提升为master)，需要手动改环境配置才能切换到slave redis服务器，另外也无法横向扩展Redis服务的并行写入性能，当单台Redis服务器性能无法满足业务写入需求的时候就必须需要一种方式解决以上的两个核心问题，即：

1.   master和slave角色的无缝切换，让业务无感知从而不影响业务使用 
2.   可以横向动态扩展Redis服务器，从而实现多台服务器并行写入以实现更高并发的目的。

2.2 哨兵模式介绍

Sentinel（哨兵）是Redis 的高可用性解决方案：由一个或多个Sentinel 实例组成的Sentinel 系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器。其已经被集成在redis2.6+的版本中，Redis的哨兵模式到了2.8版本之后就稳定了下来。一般在生产环境也建议使用Redis的2.8版本的以后版本

原理：Sentinel（哨兵）通过流言协议(gossip protocols)来接收关于Master主服务器是否下线的信息，并使用投票协议(Agreement Protocols)来决定是否执行自动故障迁移，以及选择哪个Slave作为新的Master。

通过一定的vote算法，从剩下的slave从服务器节点中，选一台提升为Master服务器节点，然后自动修改相关配置，并开启故障转移（failover）。Sentinel 机制可以解决master和slave角色的自动切换问题，但单个Master 的性能瓶颈问题无法解决

2.3 哨兵的作用

哨兵在redis集群架构中是一个非常重要的组件，具有监控、通知、故障转移的功能。

监控：监控主节点和从节点是否正常运行；
通知：哨兵检测的服务器出现问题时，会向其他的哨兵发送通知，哨兵之间就相当于一个通信群，每个哨兵发现的问题都会发在这个群里。
自动故障转移：当检测到主节点宕机后，断开与宕机主节点连接的所有从节点，在从节点中选取一个作为主节点，然后将其他的从节点连接到这个最新主节点的上。并且告知客户端最新的服务器地址。

哨兵也是一台 Redis 服务器，只是不对外提供任何服务。配置哨兵时配置为单数，哨兵使用的配置文件是 sentinel.conf
哨兵集群至少要 3 个节点，来确保自己的健壮性。
redis主从 +sentinel的架构，是不会保证数据的零丢失的，它是为了保证redis集群的高可用。

2.4 哨兵监控工作流程

    哨兵有三个定时监控任务完成对各节点的发现和监控，每隔10秒, 每个哨兵 向 master和slave 发送 info命令,通过向主节点发送info，主节点返回 run_id 与从节点的信息，当有新的从节点加入时可以马上感知。每隔2秒, 每个哨兵 , 利用发布订阅的特性向redis数据节点的指定频道(sentinel:hello) 发送, 包括自己的host、ip和runid还有对这个master的监控配置。每个哨兵节点也会订阅该频道，来了解其它哨兵节点的信息及对主节点的判断，每隔1秒, 每个哨兵会向主节点，从节点及其余哨兵节点发送ping命令，做心跳检测，用于判定是否存活。

2.5 哨兵工作流程（故障转移原理）

    哨兵会一直给主节点发送 publish sentinel：hello，直到哨兵报出 sdown，若某个哨兵检测到主节点挂了，就会在哨兵群里通知。其余的哨兵接收到指令后，发送 hello 信息，检测主节点是否真的挂了 。对于一个哨兵认为主节点挂了称之为主观下线，半数哨兵认为主节点挂了称之为客官下线。一旦被认为主节点客官下线后。哨兵间会投票来竞选出一个代表

    每个哨兵-携带携带runid和自己竞选次数，参与竞选。每个哨兵都可以投票，规则一般可以通过，认为先收到谁的消息投票给谁。投票截止到任意一个哨兵的票数为总哨兵数的一半以上，这个就是选为哨兵代表。（这也是哨兵需要基数的原因）代表哨兵会发消息给所有Redis子节点

2.6 主观下线和客观下线

默认情况下，每个 Sentinel 节点会以 每秒一次 的频率对 Redis 节点和 其它 的 Sentinel 节点发送 PING 命令，并通过节点的回复来判断节点是否在线。

主观下线：
    主观下线 适用于所有 主节点 和 从节点。如果在 down-after-milliseconds 毫秒内，Sentinel 没有收到 目标节点 的有效回复，则会判定 该节点 为 主观下线。

客观下线：
    客观下线 只适用于 主节点。如果 主节点 出现故障，Sentinel 节点会通过 sentinel is-master-down-by-addr 命令，向其它 Sentinel 节点询问对该节点的 状态判断。如果超过 <quorum> 个数的节点判定 主节点 不可达，则该 Sentinel 节点会判断 主节点 为 客观下线。

2.7 哨兵模式优缺点

优点
高可用，在主节点故障时能实现故障的转移

缺点：
需要另外部署一套哨兵集群，部署麻烦、原理复杂、浪费资源，从节点作为备份节点不提供服务。
不支持读写分离，实现起来相对复杂。
只支持对主节点的故障转移，不支持对从节点的故障转移。
所有主节点和从节点都包含了 Redis 全量的数据，数据冗余，导致数据存储的数据量有限。

2.8 配置哨兵

哨兵的前提是已经实现了一个redis的主从复制的运行环境，从而实现一个一主两从基于哨兵的高可用 redis架构

2.8.1 所有主从节点的redis.conf中关健配置

bind 0.0.0.0
masterauth "123456"         #主节点的密码,
requirepass "123456"        #Redis节点密码,redis哨兵集群涉及主从切换,所有主从节点密码必须全部一致

2.8.2 搭建主从操作

主从redis搭建的方案参考之前安装部分：

#在所有主从节点执行
bind 0.0.0.0
masterauth 123456
requirepass 123456

#在所有从节点设置主节点信息
replicaof 192.168.1.100 6379

#启动Redis
[root@master src]# ./redis-server /root/redis-6.0.16/redis.conf

主节点状态

[root@master ~]# redis-cli -a 123456 info Replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.1.101,port=6379,state=online,offset=28,lag=1
slave1:ip=192.168.1.102,port=6379,state=online,offset=28,lag=1
master_replid:51c552e7a766440e4d32eca18cd00fd883fdfd1b
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:28
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:28

slave1节点状态

[root@slave1 ~ ]# redis-cli -a 123456 info Replication
# Replication
role:slave
master_host:192.168.1.100
master_port:6379
master_link_status:up
master_last_io_seconds_ago:10
master_sync_in_progress:0
slave_repl_offset:84
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:51c552e7a766440e4d32eca18cd00fd883fdfd1b
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:84
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:15
repl_backlog_histlen:70

slave2 节点状态

[root@slave2 ~ ]# redis-cli -a 123456 info Replication
# Replication
role:slave
master_host:192.168.1.100
master_port:6379
master_link_status:up
master_last_io_seconds_ago:4
master_sync_in_progress:0
slave_repl_offset:154
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:51c552e7a766440e4d32eca18cd00fd883fdfd1b
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:154
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:154

2.8.3 Sentinel 哨兵配置说明

Sentinel实际上是一个特殊的redis服务器，有些redis指令支持，但很多指令并不支持，默认监听在 26379/tcp 端口.；哨兵可以不和Redis服务器部署在一起，但一般部署在一起

Redis 哨兵配置文件：/root/redis-6.0.16/redis-sentinel.conf

#Redis 哨兵监听端口默认为 263379
port 26379
#daemonize yes 设置哨兵后台运行,默认为 no 以前台方式运行
daemonize no
#哨兵服务进程pid文件
pidfile /var/run/redis-sentinel.pid
#自定义sentinel哨兵日志文件绝对路径
logfile "/var/log/sentinel.log"
#工作目录
dir /tmp

#哨兵监控Redis主从复制集群必须配置参数
######################################################################################################
#sentinel monitor <Redis主从集群名> <主节点地址> <主节点端口> <ODOWN切换主从权重>
#指定哨兵监Redis主从集群中master服务器的地址和端口,一个哨兵服务可以监控多组Redis主从集群
#ODOWN切换主从权重：即有几个sentinel认为master down了就进行故障转移，一般此值是所有sentinel节点(一般总数是>=3的 奇数,如:3,5,7等)的一半以上的整数值，比如，总数是3，即3/2=1.5，取整为2,是master的ODOWN客观下线的依据
sentinel monitor mymaster 127.0.0.1 6379 2

#当主节点出现问题,哨兵通过ODOWN切换新的主节点,并且从节点需要指向新主节点地址,此时哨兵需要登录监控节点修改配置,因此需要登录节点
#sentinel monitor 定义主从集群中master的密码,注意: sentinel auth-pass 配置在 sentinel monitor 紧挨着的下面一行
sentinel auth-pass <master-name> <password>

#(SDOWN)哨兵主观判断mymaster集群中所有节点的主观下线的时间，单位：毫秒，建议3000
sentinel down-after-milliseconds mymaster 30000

######################################################################################################
#发生故障转移后，所有从节点需要向哨兵提升新主节点同步数据,如果从节点同时一并向新主节点同步,会造成新主机负载压力
#sentinel parallel-syncs 限制同时向新master同步数据的slave数量，数字越小总同步时间越长，但可以减轻新master的负载压力
sentinel parallel-syncs mymaster 1

#所有slaves指向新的master所需的超时时间，单位：毫秒
sentinel failover-timeout mymaster 180000

#禁止修改脚本,默认即可
sentinel deny-scripts-reconfig yes

#yum安装定义sentinel日志文件,多个logfile最后配置生效,前面logfile配置项启动Sentinel会自动删除
logfile /var/log/redis/sentinel.log

2.8.4 启动哨兵

三个哨兵服务器的配置都如下

cat > sentinel.conf << EOF
port 26379
daemonize yes
pidfile /var/run/redis-sentinel.pid
logfile /var/log/redis/sentinel.log
dir /tmp
#修改下面俩行为主机的IP
sentinel monitor mymaster 192.168.200.10 6379 2
sentinel auth-pass mymaster 123456
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
sentinel deny-scripts-reconfig yes
EOF

三台哨兵服务器都要启动

[root@master src]# ./redis-sentinel /root/redis-5.0.4/sentinel.conf

查看端口28379 是否正常开启

#master节点 
[root@master ~ ]# netstat -lnt | grep 26379
tcp        0      0 0.0.0.0:26379           0.0.0.0:*               LISTEN
tcp6       0      0 :::26379                :::*                    LISTEN

#slave1节点
[root@slave1 ~ ]# netstat -lnt | grep 26379
tcp        0      0 0.0.0.0:26379           0.0.0.0:*               LISTEN
tcp6       0      0 :::26379                :::*                    LISTEN

#slave2节点
[root@slave2 ~ ]# netstat -lnt | grep 26379
tcp        0      0 0.0.0.0:26379           0.0.0.0:*               LISTEN
tcp6       0      0 :::26379                :::*                    LISTEN

哨兵服务启动后，会在 sentinel.conf文件添加一些信息，确保主从复制集群每个节点的sentinel.conf 配置文件中的 sentinel myid ID 必须不同

#master节点
[root@master ~ ]# egrep -v '^$|^#' /root/redis-6.0.16/sentinel.conf 
port 26379
daemonize no
pidfile "/var/run/redis-sentinel.pid"
logfile "/var/log/redis/sentinel.log"
dir "/tmp"
sentinel myid 23b408383c33a833b52b36fc7d9a4247811faddb      #每个主从节点集群必须不同
sentinel deny-scripts-reconfig yes
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel auth-pass mymaster 123456
sentinel config-epoch mymaster 0
sentinel leader-epoch mymaster 0
protected-mode no
supervised systemd
sentinel known-replica mymaster 192.168.1.102 6379
sentinel known-replica mymaster 192.168.1.101 6379
sentinel known-sentinel mymaster 192.168.1.101 26379 4dfea0efa7ed1aeb5107ca79241b8848f8231112
sentinel known-sentinel mymaster 192.168.1.102 26379 c9ce54d10d70fdde1ee8cb2c78f3f66787a06d94
sentinel current-epoch 0

#slave1节点
[root@slave1 ~ ]# egrep -v '^$|^#' /root/redis-6.0.16/sentinel.conf 
port 26379
daemonize no
pidfile "/var/run/redis-sentinel.pid"
logfile "/var/log/redis/sentinel.log"
dir "/tmp"
sentinel myid c9ce54d10d70fdde1ee8cb2c78f3f66787a06d94
sentinel deny-scripts-reconfig yes
sentinel monitor mymaster 192.168.1.100 6379 2
sentinel auth-pass mymaster 123456
sentinel config-epoch mymaster 0
sentinel leader-epoch mymaster 0
protected-mode no
supervised systemd
sentinel known-replica mymaster 192.168.1.102 6379
sentinel known-replica mymaster 192.168.1.101 6379
sentinel known-sentinel mymaster 192.168.1.100 26379 23b408383c33a833b52b36fc7d9a4247811faddb
sentinel known-sentinel mymaster 192.168.1.101 26379 4dfea0efa7ed1aeb5107ca79241b8848f8231112
sentinel current-epoch 0

#slave2节点
[root@slave2 ~ ]# egrep -v '^$|^#' /root/redis-6.0.16/sentinel.conf 
port 26379
daemonize no
pidfile "/var/run/redis-sentinel.pid"
logfile "/var/log/redis/sentinel.log"
dir "/tmp"
sentinel myid 4dfea0efa7ed1aeb5107ca79241b8848f8231112
sentinel deny-scripts-reconfig yes
sentinel monitor mymaster 192.168.1.100 6379 2
sentinel auth-pass mymaster 123456
sentinel config-epoch mymaster 0
sentinel leader-epoch mymaster 0
protected-mode no
supervised systemd
sentinel known-replica mymaster 192.168.1.102 6379
sentinel known-replica mymaster 192.168.1.101 6379
sentinel known-sentinel mymaster 192.168.1.100 26379 23b408383c33a833b52b36fc7d9a4247811faddb
sentinel known-sentinel mymaster 192.168.1.102 26379 c9ce54d10d70fdde1ee8cb2c78f3f66787a06d94

2.8.5 查看哨兵日志

[root@master src]#  tail /var/log/redis/sentinel.log
3258:X 02 Jun 2023 09:50:54.460 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
3258:X 02 Jun 2023 09:50:54.460 # Redis version=6.0.16, bits=64, commit=00000000, modified=0, pid=3258, just started
3258:X 02 Jun 2023 09:50:54.460 # Configuration loaded
3258:X 02 Jun 2023 09:50:54.461 * Increased maximum number of open files to 10032 (it was originally set to 1024).
3258:X 02 Jun 2023 09:50:54.461 * Running mode=sentinel, port=26379.
3258:X 02 Jun 2023 09:50:54.461 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
3258:X 02 Jun 2023 09:50:54.463 # Sentinel ID is a0105bb4ac4cfc34b688b1c33c12724221ff1753
3258:X 02 Jun 2023 09:50:54.463 # +monitor master master 192.168.1.100 6379 quorum 2
3258:X 02 Jun 2023 09:50:54.464 * +slave slave 192.168.1.101:6379 192.168.1.101 6379 @ master 192.168.1.100 6379
3258:X 02 Jun 2023 09:50:54.466 * +slave slave 192.168.1.102:6379 192.168.1.102 6379 @ master 192.168.1.100 6379

2.8.6 查看sentinel状态

在sentinel状态中尤其是最后一行，涉及到masterIP是多少，有几个slave，有几个sentinels，必须是符合全部服务器数量

[root@master src]# ./redis-cli -h 192.168.1.100 -a 123456 -p 26379
192.168.1.100:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=master,status=ok,address=192.168.1.100:6379,slaves=2,sentinels=1

#name=<主从集群名>,status 集群状态, address 集群中主节点, slaves 从节点个数, sentinel 监控集群的哨兵个数

2.8.7 停止Redis Master测试故障转移

模拟master节点故障宕机

[root@master src]# killall redis-server

查看哨兵故障转移时sentinel的信息：

[root@slave1 src]# redis-cli -h 192.168.101.131 -p 26379 info Sentinel 
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.1.101:6379,slaves=2,sentinels=2

哨兵主观发现master主节点故障信息

[root@slave1 redis-6.0.16]# tail /var/log/redis/sentinel.log 
1921:X 02 Jun 2023 10:11:16.495 # +failover-state-reconf-slaves master mymaster 192.168.1.101 6379
1921:X 02 Jun 2023 10:11:16.547 * +slave-reconf-sent slave 192.168.1.100:6379 192.168.1.100 6379 @ mymaster 192.168.1.101 6379
1921:X 02 Jun 2023 10:11:17.537 * +slave-reconf-inprog slave 192.168.1.100:6379 192.168.1.100 6379 @ mymaster 192.168.1.101 6379
1921:X 02 Jun 2023 10:11:17.592 # -odown master mymaster 192.168.1.101 6379
1921:X 02 Jun 2023 10:14:16.536 # +failover-end-for-timeout master mymaster 192.168.1.101 6379
1921:X 02 Jun 2023 10:14:16.536 # +failover-end master mymaster 192.168.1.101 6379
1921:X 02 Jun 2023 10:14:16.536 * +slave-reconf-sent-be slave 192.168.1.100:6379 192.168.1.100 6379 @ mymaster 192.168.1.101 6379
1921:X 02 Jun 2023 10:14:16.536 # +switch-master mymaster 192.168.1.101 6379 192.168.1.102 6379
1921:X 02 Jun 2023 10:14:16.536 * +slave slave 192.168.1.100:6379 192.168.1.100 6379 @ mymaster 192.168.1.102 6379
1921:X 02 Jun 2023 10:14:16.536 * +slave slave 192.168.1.101:6379 192.168.1.101 6379 @ mymaster 192.168.1.102 6379

2.8.8 故障转移后的redis配置文件会被自动修改

故障转移后新主节点master sentinel 哨兵配置文件的sentinel monitor IP 自动修改

[root@slave1 redis-6.0.16]# cat sentinel.conf 
port 26379
daemonize yes
pidfile "/var/run/redis-sentinel.pid"
logfile "/var/log/redis/sentinel.log"
dir "/tmp"
#修改下面俩行
sentinel myid 5f973491babbd749ce9e99add0994c468fd93cb0
sentinel deny-scripts-reconfig yes
sentinel monitor mymaster 192.168.1.102 6379 2   ##自动修改成新的master的ip
sentinel auth-pass mymaster 123456
sentinel config-epoch mymaster 1
sentinel leader-epoch mymaster 1
# Generated by CONFIG REWRITE
protected-mode no
user default on nopass ~* +@all
sentinel known-replica mymaster 192.168.1.102 6379
sentinel known-replica mymaster 192.168.1.100 6379
sentinel known-sentinel mymaster 192.168.1.102 26379 e247a440a58531f2f83bd951d5927c39ba5186a9
sentinel current-epoch 1

故障转移后slave节点修改 redis.conf 文件指向新主节点

[root@slave2 ~ ]# egrep -v '^$|^#'/root/redis-6.0.16/redis.conf | grep replicaof
replicaof 192.168.1.102 6379

2.8.9 恢复故障的原master重新加入redis集群

恢复故障的原master重新加入redis集群，作为slave从节点

[root@master ~ ]# systemctl restart redis.service
[root@master ~ ]# egrep -v '^$|^#'/root/redis-6.0.16/redis.conf | grep replicaof
replicaof 192.168.1.102 6379

[root@master ~ ]# redis-cli  -a 123456 info Replication
# Replication
role:slave
master_host:192.168.1.102
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:1117130
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:c53545e42f6bed993e0434d2c8b9ced52c507ff2

2.8.10 切换主从

手动切换主从服务集群的master节点

sentinel failover <masterName>

范例：

[root@slave2 src]# ./redis-cli -p 26379 -h 192.168.1.102
192.168.1.102:26379> sentinel failover mymaster
OK
[root@slave2 src]# ./redis-cli -p 26379 -h 192.168.1.102
192.168.1.102:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=sdown,address=192.168.1.102:6379,slaves=2,sentinels=2

在master查看切换日志

[root@master src]# tailf /var/log/redis/sentinel.log 
3258:X 02 Jun 2023 09:50:54.460 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
3258:X 02 Jun 2023 09:50:54.460 # Redis version=6.0.16, bits=64, commit=00000000, modified=0, pid=3258, just started
3258:X 02 Jun 2023 09:50:54.460 # Configuration loaded
3258:X 02 Jun 2023 09:50:54.461 * Increased maximum number of open files to 10032 (it was originally set to 1024).
3258:X 02 Jun 2023 09:50:54.461 * Running mode=sentinel, port=26379.
3258:X 02 Jun 2023 09:50:54.461 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
3258:X 02 Jun 2023 09:50:54.463 # Sentinel ID is a0105bb4ac4cfc34b688b1c33c12724221ff1753
3258:X 02 Jun 2023 09:50:54.463 # +monitor master master 192.168.1.100 6379 quorum 2
3258:X 02 Jun 2023 09:50:54.464 * +slave slave 192.168.1.101:6379 192.168.1.101 6379 @ master 192.168.1.100 6379
3258:X 02 Jun 2023 09:50:54.466 * +slave slave 192.168.1.102:6379 192.168.1.102 6379 @ master 192.168.1.100 6379
3258:X 02 Jun 2023 09:59:50.827 # +sdown master master 192.168.1.100 6379
3520:X 02 Jun 2023 10:09:46.535 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
3520:X 02 Jun 2023 10:09:46.535 # Redis version=6.0.16, bits=64, commit=00000000, modified=0, pid=3520, just started
3520:X 02 Jun 2023 10:09:46.535 # Configuration loaded
3520:X 02 Jun 2023 10:09:46.543 * Increased maximum number of open files to 10032 (it was originally set to 1024).
3520:X 02 Jun 2023 10:09:46.543 # Could not create server TCP listening socket *:26379: bind: Address already in use
3258:X 02 Jun 2023 10:10:17.996 * +reboot master master 192.168.1.100 6379
3258:X 02 Jun 2023 10:10:18.052 # -sdown master master 192.168.1.100 6379
3258:X 02 Jun 2023 10:10:23.923 * +convert-to-slave slave 192.168.1.101:6379 192.168.1.101 6379 @ master 192.168.1.100 6379
3258:X 02 Jun 2023 10:10:24.937 * +fix-slave-config slave 192.168.1.102:6379 192.168.1.102 6379 @ master 192.168.1.100 6379
3258:X 02 Jun 2023 10:12:08.270 # +sdown master master 192.168.1.100 6379
3258:X 02 Jun 2023 10:19:21.776 # Executing user requested FAILOVER of 'master'
3258:X 02 Jun 2023 10:19:21.776 # +new-epoch 1
3258:X 02 Jun 2023 10:19:21.776 # +try-failover master master 192.168.1.100 6379
3258:X 02 Jun 2023 10:19:21.791 # +vote-for-leader a0105bb4ac4cfc34b688b1c33c12724221ff1753 1
3258:X 02 Jun 2023 10:19:21.791 # +elected-leader master master 192.168.1.100 6379
3258:X 02 Jun 2023 10:19:21.791 # +failover-state-select-slave master master 192.168.1.100 6379
3258:X 02 Jun 2023 10:19:21.844 # +selected-slave slave 192.168.1.101:6379 192.168.1.101 6379 @ master 192.168.1.100 6379
3258:X 02 Jun 2023 10:19:21.844 * +failover-state-send-slaveof-noone slave 192.168.1.101:6379 192.168.1.101 6379 @ master 192.168.1.100 6379
3258:X 02 Jun 2023 10:19:21.897 * +failover-state-wait-promotion slave 192.168.1.101:6379 192.168.1.101 6379 @ master 192.168.1.100 6379
3258:X 02 Jun 2023 10:19:22.150 # +promoted-slave slave 192.168.1.101:6379 192.168.1.101 6379 @ master 192.168.1.100 6379
3258:X 02 Jun 2023 10:19:22.150 # +failover-state-reconf-slaves master master 192.168.1.100 6379
3258:X 02 Jun 2023 10:19:22.237 * +slave-reconf-sent slave 192.168.1.102:6379 192.168.1.102 6379 @ master 192.168.1.100 6379
3258:X 02 Jun 2023 10:19:22.843 * +slave-reconf-inprog slave 192.168.1.102:6379 192.168.1.102 6379 @ master 192.168.1.100 6379
3258:X 02 Jun 2023 10:19:23.896 * +slave-reconf-done slave 192.168.1.102:6379 192.168.1.102 6379 @ master 192.168.1.100 6379
3258:X 02 Jun 2023 10:19:23.968 # +failover-end master master 192.168.1.100 6379
3258:X 02 Jun 2023 10:19:23.968 # +switch-master master 192.168.1.100 6379 192.168.1.101 6379
3258:X 02 Jun 2023 10:19:23.970 * +slave slave 192.168.1.102:6379 192.168.1.102 6379 @ master 192.168.1.101 6379
3258:X 02 Jun 2023 10:19:23.970 * +slave slave 192.168.1.100:6379 192.168.1.100 6379 @ master 192.168.1.101 6379
3258:X 02 Jun 2023 10:21:14.565 * +convert-to-slave slave 192.168.1.102:6379 192.168.1.102 6379 @ master 192.168.1.101 6379
3258:X 02 Jun 2023 10:24:03.917 * +fix-slave-config slave 192.168.1.100:6379 192.168.1.100 6379 @ master 192.168.1.101 6379        ##Master已经切换到了192.168.1.101

在Redis的主配置文件 redis.conf中，可以设置哨兵提升新master节点优先级

[root@master ~ ]# grep 'replica-priority'/root/redis-6.0.16/redis.conf
replica-priority 100        #数值越低,提升新master节点优先级越高
#设置
[root@master src]# redis-cli -h 192.168.1.100 -p 6379 -a 123456 config set slave-priority 100
#查看优先级
[root@master src]# redis-cli -h 192.168.1.100 -p 6379 -a 123456 config get slave-priority