基于sentinel的redis的HA方案
2015-12-28 16:27
267 查看
一、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结构。
单M-S结构适用于不同用户数据存在关联,但应用可以实现读写分离的业务模式。Master主要提供写操作,Slave主要提供读操作,充分利用硬件资源。
双(多)M-S结构适用于用户间不存在或者存在较少的数据关联的业务模式,读写效率是单M-S的两(多)倍,但要求故障时单台服务器能够承担两个Mater Redis的资源需求。
三、配置部署
单M-S结构和双M-S结构配置相差无几,下面以双M-S结构配置为例。
在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
#……
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
redis-server redis-1M.conf
redis-server redis-2S.conf
Server-1S启动redis
redis-server redis-1S.conf
redis-server redis-2M.conf
检测同步
Master日志检查:
[28162] 10 Nov 23:32:11.810 * DB loaded from append only file: 0.000 seconds
[28162] 10 Nov 23:32:11.810 * The server is now ready to accept connections on port 6379
[28162] 10 Nov 23:32:35.360 * Slave ask for synchronization
[28162] 10 Nov 23:32:35.360 * Starting BGSAVE for SYNC
[28162] 10 Nov 23:32:35.361 * Background saving started by pid 28170
[28170] 10 Nov 23:32:35.373 * DB saved on disk
[28170] 10 Nov 23:32:35.375 * RDB: 0 MB of memory used by copy-on-write
[28162] 10 Nov 23:32:35.437 * Background saving terminated with success
[28162] 10 Nov 23:32:35.438 * Synchronization with slave succeeded
Slave日志检查:
[28091] 10 Nov 23:27:15.908 * DB loaded from append only file: 0.001 seconds
[28091] 10 Nov 23:27:15.908 * The server is now ready to accept connections on port 6389
[28091] 10 Nov 23:27:15.944 * Connecting to MASTER...
[28091] 10 Nov 23:27:15.947 * MASTER <-> SLAVE sync started
[28091] 10 Nov 23:27:15.951 * Non blocking connect for SYNC fired the event.
[28091] 10 Nov 23:27:15.952 * Master replied to PING, replication can continue...
[28091] 10 Nov 23:27:15.990 * MASTER <-> SLAVE sync: receiving 50 bytes from master
[28091] 10 Nov 23:27:15.990 * MASTER <-> SLAVE sync: Loading DB in memory
[28091] 10 Nov 23:27:15.991 * MASTER <-> SLAVE sync: Finished with success
[28091] 10 Nov 23:27:15.993 * Background append only file rewriting started by pid 28094
[28094] 10 Nov 23:27:15.998 * SYNC append only file rewrite performed
[28094] 10 Nov 23:27:15.998 * AOF rewrite: 0 MB of memory used by copy-on-write
[28091] 10 Nov 23:27:16.047 * Background AOF rewrite terminated with success
[28091] 10 Nov 23:27:16.047 * Parent diff successfully flushed to the rewritten AOF (0 bytes)
[28091] 10 Nov 23:27:16.048 * Background AOF rewrite finished successfully
启动sentinel服务
redis-server sentinel-1M.conf --sentinel
[28156] 10 Nov 23:33:22.337 * +slave slave 192.168.84.129:6389 192.168.84.129 6389 @server-1S 192.168.84.128 6379
[28156] 10 Nov 23:39:37.071 # +sdown sentinel 192.168.84.128:26389 192.168.84.128 26389 @server-1S 192.168.84.128 6379
[28156] 10 Nov 23:39:37.072 # +sdown sentinel 192.168.84.128:26389 192.168.84.128 26389 @server-1M 192.168.84.129 6379
[28156] 10 Nov 23:40:05.438 # -sdown sentinel 192.168.84.128:26389 192.168.84.128 26389 @server-1S 192.168.84.128 6379
[28156] 10 Nov 23:40:05.438 # -sdown sentinel 192.168.84.128:26389 192.168.84.128 26389 @server-1M 192.168.84.129 6379
[28156] 10 Nov 23:40:10.262 * -dup-sentinel masterserver-1S 192.168.84.128 6379 #duplicate of 192.168.84.128:26389 or e453a45a5e1421519dcbe00a199f203579b27b0f
[28156] 10 Nov 23:40:10.263 * +sentinel sentinel 192.168.84.128:26389 192.168.84.128 26389 @server-1S 192.168.84.128 6379
[28156] 10 Nov 23:40:10.263 * -dup-sentinel masterserver-1M 192.168.84.129 6379 #duplicate of 192.168.84.128:26389 or e453a45a5e1421519dcbe00a199f203579b27b0f
[28156] 10 Nov 23:40:10.263 * +sentinel sentinel 192.168.84.128:26389 192.168.84.128 26389 @server-1M 192.168.84.129 6379
redis-server sentinel-1S.conf --sentinel
[16383] 10 Nov 23:40:05.499 * +slave slave 192.168.84.129:6389 192.168.84.129 6389 @server-1S 192.168.84.128 6379
[16383] 10 Nov 23:40:05.500 * +slave slave 192.168.84.128:6389 192.168.84.128 6389 @server-1M 192.168.84.129 6379
[16383] 10 Nov 23:40:06.098 * +sentinel sentinel 192.168.84.129:26379 192.168.84.129 26379 @server-1S 192.168.84.128 6379
[16383] 10 Nov 23:40:08.404 * +sentinel sentinel 192.168.84.129:26379 192.168.84.129 26379 @server-1M 192.168.84.129 6379
[28156] 11 Nov 00:42:48.431 # +sdown masterserver-1M 192.168.84.129 6379
[28156] 11 Nov 00:42:48.431 # +odown masterserver-1M 192.168.84.129 6379 #quorum 1/1
[28156] 11 Nov 00:42:56.570 # +failover-detected masterserver-1M 192.168.84.129 6379
[28156] 11 Nov 00:42:56.670 # +failover-end masterserver-1M 192.168.84.129 6379
[28156] 11 Nov 00:42:56.670 # +switch-masterserver-1M 192.168.84.129 6379 192.168.84.128 6389
[28156] 11 Nov 00:42:57.055 * +sentinel sentinel 192.168.84.128:26389 192.168.84.128 26389 @server-1M 192.168.84.128 6389
[28156] 11 Nov 00:43:01.688 # +sdown slave 192.168.84.129:6379 192.168.84.129 6379 @server-1M 192.168.84.128 6389
四、备份恢复
RDB是在某个时间点将内存中的所有数据的快照保存到磁盘上,在数据恢复时,可以恢复备份时间以前的所有数据,但无法恢复备份时间点后面的数据。
AOF是以协议文本的方式,将所有对数据库进行过写入的命令(及其参数)记录到 AOF 文件,以此达到记录数据库状态的目的。优点是基本可以实现数据无丢失(缓存的数据有可能丢失),缺点是随着数据量的持续增加,AOF文件也会越来越大。
在保证数据安全的情况下,尽量避免因备份数据消耗过多的Redis资源,采用如下备份策略:
Master端:不采用任何备份机制
Slave端:采用AOF(严格数据要求时可同时开启RDB),每天将AOF文件备份至备份服务器。
为了最大限度减少Master端的资源干扰,将备份相关全部迁移至Slave端完成。同时这样也有缺点,当Master挂掉后,应用服务切换至Slave端,此时的Slave端的负载将会很大。目前Redis不支持RDB和AOF参数动态修改,需要重启Redis生效,希望能在新的版本中实现更高效的修改方式。
· 当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".
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
cat sentinel.conf
#第4行:指定Sentinel去监视一个名为 mymaster 的Master,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行:表示如果15秒后,mysater仍没活过来,则启动failover,从剩下的slave中选一个升级为master
另:一个sentinal可同时监控多个master,只要把4-8行重复多段,加以修改即可。
cat redis.conf
View Code
注意点:
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状态,此时只能手动修改配置文件,然后重新启动集群.
· 监控(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-1Mvi 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启动redisredis-server redis-1M.conf
redis-server redis-2S.conf
Server-1S启动redis
redis-server redis-1S.conf
redis-server redis-2M.conf
检测同步
Master日志检查:
[28162] 10 Nov 23:32:11.810 * DB loaded from append only file: 0.000 seconds
[28162] 10 Nov 23:32:11.810 * The server is now ready to accept connections on port 6379
[28162] 10 Nov 23:32:35.360 * Slave ask for synchronization
[28162] 10 Nov 23:32:35.360 * Starting BGSAVE for SYNC
[28162] 10 Nov 23:32:35.361 * Background saving started by pid 28170
[28170] 10 Nov 23:32:35.373 * DB saved on disk
[28170] 10 Nov 23:32:35.375 * RDB: 0 MB of memory used by copy-on-write
[28162] 10 Nov 23:32:35.437 * Background saving terminated with success
[28162] 10 Nov 23:32:35.438 * Synchronization with slave succeeded
Slave日志检查:
[28091] 10 Nov 23:27:15.908 * DB loaded from append only file: 0.001 seconds
[28091] 10 Nov 23:27:15.908 * The server is now ready to accept connections on port 6389
[28091] 10 Nov 23:27:15.944 * Connecting to MASTER...
[28091] 10 Nov 23:27:15.947 * MASTER <-> SLAVE sync started
[28091] 10 Nov 23:27:15.951 * Non blocking connect for SYNC fired the event.
[28091] 10 Nov 23:27:15.952 * Master replied to PING, replication can continue...
[28091] 10 Nov 23:27:15.990 * MASTER <-> SLAVE sync: receiving 50 bytes from master
[28091] 10 Nov 23:27:15.990 * MASTER <-> SLAVE sync: Loading DB in memory
[28091] 10 Nov 23:27:15.991 * MASTER <-> SLAVE sync: Finished with success
[28091] 10 Nov 23:27:15.993 * Background append only file rewriting started by pid 28094
[28094] 10 Nov 23:27:15.998 * SYNC append only file rewrite performed
[28094] 10 Nov 23:27:15.998 * AOF rewrite: 0 MB of memory used by copy-on-write
[28091] 10 Nov 23:27:16.047 * Background AOF rewrite terminated with success
[28091] 10 Nov 23:27:16.047 * Parent diff successfully flushed to the rewritten AOF (0 bytes)
[28091] 10 Nov 23:27:16.048 * Background AOF rewrite finished successfully
启动sentinel服务
redis-server sentinel-1M.conf --sentinel
[28156] 10 Nov 23:33:22.337 * +slave slave 192.168.84.129:6389 192.168.84.129 6389 @server-1S 192.168.84.128 6379
[28156] 10 Nov 23:39:37.071 # +sdown sentinel 192.168.84.128:26389 192.168.84.128 26389 @server-1S 192.168.84.128 6379
[28156] 10 Nov 23:39:37.072 # +sdown sentinel 192.168.84.128:26389 192.168.84.128 26389 @server-1M 192.168.84.129 6379
[28156] 10 Nov 23:40:05.438 # -sdown sentinel 192.168.84.128:26389 192.168.84.128 26389 @server-1S 192.168.84.128 6379
[28156] 10 Nov 23:40:05.438 # -sdown sentinel 192.168.84.128:26389 192.168.84.128 26389 @server-1M 192.168.84.129 6379
[28156] 10 Nov 23:40:10.262 * -dup-sentinel masterserver-1S 192.168.84.128 6379 #duplicate of 192.168.84.128:26389 or e453a45a5e1421519dcbe00a199f203579b27b0f
[28156] 10 Nov 23:40:10.263 * +sentinel sentinel 192.168.84.128:26389 192.168.84.128 26389 @server-1S 192.168.84.128 6379
[28156] 10 Nov 23:40:10.263 * -dup-sentinel masterserver-1M 192.168.84.129 6379 #duplicate of 192.168.84.128:26389 or e453a45a5e1421519dcbe00a199f203579b27b0f
[28156] 10 Nov 23:40:10.263 * +sentinel sentinel 192.168.84.128:26389 192.168.84.128 26389 @server-1M 192.168.84.129 6379
redis-server sentinel-1S.conf --sentinel
[16383] 10 Nov 23:40:05.499 * +slave slave 192.168.84.129:6389 192.168.84.129 6389 @server-1S 192.168.84.128 6379
[16383] 10 Nov 23:40:05.500 * +slave slave 192.168.84.128:6389 192.168.84.128 6389 @server-1M 192.168.84.129 6379
[16383] 10 Nov 23:40:06.098 * +sentinel sentinel 192.168.84.129:26379 192.168.84.129 26379 @server-1S 192.168.84.128 6379
[16383] 10 Nov 23:40:08.404 * +sentinel sentinel 192.168.84.129:26379 192.168.84.129 26379 @server-1M 192.168.84.129 6379
4、故障模拟检测
模拟redis-1M(Master 192.168.84.129 6379)故障,sentinel自动检测状态,然后切换至redis-1S(Slave 192.168.84.128 6389),并将redis-1M转移为redis-1S的slave,状态为+sdown。[28156] 11 Nov 00:42:48.431 # +sdown masterserver-1M 192.168.84.129 6379
[28156] 11 Nov 00:42:48.431 # +odown masterserver-1M 192.168.84.129 6379 #quorum 1/1
[28156] 11 Nov 00:42:56.570 # +failover-detected masterserver-1M 192.168.84.129 6379
[28156] 11 Nov 00:42:56.670 # +failover-end masterserver-1M 192.168.84.129 6379
[28156] 11 Nov 00:42:56.670 # +switch-masterserver-1M 192.168.84.129 6379 192.168.84.128 6389
[28156] 11 Nov 00:42:57.055 * +sentinel sentinel 192.168.84.128:26389 192.168.84.128 26389 @server-1M 192.168.84.128 6389
[28156] 11 Nov 00:43:01.688 # +sdown slave 192.168.84.129:6379 192.168.84.129 6379 @server-1M 192.168.84.128 6389
四、备份恢复
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".
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
cat sentinel.conf
1 port 26379 2 daemonize yes 3 dir "/tmp" 4 sentinel monitor mymaster 10.1.1.28 6379 2 5 sentinel down-after-milliseconds mymaster 5000 6 sentinel parallel-syncs mymaster 1 7 sentinel failover-timeout mymaster 15000 8 logfile "/opt/redis/sentinel.log"
#第4行:指定Sentinel去监视一个名为 mymaster 的Master,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行:表示如果15秒后,mysater仍没活过来,则启动failover,从剩下的slave中选一个升级为master
另:一个sentinal可同时监控多个master,只要把4-8行重复多段,加以修改即可。
cat redis.conf
View Code
注意点:
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状态,此时只能手动修改配置文件,然后重新启动集群.
相关文章推荐
- redis error MISCONF Redis is configured to save RDB snapshots
- java操作redis
- Redis的简单介绍及在Windows下环境搭建
- redis 的性能及高版本配置
- Redis 未授权访问配合 SSH key 文件利用分析
- Java使用Pipeline对Redis批量读写(hmset&hgetall)
- 看了几天的redis稍微总结一下数据类型及命令(字符型)
- Nosql之redis学习(四)
- Redis整合Spring结合使用缓存实例
- Nosql之redis学习(三)
- NoSql之redis学习(二)
- Redis学习笔记(一) 初识 Redis
- PHP-redis中文文档
- PHP使用Redis一
- php-redis分页
- PHP安装redis扩展
- spring与redis集成之aop整合方案
- Redis相关命令及Jedis的demo(转)
- CentOS7下源码安装Redis系统服务配置
- redis server配置文件参数说明