默认情况下,Redis node和sentinel的protected-mode都是yes,在搭建集群时,若想从远程连接redis集群,需要将redis.conf和sentinel.conf的protected-mode修改为no,若只修改redis node,从远程连接sentinel后,依然是无法正常使用的,且sentinel的配置文件中没有protected-mode配置项,需要手工添加。

protected-mode在默认开启的情况下要是配置里没有指定bind和密码。开启该参数后,redis只会本地进行访问,拒绝外部访问

----------------------------------------------------------------------------

Sentinel(哨岗、哨兵)是Redis的高可用性解决方案:由一个或多个Sentinel实现组成的Sentinel系统可以监控任意多个主服务器,以及这些主服务器属下的所有从服务器,并在被监视的主服务器进入下线状态时,自动将下线主服务器属下的某个从服务器升级为新的主服务器,然后由新的主服务器代替已下线的主服务器继续处理命令请求。

redis.conf中从的转为主的优先级,数字越小,级别越高。默认100

slave-priority 100

-----------------------------------------------------------------------------

一、Redis Sentinel是redis自带的集群管理工具,主要功能有

·  监控(Monitoring): Redis Sentinel实时监控主服务器和从服务器运行状态。

·  提醒(Notification):当被监控的某个 Redis 服务器出现问题时, Redis Sentinel 可以向系统管理员发送通知, 也可以通过 API 向其他程序发送通知。

·  自动故障转移(Automatic failover): 当一个主服务器不能正常工作时,Redis Sentinel 可以将一个从服务器升级为主服务器, 并对其他从服务器进行配置,让它们使用新的主服务器。当应用程序连接到Redis 服务器时, Redis Sentinel会告之新的主服务器地址和端口。

Redis Sentinel 是一个分布式系统, 你可以在架构中运行多个 Sentinel 进程,这些进程通过相互通讯来判断一个主服务器是否断线,以及是否应该执行故障转移。

在配置Redis Sentinel时,至少需要有1个Master和1个Slave。当Master失效后,Redis Sentinel会报出失效警告,并通过自动故障转移将Slave提升为Master,并提供读写服务;当失效的Master恢复后,Redis Sentinel会自动识别,将Master自动转换为Slave并完成数据同步。

通过Redis Sentinel可以实现Redis零手工干预并且短时间内进行M-S切换,减少业务影响时间。

二、拓扑结构

在两个服务器中分别都部署Redis和Redis Sentinel。当Master中的Redis出现故障时(Redis进程终止、服务器僵死、服务器断电等),由Redis Sentinel将Master权限切换至Slave Redis中,并将只读模式更改为可读可写模式。应用程序通过Redis Sentinal确定当前Master Redis位置,进行重新连接。

根据业务模式,可以制定两种拓扑结构:单M-S结构和双M-S结构。如果有足够多的服务器,可以配置多M-S结构。

1、单M-S结构

单M-S结构特点是在Master服务器中配置Master Redis(Redis-1M)和Master Sentinel(Sentinel-1M)。Slave服务器中配置Slave Redis(Redis-1S)和Slave Sentinel(Sentinel-1S)。其中 Master Redis可以提供读写服务,但是Slave Redis只能提供只读服务。因此,在业务压力比较大的情况下,可以选择将只读业务放在Slave Redis中进行。

2、双M-S结构

双M-S结构的特点是在每台服务器上配置一个Master Redis,同时部署一个Slave Redis。由两个Redis Sentinel同时对4个Redis进行监控。两个Master Redis可以同时对应用程序提供读写服务,即便其中一个服务器出现故障,另一个服务器也可以同时运行两个Master Redis提供读写服务。缺点是两个Master redis之间无法实现数据共享,不适合存在大量用户数据关联的应用使用。

3、优劣对比

两个结构各有优缺点,分别适用于不同的应用场景:

单M-S结构适用于不同用户数据存在关联,但应用可以实现读写分离的业务模式。Master主要提供写操作,Slave主要提供读操作,充分利用硬件资源。

双(多)M-S结构适用于用户间不存在或者存在较少的数据关联的业务模式,读写效率是单M-S的两(多)倍,但要求故障时单台服务器能够承担两个Mater Redis的资源需求。

三、配置部署

单M-S结构和双M-S结构配置相差无几,下面以双M-S结构配置为例。

1、Redis配置

1)Master Redis配置

在Server-1M上配置Redis-1M

# vi redis-1M.conf

## master redis-1M

## daemonize默认为no,修改为yes,启用后台运行

daemonize yes

# Redis 默认pid 文件位置redis.pid

#当运行多个 redis 服务时,需要指定不同的 pid 文件和端口

pidfile redis-1M.pid

##端口号

port 6379

##验证口令

requirepass *************

masterauth *************

#绑定可连接Redis的IP地址,不设置将处理所有请求

# bind 127.0.0.1

#客户端连接的超时时间,单位为秒,超时后会关闭连接(0为不设置)

timeout 0

#日志记录等级

loglevel notice

#设置数据库的个数

databases 16

#日志刷新策略(Master禁用)

#save 900 1

#save 300 10

#save 60 10000

#是否使用压缩镜像备份

rdbcompression yes

#镜像备份文件的文件名

dbfilename redis-1M_dump.rdb

#镜像备份路径,默认值为 ./

dir /redis/backup

#设置该数据库为其他数据库的从数据库,主库无需设置

#slaveof

# slaveof

#指定与主数据库连接时需要的密码验证,主库无需设置

#masterauth

#masterauth

#如果 slave-serve-stale-data 设置成 'no',slave会返回"SYNC with master in #progress"错误信息,但 INFO和SLAVEOF命令除外。

slave-serve-stale-data yes

#客户端连接访问口令

# requirepass foobared

#限制同时连接的客户数量,防止过多的client导致内存耗尽。如果有足够内存可以不进行#设置

#maxclients 10000

#设置redis能够使用的最大内存。

# maxmemory

##启用增量(Master禁用)----是否开启appendonlylog,开启的话每次写操作会记一条log,这会提高数据抗风险能力,但影响效率。当设为yes时将对redis所有的操作都保存到AOF文件中,因为dump.rdb是异步的,在下次快照到达之前,如果出现crash等问题,会造成数据丢失,而AOF文件时同步记录的,所以会完整的恢复数据

appendonly no

#增量日志文件名,默认值为appendonly.aof

appendfilename appendonly.aof

#设置对 appendonly.aof 文件进行同步的频率

#always 表示每次有写操作都进行同步,everysec 表示对写操作进行累积,每秒同步一次。

#no表示等操作系统进行数据缓存同步到磁盘,都进行同步,everysec 表示对写操作进行累#积,每秒同步一次

appendfsync everysec

#是否重置Hash表

#设置成yes后redis将每100毫秒使用1毫秒CPU时间来对redis的hash表重新hash,##可降低内存的使用。当使用场景有较为严格的实时性需求,不能接受Redis时不时的对请##求有2毫秒的延迟的话,把这项配置为no。如果没有这么严格的实时性要求,可以设置为 #yes,能够尽可能快的释放内存。

activerehashing yes

##Slave开启只读模式

slave-read-only yes

在Server-1S上配置Redis-2M

# vi redis-2M.conf

## master redis-2M

# Redis 默认pid 文件位置redis.pid

#当运行多个 redis 服务时,需要指定不同的 pid 文件和端口

pidfile redis-2M.pid

#镜像备份文件的文件名

dbfilename redis-1M_dump.rdb

#日志刷新策略(Slave启用)

save 900 1

save 300 10

save 60 10000

#-----------------其他参数与redis-1M保持一致-----------------

daemonize yes

#……

2)Slave Redis配置

在Server-1S上配置Redis-1S

# Redis 默认pid 文件位置redis.pid

#当运行多个 redis 服务时,需要指定不同的 pid 文件和端口

pidfile redis-1S.pid

##端口号

port 7379

#镜像备份文件的文件名

dbfilename redis-1S_dump.rdb

#设置该数据库为其他数据库的从数据库,主库无需设置

Slaveof server-1M 6379

##启用增量(Master禁用)

appendonly yes

#-----------------其他参数与redis-1M保持一致-----------------

daemonize yes

#……

在Server-1M上配置Redis-2S

# Redis 默认pid 文件位置redis.pid

#当运行多个 redis 服务时,需要指定不同的 pid 文件和端口

pidfile redis-2S.pid

##端口号

port 7379

#镜像备份文件的文件名

dbfilename redis-2S_dump.rdb

#设置该数据库为其他数据库的从数据库,主库无需设置

Slaveof server-1S 6379

#-----------------其他参数与redis-2M保持一致-----------------

daemonize yes

#……

2、Redis Sentinel配置

在Server-1M上配置Sentinel-1M

vi sentinel-1M.conf

#Master redis-1M

#hostname server-1M

#ip 192.168.84.129

#端口号

port 26379

sentinel monitor server-1M 192.168.84.129 6379 1

sentinel down-after-milliseconds server-1M 5000

sentinel failover-timeout server-1M 900000

sentinel can-failover server-1M yes

sentinel parallel-syncs server-1M 1

#Master redis-1S

#hostname server-1S

#ip 192.168.84.128

sentinel monitor server-1S 192.168.84.128 6379 1

sentinel down-after-milliseconds server-1S 5000

sentinel failover-timeout server-1S 900000

sentinel can-failover server-1S yes

sentinel parallel-syncs server-1S 1

在Server-1S上配置Sentinel-1S

#Master redis-1M

#hostname server-1M

#ip 192.168.84.128

#端口号

port 27379

sentinel monitor server-1M 192.168.84.129 6379 1

sentinel down-after-milliseconds server-1M 5000

sentinel failover-timeout server-1M 900000

sentinel can-failover server-1M yes

sentinel parallel-syncs server-1M 1

#Master redis-1S

#hostname server-1S

#ip 192.168.84.128

sentinel monitor server-1S 192.168.84.128 6379 1

sentinel down-after-milliseconds server-1S 5000

sentinel failover-timeout server-1S 900000

sentinel can-failover server-1S yes

sentinel parallel-syncs server-1S 1

3、启动服务

Server-1M启动redis

redis-server redis-1M.conf

redis-server redis-2S.conf

Server-1S启动redis

redis-server redis-1S.conf

redis-server redis-2M.conf

 

启动sentinel服务

redis-sentinel sentinel-1M.conf

四、备份恢复

1、备份策略

Redis提供两种相对有效的备份方法:RDB和AOF。

RDB是在某个时间点将内存中的所有数据的快照保存到磁盘上,在数据恢复时,可以恢复备份时间以前的所有数据,但无法恢复备份时间点后面的数据。

AOF是以协议文本的方式,将所有对数据库进行过写入的命令(及其参数)记录到 AOF 文件,以此达到记录数据库状态的目的。优点是基本可以实现数据无丢失(缓存的数据有可能丢失),缺点是随着数据量的持续增加,AOF文件也会越来越大。

在保证数据安全的情况下,尽量避免因备份数据消耗过多的Redis资源,采用如下备份策略:

Master端:不采用任何备份机制

Slave端:采用AOF(严格数据要求时可同时开启RDB),每天将AOF文件备份至备份服务器。

为了最大限度减少Master端的资源干扰,将备份相关全部迁移至Slave端完成。同时这样也有缺点,当Master挂掉后,应用服务切换至Slave端,此时的Slave端的负载将会很大。目前Redis不支持RDB和AOF参数动态修改,需要重启Redis生效,希望能在新的版本中实现更高效的修改方式。

2、灾难恢复

·         当Master端Redis服务崩溃(包含主机断电、进程消失等),Redis sentinel将Slave切换为读写状态,提供生产服务。通过故障诊断修复Master,启动后会自动加入Sentinel并从Slave端完成数据同步,但不会切换。

·         当Master和Slave同时崩溃(如机房断电),启动服务器后,将备份服务器最新的AOF备份拷贝至Master端,启动Master。一切完成后再启动Slave。

------------------------------------------------------------------

查看redis信息:

redis-cli -h 127.0.0.1 -p 6379 info Replication

# Replication
role:master
connected_slaves:1
slave0:10.0.2.212,7379,online

查看sentinel信息 :

redis-cli -h 172.18.18.207 -p 26379  info      (后面加# 字节,只显示指定部分的内容)

INFO"指令将会打印完整的服务信息,包括集群,我们只需要关注"replication"部分,这部分信息将会告诉我们"当前server的角色"以及指向它的所有的slave信息.可以通过在任何一个slave上,使用"INFO"指令获得当前slave所指向的master信息

可以使用redis-cli查看sentinel管理的redis群集:

redis-cli -h 172.18.18.207 -p 26379  sentinel masters

1) "name"

2) "mymaster"

3) "ip"

4) "172.18.18.207"

5) "port"

6) "6500"

...

查看一个指定的master有那些slaves:

172.18.18.207:26379> sentinel slaves mymaster

1) "name"

2) "172.18.18.207:6501"

3) "ip"

4) "172.18.18.207"

5) "port"

6) "6501"

...

还可以强制一个redis群集做failover: 
172.18.18.207:26379> sentinel failover mymaster

OK

在master上  redis-cli -p 26379  shutdown ,手动把master sentinel停掉

----------------------------------------------------------------------------------------------------------------------------------

首先解释2个名词:SDOWN和ODOWN.

  • SDOWN:subjectivelydown,直接翻译的为"主观"失效,即当前sentinel实例认为某个redis服务为"不可用"状态.
  • ODOWN:objectivelydown,直接翻译为"客观"失效,即多个sentinel实例都认为master处于"SDOWN"状态,那么此时master将处于ODOWN,ODOWN可以简单理解为master已经被集群确定为"不可用",将会开启failover.

SDOWN适合于master和slave,但是ODOWN只会使用于master;当slave失效超过"down-after-milliseconds"后,那么所有sentinel实例都会将其标记为"SDOWN".

+sdown 主观下线  -sdown 主观上线

+odown 客观下线  -odown 客观下线

Sentinel作用:
1):Master状态检测 
2):如果Master异常,则会进行Master-Slave切换,将其中一个Slave作为Master,将之前的Master作为Slave
3):Master-Slave切换后,master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变,即master_redis.conf中会多一行slaveof的配置,sentinel.conf的监控目标会随之调换

redis3.0版本的sentinel启动方式:主从两端都要启动

redis-sentinel  /opt/redis/sentinel.conf    或 redis-server /opt/redis/sentinel.conf --sentinel     两种命令的效果完全相同

cat sentinel.conf   monitor处填主redis实例的IP地址    (注意配置文件中红色加粗部分,缺少的话故障转移时会出现 failover-abort-not-elected报错)

port
protected-mode yes
bind 0.0.0.0

daemonize yes
dir "/usr/local/etc"
logfile "/usr/local/etc/sentinel.log"
sentinel monitor mymaster 10.0.30.177 2
sentinel down-after-milliseconds mymaster
sentinel failover-timeout mymaster
sentinel parallel-syncs mymaster

#第4行:指定Sentinel去监视一个名为mymaster的Master,不同环境的redis集群此处的名称应该不同,否则启动后自动学习容易发生混淆。Master的IP地址为10.1.1.28,端口号为6379,最后的2表示当有2个Sentinel检测到Master异常时才会判定其失效,即只有当2个Sentinel都判定Master失效了 即O_DWON("客观"失效)才会自动迁移,如果Sentinel的数量不达标,则不会执行自动故障迁移。

#第5行:指定Sentinel判定Master断线的时间。(单位为毫秒,判定为主观下线SDOWN)

#第6行:在执行故障转移时, 最多可以有多少个从服务器同时对新的主服务器进行同步, 这个数字越小, 完成故障转移所需的时间就越长。这个数字设置为1,虽然完成故障转移所需的时间会变长,但是可以保证每次只有1个Slave处于不能处理命令请求的状态

#第7行:若sentinel在该配置值内未能完成failover操作(即故障时master/slave自动切换),则认为本次failover失败

另:一个sentinal可同时监控多个master,只要把4-8行重复多段,加以修改即可。

cat redis.conf

daemonize yes
pidfile "/var/run/redis.pid"
port
tcp-backlog
protected-mode yes
bind 0.0.0.0

timeout
tcp-keepalive
loglevel notice
logfile "/usr/local/etc/redis.log"
databases
save
save
save
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename "dump.rdb"
dir "/usr/local/etc" slave-serve-stale-data yes
slave-read-only yes
repl-diskless-sync no
repl-diskless-sync-delay
repl-disable-tcp-nodelay no
slave-priority
appendonly no
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
lua-time-limit
slowlog-log-slower-than
slowlog-max-len
latency-monitor-threshold
notify-keyspace-events ""
hash-max-ziplist-entries
hash-max-ziplist-value
list-max-ziplist-entries
list-max-ziplist-value
set-max-intset-entries
zset-max-ziplist-entries
zset-max-ziplist-value
hll-sparse-max-bytes
activerehashing yes
client-output-buffer-limit normal
client-output-buffer-limit slave 256mb 64mb
client-output-buffer-limit pubsub 32mb 8mb
hz
aof-rewrite-incremental-fsync yes

注意点:
1):首次启动时,先启动master端的sentinel,再启动slave端的sentinel
2):Sentinel 只在 server 端做主从切换,app端要自己开发(例如Jedis库的SentinelJedis,能够监控Sentinel的状态)
3):若Master已经被判定为下线,Sentinel已经选择了新的Master,也已经将old Master改成Slave,但是还没有将其改成new Master。若此时重启old Master,则Redis集群将处于无Master状态,此时只能手动修改配置文件,然后重新启动集群.

4):当发生故障转移时,sentinel.conf和redis.conf配置文件都会被CONFIG命令变更,

redis.conf:  slaveof  新master IP

sentinel.conf: sentinel monitor mymaster 新master IP 6379 2

所以切记在使用sentinel进行监控和故障转移时切勿在redis.conf配置文件中配置rename-command CONFIG "" ,该项表示禁用CONFIG命令

参考资料:http://www.redis.cn/topics/sentinel.html

              https://redis.io/topics/config

              http://download.redis.io/redis-stable/redis.conf

http://www.cnblogs.com/zhoujinyi/p/5570024.html

基于Sentinel的Redis3.2高可用方案的更多相关文章

  1. 深入理解Redis高可用方案-Sentinel

    Redis Sentinel是Redis的高可用方案.是Redis 2.8中正式引入的. 在之前的主从复制方案中,如果主节点出现问题,需要手动将一个从节点升级为主节点,然后将其它从节点指向新的主节点, ...

  2. Redis Sentinel(哨兵)主从高可用方案

    环境搭建 三台服务器: 192.168.126.100(master) 192.168.126.110(slaver) 192.168.126.120(slaver) 拷贝192.168.126.10 ...

  3. (转)基于Redis Sentinel的Redis集群(主从&Sharding)高可用方案

    转载自:http://warm-breeze.iteye.com/blog/2020413 本文主要介绍一种通过Jedis&Sentinel实现Redis集群高可用方案,该方案需要使用Jedi ...

  4. 基于Redis Sentinel的Redis集群(主从Sharding)高可用方案(转)

    本文主要介绍一种通过Jedis&Sentinel实现Redis集群高可用方案,该方案需要使用Jedis2.2.2及以上版本(强制),Redis2.8及以上版本(可选,Sentinel最早出现在 ...

  5. 基于Redis Sentinel的Redis集群(主从&Sharding)高可用方案

    本文主要介绍一种通过Jedis&Sentinel实现Redis集群高可用方案,该方案需要使用Jedis2.2.2及以上版本(强制),Redis2.8及以上版本(可选,Sentinel最早出现在 ...

  6. 基于GTID的Mysql-Mha高可用方案探索

    声明: 本篇文章内容整理来源于互联网以及本人自己的梳理总结,目的是从零到一的搭建起来mysql mha高可用架构. 一.软件概述 MHA(Master High Availability)目前在MyS ...

  7. Redis Sentinel主从高可用方案

    Redis Sentinel主从高可用方案 本文介绍一种通过Jed和Sentinel实现Redis集群(主从)的高可用方案,该方案需要使用Jedis2.2.2及以上版本(强制),Redis2.8及以上 ...

  8. 基于mycat高可用方案——数据库负载

    引言 传统企业级应用一般采取单台数据库,吞吐所有应用的读写,随着互联网的高速发展,以及微服务架构越来越普及,往往采用分库分表来支撑高速增长的大量业务数据吞吐.分库分表主要有两种方式:水平分表和垂直分库 ...

  9. 基于阿里云SLB/ESS/EIP/ECS/VPC的同城高可用方案演练

    今天基于阿里云SLB/ESS/EIP/ECS/VPC等产品进行了一次同城高可用方案演练: 基本步骤如下: 1. 在华东1创建VPC网络VPC1,在华东1可用区B和G各创建一个虚拟交换机vpc1_swi ...

随机推荐

  1. Spring 框架中 ModelAndView、Model、ModelMap 的区别

    Model Model 是一个接口, 其实现类为ExtendedModelMap,继承了ModelMap类. public class ExtendedModelMap extends ModelMa ...

  2. 打开Visual Studio 2012的解决方案 连接 Dynamics CRM 2011 的Connect to Dynamics CRM Server 在其工具下没有显示

    一.使用TFS 代码管理,发现Visual Studio 2012 菜单栏 工具下的Connect to Dynamics CRM Server 没有显示. 平常打开VS下的工具都会出现Connect ...

  3. Windows Phone 的这几年

    Windows Phone 从2010年10月发布,到如今已经有3年多了.从那时坚持到现在的用户和开发者一定感慨很多吧. 一直关注着这个让人既爱又恨的平台的发展,笔者不仅是使用者,也同时是开发者,这里 ...

  4. nginx负载

    一. Nginx反向代理与负载均衡概念简介 • 严格地说,Nginx仅仅是作为Nginx Proxy反向代理使用的,因为这个反向代理功能表现的效果是负载均衡集群的效果,所以本文称之为Nginx负载均衡 ...

  5. ERROR 2059 (HY000): Authentication plugin 'caching_sha2_password' cannot be loaded

    问题: 连接Docker启动的mysql出现:ERROR 2059 (HY000): Authentication plugin 'caching_sha2_password' cannot be l ...

  6. setting.xml配置文件 --转载

    转载出处:http://www.cnblogs.com/yakov/archive/2011/11/26/maven2_settings.html 在此,简单的说下 setting.xml 和 pom ...

  7. request笔记记录

    1.https请求报错解决方法,添加verify=False参数 r = requests.get(json=payload, headers=headers,verify=False) 1)由于这里 ...

  8. [转]C# 系统应用之鼠标模拟技术及自动操作鼠标

    原文网址: C# 系统应用之鼠标模拟技术及自动操作鼠标        游戏程序的操作不外乎两种——键盘输入控制和鼠标输入控制,几乎所有游戏中都使用鼠标来改变角色的位置和方向,本文主要是讲述如何使用C# ...

  9. XStream和Dom4j的区别

    对于搞技术的人来说,xml文件的处理应该并不陌生吧,先总述下,个人感觉XStream在处理XML文件和JavaBean对象互转时比较好,dom4j对常用的xml配置文件操作比较好点:首先,Dom4j ...

  10. shell脚本函数

    不调用就不执行 调用就执行 调用时候的$1是指执行时候的参数1 调用之后的$是位置参数