Redis-哨兵（sentinel）

Redis-哨兵（sentinel）

说明

吹哨人巡查监控后台master主机是否故障，如果故障了则根据投票数自动将某一个从库转换为新主库，继续对外服务。

配置哨兵

前置条件：

开启三台虚拟机。

架构：每台虚拟机各启动一个redis服务以及各1个redis哨兵

首先配置1主2从的redis关系

修改redis.conf配置文件，将虚拟机中第一台机器的redis端口命名为6379；

第二台机器的redis端口命名为6380；

第三台机器的redis端口命名为6381。

 6379--master主机的配置文件

 6380--slave的配置文件

 6381--slave的配置文件

 ESC---: ---wq保存退出

分别启动三台redis-server

启动6479master

redis-server redis-6379.conf # 启动master主机

 

启动6380slave

redis-server redis-6380.conf # 启动6380slave主机

 

启动6381slave

redis-server redis-6381.conf # 启动6381slave主机

 

测试主从复制

# 6379添加一个key
127.0.0.1:6379> set k1 helloword
OK
127.0.0.1:6379> get k1
"helloword"

# 6380进行get操作
127.0.0.1:6380> get k1
"helloword"

# 6381进行get操作
127.0.0.1:6381> get k1
"helloword"

 

验证结果：主从复制，配置正常。

配置哨兵

将各虚拟机的/opt/redis-7.0.0/目录下的sentinel.conf配置文件复制到/myredis/目录下

分别做修改：

第一台虚拟机中的哨兵端口号命名为26379：

bind 0.0.0.0
daemonize yes
protected-mode no
port 26379
logfile "/myredis/sentinel26379.log"
pidfile /var/run/redis-sentinel26379.pid
dir /myredis
sentinel monitor mymaster 192.168.111.169 6379 2
sentinel auth-pass mymaster 111111

 

第二台虚拟机的哨兵端口号命名为26380:

bind 0.0.0.0
daemonize yes
protected-mode no
port 26380
logfile "/myredis/sentinel26380.log"
pidfile /var/run/redis-sentinel26380.pid
dir "/myredis"
sentinel monitor mymaster 192.168.111.169 6379 2
sentinel auth-pass mymaster 111111

第三台虚拟机的哨兵端口号命名为26381:

bind 0.0.0.0
daemonize yes
protected-mode no
port 26381
logfile "/myredis/sentinel26381.log"
pidfile /var/run/redis-sentinel26381.pid
dir "/myredis"
sentinel monitor mymaster 192.168.111.169 6379 2
sentinel auth-pass mymaster 111111

 

启动哨兵

# 第一台虚拟机中执行命令
[root@192 myredis]# redis-sentinel sentinel26379.conf --sentinel

# 第二台虚拟机中执行命令
[root@192 myredis]# redis-sentinel sentinel26380.conf --sentinel

# 第三台虚拟机中执行命令
[root@192 myredis]# redis-sentinel sentinel26380.conf --sentinel

案例演示

shutdown master主机，模拟6379挂了，看看会发生什么

127.0.0.1:6379> shutdown now
not connected> quit

 

谁成为新的master？

登录6380，执行info replication命令

127.0.0.1:6380> info replication
# Replication
role:master ###########6380成为新的master
connected_slaves:1
slave0:ip=192.168.1.13,port=6381,state=online,offset=648478,lag=0
master_failover_state:no-failover
master_replid:a1d36222666d130cf5464b3d529dfa3e456b4996
master_replid2:d1e6b81d26acc4c26b624bfc8d666222b5fd1a3b
master_repl_offset:648617
second_repl_offset:642979
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:719
repl_backlog_histlen:647899

 

登录6381，执行info replication命令

127.0.0.1:6381> info replication
# Replication
role:slave######6381还是slave
master_host:192.168.1.12
master_port:6380 ###新的master已经成为6380
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_read_repl_offset:658445
slave_repl_offset:658445
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:a1d36222666d130cf5464b3d529dfa3e456b4996
master_replid2:d1e6b81d26acc4c26b624bfc8d666222b5fd1a3b
master_repl_offset:658445
second_repl_offset:642979
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:578475
repl_backlog_histlen:79971

原来的master6379重新启动之后，是什么角色？

[root@192 myredis]# redis-server redis-6379.conf  # 启动6379
[root@192 myredis]# redis-cli -a 111111 -p 6379 # 登录

127.0.0.1:6379> info replication # 查看
# Replication
role:slave ###slave角色
master_host:192.168.1.12
master_port:6380
master_link_status:up
master_last_io_seconds_ago:2
master_sync_in_progress:0
slave_read_repl_offset:673217
slave_repl_offset:673217
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:a1d36222666d130cf5464b3d529dfa3e456b4996
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:673217
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:671791
repl_backlog_histlen:1427

 

哨兵的运行流程和选举原理

当一个主从配置中的master失效之后，sentinel可以选举出一个新的master用于自动接替原master的工作，主从配置中的其他redis服务器自动指向新的master同步数据般建议sentinel采取奇数台，防止某一台sentinel无法连接到master导致误切换

名词：

sDown：主观下线

单个哨兵自己主观上检测到关于master的状态，从哨兵的角度来看，如果发送PING心跳后，在一定时间内没有收到合法的回复，就达到了sDown的条件。

 

oDown：客观下线

odown需要一定数量的sentinel，多个哨兵达成一致意见才能认为一个master客观上已经宕掉。

流程：

1. 哨兵认定为客观下线
2. 需要选举出领导者哨兵
3. 领导者开始推动故障切换流程并选出一个新的master

选举领导者哨兵的原理

Raft算法：先到先得（哨兵A向B发送成为领导者的申请，如果B没有同意过其他哨兵，则会同意A成为领导者）

 

注意事项

1. 哨兵节点的数量应该是多个，哨兵本身应该集群，保证高可用。
2. 哨兵节点的数量应该是奇数
3. 各个哨兵节点的硬件配置应一致
4. 如果哨兵节点部署在Docker容器里面，尤其需要注意端口的映射。
5. 哨兵集群+主从复制，并不能保证数据的零丢失。-------故有了redis集群