Redis中的sentinel系统用于管理多个Redis服务器,该系统执行以下三个任务:
1.监控:sentinel会不断的监控你的主服务器与从服务器的状态
2.提醒:当被监控的某个redis服务器出现异常时,sentinel可以通过API向管理员或者其他程序发送通知
3.故障迁移:当一个主服务器不能正常工作时,sentinel会开始进行一次自动故障迁移操作,它会把失效的主服务器的其中一台从服务器升级为主服务器,并让其它的从服务器指向这台新的主服务器。
启动sentinel
对于redis-sentinel程序,你可以用一下命令来启动Sentinel系统:
redis-sentinel /path/to/sentinel.conf
对于redis-server程序,你可以用以下命令来启动一个运行在Sentinel模式下的Redis服务器:
redis-server sentinel.conf --sentinel
2种方法都可以启动一个sentinel实例
启动Sentinel实例必须指定相应的配置文件,系统会使用配置文件来保存Sentinel的状态,并在Sentinel重启时通过载入配置文件来进行状态还原。
如果在重启的时候没有找到Sentinel配置文件,那么Sentinel会拒绝启动。
配置Sentinel
Redis配置文件中包含了一个名为Sentinel.conf的文件,这个文件是一个带有Sentinel配置文件的详情信息。
第一行的配置是Sentinel去监视了一个名为mymaster的主服务器,这个服务器的地址是127.0.0.1 端口号是6379 ,而将这个主服务器判断失效的至少需要2台Sentinel同意不过要注意的是,无论你设置多少个Sentinel同意才能判断一个服务器失效,一个Sentinel都需要获得系统中多数Sentinel的支持,才能发起一次自动故障迁移,换句话说就是,在只有少数Sentinel进程正常运行的情况,Sentinel是不能执行自动故障迁移。
其他选项的基本格式如下:
sentinel <选项名字> <主服务器名字> <选项的值>
down-after-milliseconds 选项指定了Sentinel认为服务器已经断线所需要的毫秒数。
如果服务器在给定的毫秒之内,没有返回Sentinel发送的ping命令的回复,那么Sentinel会将该服务器标记为主观下线。
不过一台Sentinel标记为主观下线不一定会引起服务器的自动故障迁移,只有在足够数量的Sentinel都将一个服务器标记为主观下线之后,服务器才会标记会客观下线,这时才会自动故障迁移。
将服务器标记为客观下线所需的Sentinel数量对主服务器的配置决定的。
paraller-syncs 这个变量指定了在执行故障过程中,最多可以有多少个从服务器进行同步,这个数字越小,完成故障迁移的时间就越长。
主观下线与客观下线
1.主观下线:指的是单个Sentinel实例对服务器做出下线的判断
2.客观下线:指的是多个Sentinel实例对服务器做出下线判断,并且通过Sentinelis-master-doen-by-addr命令相互交流之后,得出下线的判断。
如果一个服务器没有在Sentinelis-master-after-milliseconds选项指定的时间内,对向它发送ping命令的Sentinel返回一个有效的回复,那么Sentinel就会把这个服务器标记为主观下线。
注意,一个服务器必须在master-down-after-milliseconds选项的值为30000毫秒,那么只要服务器在29内收到了回复,那么就会认为该服务器仍然
处于正常状态。
从主观下线到客观下线使用的是流言协议。如果Sentinel在给定的时间范围内,从其他的Sentinel那里收到了足够数量的主服务器下线的通知,那么Sentinel就会将主服务器从主观下线改为客观下线。如果之后其它的Sentinel不再报告主服务器已经下线,那么主观下线就会被移除。
客观下线只适合主服务器:对于任何的Redis实例,Sentinel在将他们判断为下线前不需要进行协商,所以从服务器或者其它的Sentinel永远不会客观下线。
只要一个Sentinel发现某个主服务器进入了客观下线,那么这个Sentinel就会被其它的Sentinel推送出,并对失效的主服务器进程故障迁移。
每个Sentinel都需要定期执行的任务
1.每个Sentinel以每秒钟一次的频率向它所知的主武器,从服务器以及其它的Sentinel发送一个ping命令。
2.如果一个实例距离最后一次回复时间大于down-after-milliseconds选项所指定的值,那么这个实例会被Sentinel标记会主观下线
3.如果主服务确定进入了主观下线的状态时,那么监听这个主服务器的Sentinel会以每秒一次的频率确定主服务器的确进入了主观下线。
4.如果主服务器被标记为主观下线,并且有足够数量的Sentinel在指定的范围时间内同意这一判断,那么该主服务器会标记为客观下线。
5.在一般情况下,每个Sentinel会以10秒的频率向主从服务器发送info命令,当一个主服务器被Sentinel标记为客观下线时,那么Sentinel会向从服务器由原来的10秒改为每秒一次。
6.当没有足够的Sentinel标记主服务器为客观下线,那么客观下线状态就会被移除。
自动发现Sentinel和从服务器
你无效为运行的每个Sentinel分别配置其它的Sentinel的地址,因为Sentinel可以通过发布与订阅功能来发现正在监视相同的主服务器的其它Sentinel,这一功能是通过频道——Sentinel_:hello 发送信息来实现的。
与此类似,你也不列出主服务器下所有的从服务器,因为Sentinel可以通过主服务器来获得所有的从服务器的信息。
Sentinel API
在默认情况下,Sentinel监听的26379端口;
有两种方法可以和Sentinel进行通信:
1.第一种方法就是直接发送命令来查询被监听的Redis服务器当前状态,以及Sentinel所知道的关于其他Sentinel的信息
2.另外一种就是使用发布与订阅频道,通过接收Sentinel发送的通知:当故障发生转移操作,或者某个被监听的服务器被判断为主观下线或者客观下线时,Sentinel就会发送想要的。
发布与订阅信息
客户端可以将Sentinel看做是一个只订阅了Redis服务器,你不可以发送Publish命令,但你可以使用subscribe命令或者psubscribe命令,通过订阅的频道来获取相应的事件提醒。
故障迁移
一次故障迁移操作有以下步骤组成:
1.发现主服务器已经进入了客观下线状态。
2.如果当选失败之后,那么会在设定的故障迁移超时时间的两倍之后,重新尝试当选。如果当选成功,那么执行以下步骤。
3.选出一个从服务器,并将它升级为主服务器。
4.向被当选的从服务器发送slaveof no one 命令,将它转变成主服务器。
5.通过发布与订阅功能,将更新后的配置传播给所有其他的Sentinel,其他的Sentinel对它们自己的配置进行更新。
6.向已下线主服务器的从服务器发送slave命令,让它们去复制新的主服务器。
7.当所有的从服务器已经开始复制新的主服务器时,领头的Sentinel终止这次故障迁移操作。