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客观上已经宕掉。
流程：
- 哨兵认定为客观下线
- 需要选举出领导者哨兵
- 领导者开始推动故障切换流程并选出一个新的master
选举领导者哨兵的原理
Raft算法：先到先得（哨兵A向B发送成为领导者的申请，如果B没有同意过其他哨兵，则会同意A成为领导者）
注意事项
- 哨兵节点的数量应该是多个，哨兵本身应该集群，保证高可用。
- 哨兵节点的数量应该是奇数
- 各个哨兵节点的硬件配置应一致
- 如果哨兵节点部署在Docker容器里面，尤其需要注意端口的映射。
- 哨兵集群+主从复制，并不能保证数据的零丢失。-------故有了redis集群
标签：Redis,redis,哨兵,6379,repl,master,sentinel From： https://www.cnblogs.com/mingbo-1/p/17992341