Redis之-哨兵模式原理

master服务器异常down机后,两个原有的slave1,slave2服务器接管服务,如slave1变成新的master服务器,slave2变成slave1的从库。

配置文件主要参数讲解:

sentinel monitor mymaster 127.0.0.1 6379 1 几个哨兵发现down才认为真正的down

sentinel down-after-milliseconds mymaster 30000 多少毫秒后连接不到master认为断开

sentinel parallel-syncs mymaster 1 同时把几台master指到新的master机器。

sentinel failover-timeout mymaster 180000 多长时间失败

启动哨兵
[[email protected] redis]# ./bin/redis-server ./sentinel.conf --sentinel
17400:X 28 Jun 17:17:32.853 # Not listening to IPv6: unsupproted
.
_.-__ ‘‘-._ <br/>_.- .. ‘‘-. Redis 3.2.13 (00000000/0) 64 bit
.-.-```. ```\/ _.,_ ‘‘-._ <br/>( ‘ , .-` | `, ) Running in sentinel mode<br/>|`-._`-...-` __...-.-.|‘` .-‘| Port: 26379
| -._. / .-‘ | PID: 17400
-._-. `-./ .-‘ .-‘
|`-.
-._-..-‘ .-‘.-‘|
| -._-. .-‘.-‘ | http://redis.io
`-.
-._-.
.-‘.-‘ .-‘
|-._-._ -.__.-‘ _.-‘_.-‘| <br/>|-.`-. .-‘.-‘ |
-._-._-.__.-‘_.-‘ _.-‘ <br/>-._ -.__.-‘ _.-‘ <br/>-. .-‘
`-.__.-‘

17400:X 28 Jun 17:17:32.854 # Sentinel ID is b81b851b02fec76bcfc7144b0a675fdedecf7188
17400:X 28 Jun 17:17:32.854 # +monitor master mymaster 127.0.0.1 6379 quorum 1
17400:X 28 Jun 17:17:32.854 +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
17400:X 28 Jun 17:17:32.855
+slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379

测试将master down,查看哨兵是否有故障转移
[[email protected] ~]# cd /usr/local/redis/
[[email protected] redis]# ./bin/redis-cli
127.0.0.1:6379> shutdown
not connected>

日志打印出了一些枚举的过程,关键字switch为master机

17400:X 28 Jun 17:19:03.363 # +sdown master mymaster 127.0.0.1 6379
17400:X 28 Jun 17:19:03.363 # +odown master mymaster 127.0.0.1 6379 #quorum 1/1
17400:X 28 Jun 17:19:03.363 # +new-epoch 1
17400:X 28 Jun 17:19:03.363 # +try-failover master mymaster 127.0.0.1 6379
17400:X 28 Jun 17:19:03.364 # +vote-for-leader b81b851b02fec76bcfc7144b0a675fdedecf7188 1
17400:X 28 Jun 17:19:03.364 # +elected-leader master mymaster 127.0.0.1 6379
17400:X 28 Jun 17:19:03.364 # +failover-state-select-slave master mymaster 127.0.0.1 6379
17400:X 28 Jun 17:19:03.464 # +selected-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
17400:X 28 Jun 17:19:03.464 +failover-state-send-slaveof-noone slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
17400:X 28 Jun 17:19:03.564
+failover-state-wait-promotion slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
17400:X 28 Jun 17:19:03.917 # +promoted-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
17400:X 28 Jun 17:19:03.917 # +failover-state-reconf-slaves master mymaster 127.0.0.1 6379
17400:X 28 Jun 17:19:04.006 +slave-reconf-sent slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
17400:X 28 Jun 17:19:04.982
+slave-reconf-inprog slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
17400:X 28 Jun 17:19:04.982 +slave-reconf-done slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
17400:X 28 Jun 17:19:05.064 # +failover-end master mymaster 127.0.0.1 6379
17400:X 28 Jun 17:19:05.064 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6380
17400:X 28 Jun 17:19:05.064
+slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380
17400:X 28 Jun 17:19:05.064 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380
17400:X 28 Jun 17:19:35.080 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380

同时登陆到6380从库,查看是否现在为master主节点
127.0.0.1:6380> info replication

role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=22858,lag=0
master_repl_offset:22858
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:22857
127.0.0.1:6380>

127.0.0.1:6381> info replication

role:slave
master_host:127.0.0.1
master_port:6380
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:35773
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

有时候主库down了,从库切换为master不是顺序晋升,如master挂了后,6381为主库了。其实是有个参数控制,在redis配置文件中,不在哨兵配置文件。
slave-priority 100 该数字越小。优先级越高。

原文地址:https://blog.51cto.com/yangjunfeng/2415069

时间: 2024-08-04 00:58:07

Redis之-哨兵模式原理的相关文章

Redis 之 哨兵模式

一.哨兵模式的概念 哨兵模式是一种特殊的模式,首先Redis提供了哨兵的命令,哨兵是一个独立的进程,作为进程,它会独立运行.其原理是哨兵通过发送命令,等待Redis服务器响应,从而监控运行的多个Redis实例. 二.实验环境 三.安装redis服务 1.指定外部安装源wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-6.repo2.安装redisyum -y install redis 四.配置maste

redis主从+哨兵模式

主从模式配置分为手动和配置文件两种方式进行配置,我现在有192.168.238.128(CentOS1).192.168.238.131(CentOS3).192.168.238.132(CentOS4)几台机器,只是配置文件的配置方式是降手动配置的命令放在配置文件中而已,本质是一致的.下面将对配置文件方式进行配置,我所述的案例,是基于我自己的另一篇博文<Redis的安装.服务配置>之上: 1.我将CentOS4作为主数据库,其他 模拟为从数据库 2.将CentOS1目录切换到/etc/red

Redis sentinel 哨兵模式集群方案配置

第一个方案是创建 redis cluster,第二种方案就是用哨兵模式来进行主从替换以及故障恢复.兵模式集群方案配置 一.sentinel介绍 Sentinel作用: 1):Master状态检测 2):如果Master异常,则会进行Master-Slave切换,将其中一个Slave作为Master,将之前的Master作为Slave 3):Master-Slave切换后,master_redis.conf.slave_redis.conf和sentinel.conf的内容都会发生改变,即mast

学习记录03 --- 重新配置redis的哨兵模式

查阅多方资料后,才发现昨天写的配置哨兵模式开启是错的,尴尬... 今天重新来配置一下,当然为了避免出现问题,先理清下思路,整理好信息 哨兵模式监控的节点最少三个,昨天监控了2个是不够的,所以我又再一次的拷贝了一份redis.conf 服务器类型 是否主服务器 IP地址 端口号 Redis 是 192.168.200.128 6379 Redis 否 192.168.200.128 6380 Redis 否 192.168.200.128 6381 Sentinel - 192.168.200.1

redis的哨兵模式(redis有密码)

环境搭建: 前言: 小编使用的redis的版本号是5.0.5,可能会略有不同,例如redis.conf配置文件中,没有slaveof这一项配置 虚拟机一定要关闭掉防火墙 本次使用7006作为master,7007,7008作为slave 为了方便直接在slave的配置文件中写好master的配置(配从不配主),配置好master的ip,redis的端口和密码 slave的redis.conf里主机配置: 启动主机和从机后一主二从模式就ok了,可以简单测试一下 下面开始配置哨兵 新建了一个sent

Redis 主从哨兵模式搭建

安装单机版redis 1.编译redis cd /opt/ tar zxvf redis-3.0.6.tar.gz cd redis-3.0.6 make 2.创建redis目录 cd src/ mkdir /usr/local/redis cp redis-cli /usr/local/redis/ cp redis-server /usr/local/redis/ cd .. cp redis.conf /usr/local/redis/ 3.修改配置文件 cd /usr/local/red

redis sentinel哨兵模式集群搭建教程

1.环境说明 我们将使用192.168.220.128.192.168.220.129.192.168.220.130三台机器搭建sentinel集群 当前我们已在192.168.220.128上按redis安装教程安装了redis,192.168.220.129和192.168.220.130两台上没有安装 2.配置并启动192.168.220.128上的sentinel 2.1修改conf/redis.conf,配置masterauth字段值 2.2修改conf/sentinel.conf,

Redis之哨兵模式Sentinel配置与启动(五)

一.介绍 上一篇我们已经介绍了Redis的主从复制,传送门:<Redis高可用之主从复制实践(四)>,想必大家对redis已经有一个概念了,那么问题来了,如果redis主从复制的master服务器挂掉了,那么整体redis就崩溃了,因为master无法进行写数据,导致slave中无法更新数据. 那么为了解决这个问题我们就需要有一种方案让redis宕机后可以自动进行故障转移,还好redis给我们提供一种高可用解决方案 Redis-Sentinel.Redis-sentinel本身也是一个独立运行

redis哨兵模式

前面总结了redis的主从复制,实现了读写分离,但是这种模式存在了一定的弊端,例如主机宕机后,从机就失去了存在的意义,因为从机无法反客为主,实现对外提供服务.需要人工手动操作.而redis的哨兵模式可以实现当主机宕机后,从机根据投票模式,票数多的自动切换成主机.下面总结一些如何进行配置. (1)首先还是准备3台服务器,ip分别为192.168.0.101(主机), 192,168.0.102, 192.168.0.104. (2)先配置好主从复制,使用命令slaveof host post,如下