Redis高可用集群-哨兵模式(Redis-Sentinel)搭建配置教程【Windows环境】
No cross,no crown . 不经历风雨,怎么见彩虹。
Redis哨兵模式,用现在流行的话可以说就是一个“哨兵机器人”,给“哨兵机器人”进行相应的配置之后,这个"机器人"可以7*24小时工作,它能能够自动帮助你做一些事情,如监控,提醒,自动处理故障等。
Redis-sentinel简介
Redis-sentinel是Redis的作者antirez,因为Redis集群的被各大公司使用,每个公司要写自己的集群管理工具,于是antirez花了几个星期写出了Redis-sentinel。
Redis 的 Sentinel 系统用于管理多个 Redis 服务器(instance),Redis 的 Sentinel 为Redis提供了高可用性。使用哨兵模式创建一个可以不用人为干预而应对各种故障的Redis部署。
该系统执行以下三个任务:
- 监控(Monitoring):Sentinel会不断地检查你的主服务器和从服务器是否允许正常。
- 提醒(Notification):当被监控的某个Redis服务器出现问题时,Sentinel可以通过API向管理员或者其他应用程序发送通知。
- 自动故障迁移(Automatic failover): (1)当一个主服务器不能正常工作时,Sentinel会开始一次自动故障迁移操作,他会将失效主服务器的其中一个从服务器升级为新的主服务器,并让失效主服务器的其他从服务器改为复制新的主服务器;
(2)客户端试图连接失败的主服务器时,集群也会向客服端返回新主服务器的地址,是的集群可以使用新主服务器代替失效服务器。
sentinel的分布式特性
Redis Sentinel 是一个分布式系统, 你可以在一个架构中运行多个 Sentinel 进程(progress), 这些进程使用流言协议(gossip protocols)来接收关于主服务器是否下线的信息, 并使用投票协议(agreement protocols)来决定是否执行自动故障迁移, 以及选择哪个从服务器作为新的主服务器。
单个sentinel进程来监控redis集群是不可靠的,当sentinel进程宕掉后(sentinel本身也有单点问题,single-point-of-failure)整个集群系统将无法按照预期的方式运行。所以有必要将sentinel集群,这样有几个好处:
有一些sentinel进程宕掉了,依然可以进行redis集群的主备切换;
如果只有一个sentinel进程,如果这个进程运行出错,或者是网络堵塞,那么将无法实现redis集群的主备切换(单点问题);
如果有多个sentinel,redis的客户端可以随意地连接任意一个sentinel来获得关于redis集群中的信息
一个健壮的部署至少需要三个哨兵实例。
三个哨兵实例应该放置在客户使用独立方式确认故障的计算机或虚拟机中。例如不同的物理机或不同可用区域的虚拟机。【本次讲解是一个机器上进行搭建,和多级是一个道理】
Redis-sentinel搭建
- 环境
Windows10
Redis-x64-3.2.100
本次搭建说明:
master:127.0.0.1:6379 【初始化master】
slave:127.0.0.1:6380 127.0.0.1:6381
sentinel:127.0.0.1:26379 127.0.0.1:26380 127.0.0.1:26381
- 安装和基本配置
因为之前已经介绍过Redis集群的主从配置,里面有安装和基本配置,所以这里不做介绍,不懂的请查看:Redis集群主从复制(一主两从)搭建配置教程【Windows环境】
- Sentinel配置
根据安装和基本配置,已经有了主从配置 ,对应文件夹Redis6379~Redis6381。然后在每个文件夹下面新增 一个名为 sentinel.conf 的文件。配置内容如下:
# 这个是Redis6379配置内容,其他文件同理新增然后改一下端口即可,26380,和 26381。
#当前Sentinel服务运行的端口
port 26379
# 哨兵监听的主服务器
sentinel monitor mymaster 127.0.0.1 6379 2
# 3s内mymaster无响应,则认为mymaster宕机了
sentinel down-after-milliseconds mymaster 3000
#如果10秒后,mysater仍没启动过来,则启动failover
sentinel failover-timeout mymaster 10000
# 执行故障转移时, 最多有1个从服务器同时对新的主服务器进行同步
sentinel parallel-syncs mymaster 1
配置文件只需要配置master的信息就好啦,不用配置slave的信息,因为slave能够被自动检测到(master节点中有关于slave的消息)。
为了更清楚每一行配置的含义,对每个选项的含义进行简单介绍:
sentinel monitor [master-group-name] [ip] [port] [quorum]
- master-group-name:master名称(可以自定义)
- ip port : IP地址和端口号
- quorun:票数,Sentinel需要协商同意master是否可到达的数量。
第一行配置指示 Sentinel 去监视一个名为 mymaster 的主服务器, 这个主服务器的 IP 地址为 127.0.0.1 , 端口号为 6379 , 而将这个主服务器判断为失效至少需要 2 个 Sentinel 同意 (只要同意 Sentinel 的数量不达标,自动故障迁移就不会执行)。
票数在本文中:redis集群中有3个sentinel实例,其中master挂掉啦,这里设置票数为2,表示有2个sentinel认为master挂掉啦,才能被认为是正真的挂掉啦。
sentinel <选项的名字> <主服务器的名字> <选项的值>
- down-after-milliseconds 选项指定了 Sentinel 认为服务器已经断线所需的毫秒数。
如果服务器在给定的毫秒数之内, 没有返回 Sentinel 发送的 PING 命令的回复, 或者返回一个错误, 那么 Sentinel 将这个服务器标记为主观下线(subjectively down,简称 SDOWN )。
不过只有一个 Sentinel 将服务器标记为主观下线并不一定会引起服务器的自动故障迁移: 只有在足够数量的 Sentinel 都将一个服务器标记为主观下线之后, 服务器才会被标记为客观下线(objectively down, 简称 ODOWN ), 这时自动故障迁移才会执行。
将服务器标记为客观下线所需的 Sentinel 数量由对主服务器的配置决定。
- parallel-syncs 选项指定了在执行故障转移时, 最多可以有多少个从服务器同时对新的主服务器进行同步, 这个数字越小, 完成故障转移所需的时间就越长。
5.其他配置
新增Redis启动脚本:startRedisServer.bat
@echo off
redis-server.exe redis.windows.conf
@pause
新增Redis-Sentinel启动脚本:startRedisSentinel.bat
@echo off
redis-server.exe sentinel.conf --sentinel
@pause
在配置启动startrRedis6379.cmd,其他同理!
@echo off
cd Redis6379
startRedisServer.bat
在配置启动startrRedisSentinel26379.cmd,其他同理!
@echo off
cd Redis6379
startRedisSentinel.bat
at
配置完如图:
- 启动Sentinel实例
哨兵启动命令 redis-server.exe sentinel.conf --sentinel
第一步:点击startRedis.cmd ,启动Redis集群
第二步:点击startRedisSentinel.cmd ,启动哨兵实例
查看Sentinel启动日志,看到```
生成哨兵ID(Sentinel ID),并自动识别主服务器和从服务器!
[114252] 03 Mar 13:32:57.896 # Sentinel ID is 89f521b40a803495472c0457b0396473c4bfb100
[114252] 03 Mar 13:32:57.896 # +monitor master mymaster 127.0.0.1 6379 quorum 2
[114252] 03 Mar 13:32:57.909 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:32:57.917 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
查看主服务器6379(Master)信息:
F:\nosql_learn\Redis-Sentinel\Redis6379>redis-cli -p 6379
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=54148,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=54148,lag=1
master_repl_offset:54414
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:54413
127.0.0.1:6379>
查看主服务器6380(Slave)信息:
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:80531
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
127.0.0.1:6380>
Redis-Sentinel高可用场景演示
场景1:主服务器master宕机
当主服务器master宕机,那么Sentinel会通过选举(算法)机制,从Salve中选出一个作为新Master。
大概原理是当选出一个Slave要作为Master的时候,会发送命令slaveofno one来取消选中的这个slave,使其成为Master。哨兵会发送给其他从服务器Slave配置选中的这个为新主服务器Master,并删除监听列表中出现故障的Master服务器。
(1)关闭掉 6379主服务器
127.0.0.1:6379> shutdown
not connected>
(2)查看观察选举新的master的过程和显示了failover的过程,整个日志信息还是比较完整的。最后选举了6381为主服务器!
[114252] 03 Mar 13:32:59.945 * +sentinel sentinel 926e67646440b200ee41bb224bacf9e0314e3b32 127.0.0.1 26379 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:33:00.018 * +sentinel sentinel 7fc21e38de0408ccaa06111e44638e2693794e08 127.0.0.1 26380 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.223 # +sdown master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.300 # +odown master mymaster 127.0.0.1 6379 #quorum 2/2
[114252] 03 Mar 13:53:19.300 # +new-epoch 1
[114252] 03 Mar 13:53:19.300 # +try-failover master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.306 # +vote-for-leader 89f521b40a803495472c0457b0396473c4bfb100 1
[114252] 03 Mar 13:53:19.319 # 7fc21e38de0408ccaa06111e44638e2693794e08 voted for 89f521b40a803495472c0457b0396473c4bfb100 1
[114252] 03 Mar 13:53:19.369 # +elected-leader master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.370 # +failover-state-select-slave master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.428 # +selected-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.428 * +failover-state-send-slaveof-noone slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.530 * +failover-state-wait-promotion slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:20.327 # +promoted-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:20.328 # +failover-state-reconf-slaves master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:20.398 * +slave-reconf-sent slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:21.390 * +slave-reconf-inprog slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:21.390 * +slave-reconf-done slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:21.445 # +failover-end master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:21.445 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6381
[114252] 03 Mar 13:53:21.447 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6381
[114252] 03 Mar 13:53:21.449 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381
[114252] 03 Mar 13:53:23.193 # +sdown sentinel 926e67646440b200ee41bb224bacf9e0314e3b32 127.0.0.1 26379 @ mymaster 127.0.0.1 6381
[114252] 03 Mar 13:53:24.451 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381
(3)查看6381服务器信息,角色为主,从服务器6380!
127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=33358,lag=1
master_repl_offset:33505
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:33504
127.0.0.1:6381>
场景2:之前故障的6379 master重新启动
(1)启动6379服务,发现6379成为6381的从服务器!
F:\nosql_learn\Redis-Sentinel\Redis6379>redis-server.exe redis.windows.conf
[116640] 03 Mar 13:59:25.753 * The server is now ready to accept connections on port 6379
[116640] 03 Mar 13:59:48.315 * SLAVE OF 127.0.0.1:6381 enabled (user request from 'id=2 addr=127.0.0.1:61677 fd=7 name=sentinel-7fc21e38-cmd age=10 idle=0 flags=x db=0 sub=0 psub=0 multi=3 qbuf=0 qbuf-free=32768 obl=36 oll=0 omem=0 events=r cmd=exec')
[116640] 03 Mar 13:59:48.326 # CONFIG REWRITE executed with success.
[116640] 03 Mar 13:59:48.826 * Connecting to MASTER 127.0.0.1:6381
[116640] 03 Mar 13:59:48.851 * MASTER <-> SLAVE sync started
(2)查看6381服务器状态信息:原来的master自动切换成slave,不会自动恢复成master。
127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=73183,lag=0
slave1:ip=127.0.0.1,port=6379,state=online,offset=73183,lag=0
master_repl_offset:73183
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:73182
127.0.0.1:6381>
场景3:从服务器Slave宕机和重启
(1)关闭6380从服务器:
127.0.0.1:6380> shutdown
not connected>
(2)Sentinel日志:
[113488] 03 Mar 14:06:50.143 # +sdown slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6381
(3)查看住服务器6381状态信息:
127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6379,state=online,offset=111361,lag=1
master_repl_offset:111361
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:111360
127.0.0.1:6381>
(4)启动从服务器6380
Connecting to MASTER 127.0.0.1:6381
(5)查看住服务器6381状态信息:6380又回来了!
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6379,state=online,offset=141232,lag=0
slave1:ip=127.0.0.1,port=6380,state=online,offset=141232,lag=1
master_repl_offset:141232
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:141231
127.0.0.1:6381>
Redis-sentinel相关知识
- 主观下线和客观下线
- 每个 Sentinel 都需要定期执行的任务
- 自动发现 Sentinel 和从服务器
....
可以参考 Redis 的 Sentinel 文档
Jedis客户端使用Sentinel
;
import java.util.HashSet;
import java.util.Set;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPoolConfig;
import redis.clients.jedis.JedisSentinelPool;
public class RedisManagerUtil {
private static JedisSentinelPool pool = null;
// 自带的哨兵模式 JedisSentinelPool, 并在一开始初始化连接池
static {
try {
JedisPoolConfig config = new JedisPoolConfig();
// 控制一个pool可分配多少个jedis实例,通过pool.getResource()来获取;
// 如果赋值为-1,则表示不限制;如果pool已经分配了maxActive个jedis实例,则此时pool的状态为exhausted(耗尽)。
config.setMaxTotal(Integer.valueOf(1000));
// 控制一个pool最多有多少个状态为idle(空闲的)的jedis实例。
config.setMaxIdle(Integer.valueOf(20));
// 表示当borrow(引入)一个jedis实例时,最大的等待时间,如果超过等待时间,则直接抛出JedisConnectionException;
config.setMinEvictableIdleTimeMillis(Integer.valueOf(-1));
// 在borrow一个jedis实例时,是否提前进行validate操作;如果为true,则得到的jedis实例均是可用的;
config.setTestOnBorrow(Boolean.valueOf(true));
// master名称和配置文件中配置的要一样
String master = "mymaster";
//setinel客户端提供了master自动发现功能
Set<String> sentinels = new HashSet<String>();
sentinels.add("127.0.0.1:26379");
sentinels.add("127.0.0.1:26380");
sentinels.add("127.0.0.1:26381");
pool = new JedisSentinelPool(master, sentinels, config);
} catch (Exception e) {
e.printStackTrace();
}
}
/**
* 构建redis连接池
*
* @return JedisPool
*/
public static JedisSentinelPool getPool() {
return pool;
}
/**
* 返还到连接池
*
* @param pool
* @param redis
*/
public static void returnResource(JedisSentinelPool pool, Jedis redis) {
if (redis != null) {
try {
pool.returnResource(redis);
} catch (Exception e) {
e.printStackTrace();
}
}
}
/**
* 测试redis线程池是否正常
* @param args
*/
public static void main(String[] args) {
JedisSentinelPool pool = RedisPoolAPIManager.getPool();
Jedis redis = pool.getResource();
System.out.println("redis = " + redis);
if(redis != null){
returnResource(pool,redis);
}
}
}
总结
Redis-Sentinel是Redis官方推荐的高可用性(HA) 解决方案,Redis-sentinel本身也是一个独立运行的进程,它能监控多个master-slave集群,发现master宕机后能进行自动切换。Sentinel可以监视任意多个主服务器(复用),以及主服务器属下的从服务器,并在被监视的主服务器下线时,自动执行故障转移操作。
为了防止sentinel的单点故障,可以对sentinel进行集群化,创建多个sentinel。
如果你想使用本篇博文中配置的redis-Sentinel,可以在这里Redis-Sentinel下载!
参考博文
Redis学习笔记(四) Redis哨兵(sentinel)
本系列文章:
第一篇:Redis集群主从复制(一主两从)搭建配置教程【Windows环境】
第二篇:Redis高可用集群-哨兵模式搭建配置教程【Windows环境】
第三篇:Redis集群模式-主从复制搭建配置教程【Windows环境】
No cross,no crown . 不经历风雨,怎么见彩虹。
Redis哨兵模式,用现在流行的话可以说就是一个“哨兵机器人”,给“哨兵机器人”进行相应的配置之后,这个"机器人"可以7*24小时工作,它能能够自动帮助你做一些事情,如监控,提醒,自动处理故障等。
Redis-sentinel简介
Redis-sentinel是Redis的作者antirez,因为Redis集群的被各大公司使用,每个公司要写自己的集群管理工具,于是antirez花了几个星期写出了Redis-sentinel。
Redis 的 Sentinel 系统用于管理多个 Redis 服务器(instance),Redis 的 Sentinel 为Redis提供了高可用性。使用哨兵模式创建一个可以不用人为干预而应对各种故障的Redis部署。
该系统执行以下三个任务:
- 监控(Monitoring):Sentinel会不断地检查你的主服务器和从服务器是否允许正常。
- 提醒(Notification):当被监控的某个Redis服务器出现问题时,Sentinel可以通过API向管理员或者其他应用程序发送通知。
- 自动故障迁移(Automatic failover): (1)当一个主服务器不能正常工作时,Sentinel会开始一次自动故障迁移操作,他会将失效主服务器的其中一个从服务器升级为新的主服务器,并让失效主服务器的其他从服务器改为复制新的主服务器;
(2)客户端试图连接失败的主服务器时,集群也会向客服端返回新主服务器的地址,是的集群可以使用新主服务器代替失效服务器。
sentinel的分布式特性
Redis Sentinel 是一个分布式系统, 你可以在一个架构中运行多个 Sentinel 进程(progress), 这些进程使用流言协议(gossip protocols)来接收关于主服务器是否下线的信息, 并使用投票协议(agreement protocols)来决定是否执行自动故障迁移, 以及选择哪个从服务器作为新的主服务器。
单个sentinel进程来监控redis集群是不可靠的,当sentinel进程宕掉后(sentinel本身也有单点问题,single-point-of-failure)整个集群系统将无法按照预期的方式运行。所以有必要将sentinel集群,这样有几个好处:
有一些sentinel进程宕掉了,依然可以进行redis集群的主备切换;
如果只有一个sentinel进程,如果这个进程运行出错,或者是网络堵塞,那么将无法实现redis集群的主备切换(单点问题);
如果有多个sentinel,redis的客户端可以随意地连接任意一个sentinel来获得关于redis集群中的信息
一个健壮的部署至少需要三个哨兵实例。
三个哨兵实例应该放置在客户使用独立方式确认故障的计算机或虚拟机中。例如不同的物理机或不同可用区域的虚拟机。【本次讲解是一个机器上进行搭建,和多级是一个道理】
Redis-sentinel搭建
- 环境
Windows10
Redis-x64-3.2.100
本次搭建说明:
master:127.0.0.1:6379 【初始化master】
slave:127.0.0.1:6380 127.0.0.1:6381
sentinel:127.0.0.1:26379 127.0.0.1:26380 127.0.0.1:26381
- 安装和基本配置
因为之前已经介绍过Redis集群的主从配置,里面有安装和基本配置,所以这里不做介绍,不懂的请查看:Redis集群主从复制(一主两从)搭建配置教程【Windows环境】
- Sentinel配置
根据安装和基本配置,已经有了主从配置 ,对应文件夹Redis6379~Redis6381。然后在每个文件夹下面新增 一个名为 sentinel.conf 的文件。配置内容如下:
# 这个是Redis6379配置内容,其他文件同理新增然后改一下端口即可,26380,和 26381。
#当前Sentinel服务运行的端口
port 26379
# 哨兵监听的主服务器
sentinel monitor mymaster 127.0.0.1 6379 2
# 3s内mymaster无响应,则认为mymaster宕机了
sentinel down-after-milliseconds mymaster 3000
#如果10秒后,mysater仍没启动过来,则启动failover
sentinel failover-timeout mymaster 10000
# 执行故障转移时, 最多有1个从服务器同时对新的主服务器进行同步
sentinel parallel-syncs mymaster 1
配置文件只需要配置master的信息就好啦,不用配置slave的信息,因为slave能够被自动检测到(master节点中有关于slave的消息)。
为了更清楚每一行配置的含义,对每个选项的含义进行简单介绍:
sentinel monitor [master-group-name] [ip] [port] [quorum]
- master-group-name:master名称(可以自定义)
- ip port : IP地址和端口号
- quorun:票数,Sentinel需要协商同意master是否可到达的数量。
第一行配置指示 Sentinel 去监视一个名为 mymaster 的主服务器, 这个主服务器的 IP 地址为 127.0.0.1 , 端口号为 6379 , 而将这个主服务器判断为失效至少需要 2 个 Sentinel 同意 (只要同意 Sentinel 的数量不达标,自动故障迁移就不会执行)。
票数在本文中:redis集群中有3个sentinel实例,其中master挂掉啦,这里设置票数为2,表示有2个sentinel认为master挂掉啦,才能被认为是正真的挂掉啦。
sentinel <选项的名字> <主服务器的名字> <选项的值>
- down-after-milliseconds 选项指定了 Sentinel 认为服务器已经断线所需的毫秒数。
如果服务器在给定的毫秒数之内, 没有返回 Sentinel 发送的 PING 命令的回复, 或者返回一个错误, 那么 Sentinel 将这个服务器标记为主观下线(subjectively down,简称 SDOWN )。
不过只有一个 Sentinel 将服务器标记为主观下线并不一定会引起服务器的自动故障迁移: 只有在足够数量的 Sentinel 都将一个服务器标记为主观下线之后, 服务器才会被标记为客观下线(objectively down, 简称 ODOWN ), 这时自动故障迁移才会执行。
将服务器标记为客观下线所需的 Sentinel 数量由对主服务器的配置决定。
- parallel-syncs 选项指定了在执行故障转移时, 最多可以有多少个从服务器同时对新的主服务器进行同步, 这个数字越小, 完成故障转移所需的时间就越长。
5.其他配置
新增Redis启动脚本:startRedisServer.bat
@echo off
redis-server.exe redis.windows.conf
@pause
新增Redis-Sentinel启动脚本:startRedisSentinel.bat
@echo off
redis-server.exe sentinel.conf --sentinel
@pause
在配置启动startrRedis6379.cmd,其他同理!
@echo off
cd Redis6379
startRedisServer.bat
在配置启动startrRedisSentinel26379.cmd,其他同理!
@echo off
cd Redis6379
startRedisSentinel.bat
at
配置完如图:
- 启动Sentinel实例
哨兵启动命令 redis-server.exe sentinel.conf --sentinel
第一步:点击startRedis.cmd ,启动Redis集群
第二步:点击startRedisSentinel.cmd ,启动哨兵实例
查看Sentinel启动日志,看到```
生成哨兵ID(Sentinel ID),并自动识别主服务器和从服务器!
[114252] 03 Mar 13:32:57.896 # Sentinel ID is 89f521b40a803495472c0457b0396473c4bfb100
[114252] 03 Mar 13:32:57.896 # +monitor master mymaster 127.0.0.1 6379 quorum 2
[114252] 03 Mar 13:32:57.909 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:32:57.917 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
查看主服务器6379(Master)信息:
F:\nosql_learn\Redis-Sentinel\Redis6379>redis-cli -p 6379
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=54148,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=54148,lag=1
master_repl_offset:54414
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:54413
127.0.0.1:6379>
查看主服务器6380(Slave)信息:
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:80531
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
127.0.0.1:6380>
Redis-Sentinel高可用场景演示
场景1:主服务器master宕机
当主服务器master宕机,那么Sentinel会通过选举(算法)机制,从Salve中选出一个作为新Master。
大概原理是当选出一个Slave要作为Master的时候,会发送命令slaveofno one来取消选中的这个slave,使其成为Master。哨兵会发送给其他从服务器Slave配置选中的这个为新主服务器Master,并删除监听列表中出现故障的Master服务器。
(1)关闭掉 6379主服务器
127.0.0.1:6379> shutdown
not connected>
(2)查看观察选举新的master的过程和显示了failover的过程,整个日志信息还是比较完整的。最后选举了6381为主服务器!
[114252] 03 Mar 13:32:59.945 * +sentinel sentinel 926e67646440b200ee41bb224bacf9e0314e3b32 127.0.0.1 26379 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:33:00.018 * +sentinel sentinel 7fc21e38de0408ccaa06111e44638e2693794e08 127.0.0.1 26380 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.223 # +sdown master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.300 # +odown master mymaster 127.0.0.1 6379 #quorum 2/2
[114252] 03 Mar 13:53:19.300 # +new-epoch 1
[114252] 03 Mar 13:53:19.300 # +try-failover master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.306 # +vote-for-leader 89f521b40a803495472c0457b0396473c4bfb100 1
[114252] 03 Mar 13:53:19.319 # 7fc21e38de0408ccaa06111e44638e2693794e08 voted for 89f521b40a803495472c0457b0396473c4bfb100 1
[114252] 03 Mar 13:53:19.369 # +elected-leader master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.370 # +failover-state-select-slave master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.428 # +selected-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.428 * +failover-state-send-slaveof-noone slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.530 * +failover-state-wait-promotion slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:20.327 # +promoted-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:20.328 # +failover-state-reconf-slaves master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:20.398 * +slave-reconf-sent slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:21.390 * +slave-reconf-inprog slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:21.390 * +slave-reconf-done slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:21.445 # +failover-end master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:21.445 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6381
[114252] 03 Mar 13:53:21.447 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6381
[114252] 03 Mar 13:53:21.449 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381
[114252] 03 Mar 13:53:23.193 # +sdown sentinel 926e67646440b200ee41bb224bacf9e0314e3b32 127.0.0.1 26379 @ mymaster 127.0.0.1 6381
[114252] 03 Mar 13:53:24.451 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381
(3)查看6381服务器信息,角色为主,从服务器6380!
127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=33358,lag=1
master_repl_offset:33505
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:33504
127.0.0.1:6381>
场景2:之前故障的6379 master重新启动
(1)启动6379服务,发现6379成为6381的从服务器!
F:\nosql_learn\Redis-Sentinel\Redis6379>redis-server.exe redis.windows.conf
[116640] 03 Mar 13:59:25.753 * The server is now ready to accept connections on port 6379
[116640] 03 Mar 13:59:48.315 * SLAVE OF 127.0.0.1:6381 enabled (user request from 'id=2 addr=127.0.0.1:61677 fd=7 name=sentinel-7fc21e38-cmd age=10 idle=0 flags=x db=0 sub=0 psub=0 multi=3 qbuf=0 qbuf-free=32768 obl=36 oll=0 omem=0 events=r cmd=exec')
[116640] 03 Mar 13:59:48.326 # CONFIG REWRITE executed with success.
[116640] 03 Mar 13:59:48.826 * Connecting to MASTER 127.0.0.1:6381
[116640] 03 Mar 13:59:48.851 * MASTER <-> SLAVE sync started
(2)查看6381服务器状态信息:原来的master自动切换成slave,不会自动恢复成master。
127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=73183,lag=0
slave1:ip=127.0.0.1,port=6379,state=online,offset=73183,lag=0
master_repl_offset:73183
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:73182
127.0.0.1:6381>
场景3:从服务器Slave宕机和重启
(1)关闭6380从服务器:
127.0.0.1:6380> shutdown
not connected>
(2)Sentinel日志:
[113488] 03 Mar 14:06:50.143 # +sdown slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6381
(3)查看住服务器6381状态信息:
127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6379,state=online,offset=111361,lag=1
master_repl_offset:111361
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:111360
127.0.0.1:6381>
(4)启动从服务器6380
Connecting to MASTER 127.0.0.1:6381
(5)查看住服务器6381状态信息:6380又回来了!
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6379,state=online,offset=141232,lag=0
slave1:ip=127.0.0.1,port=6380,state=online,offset=141232,lag=1
master_repl_offset:141232
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:141231
127.0.0.1:6381>
Redis-sentinel相关知识
- 主观下线和客观下线
- 每个 Sentinel 都需要定期执行的任务
- 自动发现 Sentinel 和从服务器
....
可以参考 Redis 的 Sentinel 文档
Jedis客户端使用Sentinel
;
import java.util.HashSet;
import java.util.Set;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPoolConfig;
import redis.clients.jedis.JedisSentinelPool;
public class RedisManagerUtil {
private static JedisSentinelPool pool = null;
// 自带的哨兵模式 JedisSentinelPool, 并在一开始初始化连接池
static {
try {
JedisPoolConfig config = new JedisPoolConfig();
// 控制一个pool可分配多少个jedis实例,通过pool.getResource()来获取;
// 如果赋值为-1,则表示不限制;如果pool已经分配了maxActive个jedis实例,则此时pool的状态为exhausted(耗尽)。
config.setMaxTotal(Integer.valueOf(1000));
// 控制一个pool最多有多少个状态为idle(空闲的)的jedis实例。
config.setMaxIdle(Integer.valueOf(20));
// 表示当borrow(引入)一个jedis实例时,最大的等待时间,如果超过等待时间,则直接抛出JedisConnectionException;
config.setMinEvictableIdleTimeMillis(Integer.valueOf(-1));
// 在borrow一个jedis实例时,是否提前进行validate操作;如果为true,则得到的jedis实例均是可用的;
config.setTestOnBorrow(Boolean.valueOf(true));
// master名称和配置文件中配置的要一样
String master = "mymaster";
//setinel客户端提供了master自动发现功能
Set<String> sentinels = new HashSet<String>();
sentinels.add("127.0.0.1:26379");
sentinels.add("127.0.0.1:26380");
sentinels.add("127.0.0.1:26381");
pool = new JedisSentinelPool(master, sentinels, config);
} catch (Exception e) {
e.printStackTrace();
}
}
/**
* 构建redis连接池
*
* @return JedisPool
*/
public static JedisSentinelPool getPool() {
return pool;
}
/**
* 返还到连接池
*
* @param pool
* @param redis
*/
public static void returnResource(JedisSentinelPool pool, Jedis redis) {
if (redis != null) {
try {
pool.returnResource(redis);
} catch (Exception e) {
e.printStackTrace();
}
}
}
/**
* 测试redis线程池是否正常
* @param args
*/
public static void main(String[] args) {
JedisSentinelPool pool = RedisPoolAPIManager.getPool();
Jedis redis = pool.getResource();
System.out.println("redis = " + redis);
if(redis != null){
returnResource(pool,redis);
}
}
}
总结
Redis-Sentinel是Redis官方推荐的高可用性(HA) 解决方案,Redis-sentinel本身也是一个独立运行的进程,它能监控多个master-slave集群,发现master宕机后能进行自动切换。Sentinel可以监视任意多个主服务器(复用),以及主服务器属下的从服务器,并在被监视的主服务器下线时,自动执行故障转移操作。
为了防止sentinel的单点故障,可以对sentinel进行集群化,创建多个sentinel。
如果你想使用本篇博文中配置的redis-Sentinel,可以在这里Redis-Sentinel下载!
参考博文
Redis学习笔记(四) Redis哨兵(sentinel)
本系列文章:
第一篇:Redis集群主从复制(一主两从)搭建配置教程【Windows环境】
第二篇:Redis高可用集群-哨兵模式(Redis-Sentinel)搭建配置教程【Windows环境】
**如果您觉得这篇博文对你有帮助,请点个赞,让更多的人看到,谢谢!**
**如果帅气(美丽)、睿智(聪颖),和我一样简单善良的你看到本篇博文中存在问题,请指出,我虚心接受你让我成长的批评,谢谢阅读!
祝你今天开心愉快!**
欢迎访问我的csdn博客,我们一同成长!
"不管做什么,只要坚持下去就会看到不一样!在路上,不卑不亢!"
博客首页:http://blog.csdn.net/u010648555
Redis高可用集群-哨兵模式(Redis-Sentinel)搭建配置教程【Windows环境】的更多相关文章
- Redis高可用集群-哨兵模式(Redis-Sentinel)
前言 Redis哨兵模式,用现在流行的话可以说就是一个“哨兵机器人”,给“哨兵机器人”进行相应的配置之后,这个"机器人"可以7*24小时工作,它能能够自动帮助你做一些事情,如监控 ...
- 基于Docker-compose搭建Redis高可用集群-哨兵模式(Redis-Sentinel)
原文转载自「刘悦的技术博客」https://v3u.cn/a_id_110 我们知道,Redis的集群方案大致有三种:1)redis cluster集群方案:2)master/slave主从方案:3) ...
- 基于docker实现redis高可用集群
基于docker实现redis高可用集群 yls 2019-9-20 简介 基于docker和docker-compose 使用redis集群和sentinel集群,达到redis高可用,为缓存做铺垫 ...
- (六) Docker 部署 Redis 高可用集群 (sentinel 哨兵模式)
参考并感谢 官方文档 https://hub.docker.com/_/redis GitHub https://github.com/antirez/redis happyJared https:/ ...
- Redis 高可用集群
Redis 高可用集群 Redis 的集群主从模型是一种高可用的集群架构.本章主要内容有:高可用集群的搭建,Jedis连接集群,新增集群节点,删除集群节点,其他配置补充说明. 高可用集群搭建 集群(c ...
- sentinel监控redis高可用集群(一)
一.首先配置redis的主从同步集群. 1.主库的配置文件不用修改,从库的配置文件只需增加一行,说明主库的IP端口.如果需要验证的,也要加多一行,认证密码. slaveof 192.168.20.26 ...
- Redis系列(二):Redis高可用集群
一.集群模式 Redis集群是一个由多个主从节点组成的高可用集群,它具有复制.高可用和分片等特性 二.集群部署 1.环境 3台主机分别是: 192.168.160.146 192.168.160.15 ...
- Redis高可用集群方案——哨兵
本篇文章版权归博客园和作者吴双本人共同所有,转载和爬虫请注明原文系列地址http://www.cnblogs.com/tdws/tag/NoSql/ 本人之前有篇文章,讲到了redis主从复制,读写分 ...
- 生产环境的redis高可用集群搭建
这里只是总结一下安装步骤 如果要了解redis集群高可用的原理,推荐仔细看一遍配置文件示例http://download.redis.io/redis-stable/redis.conf,源码包里也有 ...
随机推荐
- php编程——验证码的实现(session方法)
index.PHP(实现输入验证码页面)代码如下: <html><head><title>check code</title></head> ...
- virtualbox 迁移虚拟机存储位置
1. 菜单--管理--全局设定 ,更改 默认虚拟电脑位置. 2. 复制 (移动)现有虚拟机目录到新位置,软件里删除现有虚拟机 3. 菜单--控制--注册,逐个选择虚拟机目录里的 .vbox文件,导进虚 ...
- ubuntu 指定用户执行脚本
方法 创建可执行脚本 以下以脚本名称为superset.sh为例,具体的脚本内容大家可以自己发挥. cd ~ vi superset.sh # 脚本内容自己写好后保存 修改脚本权限 sudo chmo ...
- js判断当前页面是顶级窗口
<script> if(top.location!=self.location){ alert("不是顶层窗口"); }else{ alert("是顶层窗口& ...
- [整理].net中的延迟初始化器
LazyInitializer类 private void EnsureInitialized() { LazyInitializer.EnsureInitialized(ref _initializ ...
- 史上最全的浏览器 CSS & JS Hack 手册
浏览器渲染页面的方式各不相同,甚至同一浏览器的不同版本(“杰出代表”是 IE)也有差异.因此,浏览器兼容成为前端开发人员的必备技能.如果有一份浏览器 Hack 手册,那查询起来就方便多了.这篇文章就向 ...
- HDU 1005 Number Sequence (模拟)
题目链接 Problem Description A number sequence is defined as follows: f(1) = 1, f(2) = 1, f(n) = (A * f( ...
- WIN10文件无法自动刷新问题解决方法
Window10系统有时候会遇到以下类似的问题 1.文件删除后,图标还在,无法自动刷新屏幕,按F5或右键菜单刷新后才消失 2.文件粘贴后,不显示,刷新后才显示 3.回收站清理后,文件图标仍显示有垃圾 ...
- Linux使用一个定时器实现设置任意数量定时器功能【转】
转自:https://www.jb51.net/article/120748.htm 为什么需要这个功能,因为大多数计算机软件时钟系统通常只能有一个时钟触发一次中断.当运行多个任务时,我们会想要多个定 ...
- git学习——Git 基础要点【转】
转自:http://blog.csdn.net/zeroboundary/article/details/10549555 简单地说,Git 究竟是怎样的一个系统呢?请注意,接下来的内容非常重要,若是 ...