您的位置:首页 > 数据库 > Redis

redis哨兵模式和主从复制

2017-09-05 19:33 1201 查看
redis的主从架构,如果master故障了,需要手动将slave切换成master继续服务,为此可以用哨兵。
哨兵的作用:
1.监控redis进行状态,包括maste和slave
2.master宕机后,自动主从切换

问题:主从切换后,配置文件并没有改变啊?--你需要kill -9 redis进程再重启一下就会发现配置文件监控的主节点信息改变了
master_redis.conf slave_redis.conf 和 sentinel.conf 的内容将发生改变,
master_redis.conf 会多一行slaveof的配置,sentinel.conf的监控目标会随之调换

哨兵的部署:
添加配置文件sentinel.conf,启动哨兵即可。

哨兵配置文件详解:
1. sentinel监听端口,默认是26379,可以修改。
port 26379
 
2.sentinel monitor <master-name> <ip> <redis-port> <quorum>
告诉sentinel去监听地址为ip:port的一个master,这里的master-name可以自定义,quorum是一个数字,指明当有多少个sentinel认为一个master失效时,master才算真正失效。master-name只能包含英文字母,数字,和“.-_”这三个字符需要注意的是master-ip
要写真实的ip地址而不要用回环地址(127.0.0.1)。
配置示例:
sentinel monitor mymaster 192.168.0.5 6379 2
 
3.sentinel
auth-pass <master-name> <password>
设置连接master和slave时的密码,注意的是sentinel不能分别为master和slave设置不同的密码,因此master和slave的密码应该设置相同。
配置示例:
sentinel auth-pass mymaster 0123passw0rd
 
4.sentinel down-after-milliseconds <master-name> <milliseconds> 
这个配置项指定了需要多少失效时间,一个master才会被这个sentinel主观地认为是不可用的。 单位是毫秒,默认为30秒
配置示例:
sentinel down-after-milliseconds mymaster 30000
 
5.sentinel parallel-syncs <master-name> <numslaves> 
这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步,这个数字越小,完成failover所需的时间就越长,但是如果这个数字越大,就意味着越 多的slave因为replication而不可用。可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
配置示例:
sentinel parallel-syncs mymaster 1
 
6. sentinel failover-timeout <master-name> <milliseconds>
failover-timeout 可以用在以下这些方面: 
      1. 同一个sentinel对同一个master两次failover之间的间隔时间。
      2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
      3.当想要取消一个正在进行的failover所需要的时间。  
      4.当进行failover时,配置所有slaves指向新的master所需的最大时间。不过,即使过了这个超时,slaves依然会被正确配置为指向master,但是就不按parallel-syncs所配置的规则来了。
配置示例:
sentinel failover-timeout mymaster1 20000
 
7.sentinel的notification-script和reconfig-script是用来配置当某一事件发生时所需要执行的脚本,可以通过脚本来通知管理员,例如当系统运行不正常时发邮件通知相关人员。对于脚本的运行结果有以下规则:
        若脚本执行后返回1,那么该脚本稍后将会被再次执行,重复次数目前默认为10
        若脚本执行后返回2,或者比2更高的一个返回值,脚本将不会重复执行。
        如果脚本在执行过程中由于收到系统中断信号被终止了,则同返回值为1时的行为相同。
        一个脚本的最大执行时间为60s,如果超过这个时间,脚本将会被一个SIGKILL信号终止,之后重新执行。
1).sentinel notification-script <master-name> <script-path> 
通知型脚本:当sentinel有任何警告级别的事件发生时(比如说redis实例的主观失效和客观失效等等),将会去调用这个脚本,这时这个脚本应该通过邮件,SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时,将传给脚本两个参数,一个是事件的类型,一个是事件的描述。如果sentinel.conf配置文件中配置了这个脚本路径,那么必须保证这个脚本存在于这个路径,并且是可执行的,否则sentinel无法正常启动成功。
  配置示例:
 sentinel notification-script mymaster /var/redis/notify.sh
 
2).sentinel client-reconfig-script <master-name> <script-path>
 当一个master由于failover而发生改变时,这个脚本将会被调用,通知相关的客户端关于master地址已经发生改变的信息。以下参数将会在调用脚本时传给脚本:
       <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
目前<state>总是“failover”, <role>是“leader”或者“observer”中的一个。 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的。这个脚本应该是通用的,能被多次调用,不是针对性的。
   配置示例:
   sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

哨兵的工作方式:
1.每个哨兵每秒一次的频率向他监控的master slave以及其他哨兵发送一个ping命令
2.如果一个实例距离最后一次有效回复ping命令的时间超过了down-after-milliseconds所指定的值,那么这个实例会被哨兵标记为主观下线。
3.如果一个master被标记为主观下线,正在监视这个master的所有哨兵会已每秒1次的频率确认master的确进入了主观下线,当有足够数量的哨兵在指定时间范围内确认master进入了主观下线状态,master会被标记为客观下线。
4.当master被标记为客观下线后,哨兵想下线的master的所有slave发送info命令的频率会由每10秒1次变成每秒一次

哨兵的failover:
当master真正下线,哨兵进行faillover的时候,会选举一个哨兵进行故障恢复,并且同一时刻只会有一个哨兵进行master的故障恢复,这个哨兵获取了宕机的master的最新配置版本号,若failover等到时间过去后,他没有恢复,在选举另一个哨兵出发故障恢复,版本号也会换。哨兵保证了活跃性,最终会有一个哨兵被授权去进行faillover,保证了安全性,每个试图去failover的同一个master的哨兵都会得到一个独一无二的版本号。一旦一个哨兵成功的对master进行了故障恢复,他会将关于master的最新配置信息通过广播形式通知给其他哨兵,其他哨兵则更新对应的master配置。

哨兵的自动发现机制:
1.不需要在哨兵中配置master的所有slave地址,哨兵会通过询问master来得到slave地址
2.不需要在哨兵中配置其他哨兵的信息,每个哨兵通过向每个master和slave的发布订阅频道__sentinel__:hello每秒发送一次消息来宣布自己的存在,当检测到新的哨兵后,其他哨兵会将其加入到自身维护的master监控列表中。每个哨兵发送的消息也包含了当前维护的最新master的配置,如果哨兵发现自己的配置版本低于接收到的消息的配置版本号,会更新自己的master配置。

哨兵的监控信息:
1.启动哨兵./redis-sentinel /Users/yp-tc-m-7129/redis/redis-3.0.7/redis_cluster/7009/sentinel.conf
后,监控状态
976:X 05 Sep 09:53:05.316 # +monitor master mymaster 127.0.0.1 7009 quorum 1
976:X 05 Sep 09:53:06.320 * +slave slave 127.0.0.1:7010 127.0.0.1 7010 @ mymaster 127.0.0.1 7009
2.master当即后,从变成了主
监控状态:
976:X 05 Sep 09:55:30.706 # +sdown master mymaster 127.0.0.1 7009
976:X 05 Sep 09:55:30.706 # +odown master mymaster 127.0.0.1 7009 #quorum 1/1
976:X 05 Sep 09:55:30.706 # +new-epoch 1
976:X 05 Sep 09:55:30.706 # +try-failover master mymaster 127.0.0.1 7009
976:X 05 Sep 09:55:30.709 # +vote-for-leader 2368ecf36b91d5a467dfb4cde3d718d02b1fd613 1
976:X 05 Sep 09:55:30.709 # +elected-leader master mymaster 127.0.0.1 7009
976:X 05 Sep 09:55:30.709 # +failover-state-select-slave master mymaster 127.0.0.1 7009
976:X 05 Sep 09:55:30.777 # +selected-slave slave 127.0.0.1:7010 127.0.0.1 7010 @ mymaster 127.0.0.1 7009
976:X 05 Sep 09:55:30.777 * +failover-state-send-slaveof-noone slave 127.0.0.1:7010 127.0.0.1 7010 @ mymaster 127.0.0.1 7009
976:X 05 Sep 09:55:30.838 * +failover-state-wait-promotion slave 127.0.0.1:7010 127.0.0.1 7010 @ mymaster 127.0.0.1 7009
976:X 05 Sep 09:55:31.761 # +promoted-slave slave 127.0.0.1:7010 127.0.0.1 7010 @ mymaster 127.0.0.1 7009
976:X 05 Sep 09:55:31.761 # +failover-state-reconf-slaves master mymaster 127.0.0.1 7009
976:X 05 Sep 09:55:31.829 # +failover-end master mymaster 127.0.0.1 7009
976:X 05 Sep 09:55:31.829 # +switch-master mymaster 127.0.0.1 7009 127.0.0.1 7010
976:X 05 Sep 09:55:31.829 * +slave slave 127.0.0.1:7009 127.0.0.1 7009 @ mymaster 127.0.0.1 7010
976:X 05 Sep 09:56:01.859 # +sdown slave 127.0.0.1:7009 127.0.0.1 7009 @ mymaster 127.0.0.1 7010

127.0.0.1:7010> info replication
# Replication
role:master
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
3.master恢复后:7009变成了7010的从
976:X 05 Sep 09:55:31.829 # +failover-end master mymaster 127.0.0.1 7009
976:X 05 Sep 09:55:31.829 # +switch-master mymaster 127.0.0.1 7009 127.0.0.1 7010
976:X 05 Sep 09:55:31.829 * +slave slave 127.0.0.1:7009 127.0.0.1 7009 @ mymaster 127.0.0.1 7010
976:X 05 Sep 09:56:01.859 # +sdown slave 127.0.0.1:7009 127.0.0.1 7009 @ mymaster 127.0.0.1 7010
976:X 05 Sep 09:59:17.957 # -sdown slave 127.0.0.1:7009 127.0.0.1 7009 @ mymaster 127.0.0.1 7010
976:X 05 Sep 09:59:27.874 * +convert-to-slave slave 127.0.0.1:7009 127.0.0.1 7009 @ mymaster 127.0.0.1 7010

127.0.0.1:7009> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:7010
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:4112
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:7009>
4.查看启动哨兵的状态:
yp-tc-m-7129deMacBook-Air:src yp-tc-m-7129$ ./redis-cli -h 127.0.0.1 -p 26383 info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
master0:name=mymaster,status=ok,address=127.0.0.1:7010,slaves=1,sentinels=1
yp-tc-m-7129deMacBook-Air:src yp-tc-m-7129$
启动另一个哨兵后,在查看状态变为2:
./redis-cli -h 127.0.0.1 -p 26384 info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
master0:name=mymaster,status=ok,address=127.0.0.1:7010,slaves=1,sentinels=2

redis数据丢失的情况:



刚开始3是主,由于网络原因,3没有宕机但是3无法向1,2同步数据的时候,3被哨兵标记为主观下线,并重新选举1为主,
这时候哨兵更新了监控的主节点信息,并且1,2之间也确认了主从关系,但是1,2和3的网络并没有连接,3没有收到信息,仍然会继续写入数据,后来网络恢复了,3中作为从节点,网络中断过程中写入3的数据将会丢失。
为此我们可以配置
min-slaves-to-write
1min-slaves-max-lag 10
表示当主节点没有向从节点写数据的时候,主节点将拒绝写入请求。但是这也有缺点,主节点没有向从节点写数据,很有可能是
1.网络中断,1,3无法通信
2.从节点自己宕机了,我主节点不写入数据了?
3.主节点宕机了

slave选举的过程:
1.slave与master的断开次数,选举出候选人列表
2.slave的优先级,优先级越小,排名越靠前(优先级是0将永远不会被选举为master)
3.slave复制的下标,即slave从master接受的复制数据越多,排名越靠前
4.进程小的id

配置主从关系,7009-7010,
方式1.进入7009.输入命令 slaveof 127.0.0.1 7010即可。
这时候启动7009的监控,发现多了几行配置文件:
yp-tc-m-7129deMacBook-Air:7010 yp-tc-m-7129$ cat sentinel.conf
port 26383
sentinel monitor mymaster 127.0.0.1 7010 1
sentinel failover-timeout mymaster 900000
sentinel config-epoch mymaster 0
sentinel leader-epoch mymaster 0
#sentinel auth-pass mymaster 123456  #如果你的redis集群有密码
# Generated by CONFIG REWRITE
dir "/Users/yp-tc-m-7129/redis/redis-3.0.7/src"
sentinel known-slave mymaster 127.0.0.1 7009
sentinel current-epoch 0
yp-tc-m-7129deMacBook-Air:7010 yp-tc-m-7129$
但是这是一次生效,redis.conf文件中并没有slaveof 127.0.0.1 7010 ,redis实例重启的时候会恢复原样。
方式2).修改7009的redis.conf的配置文件加上slaveof 127.0.0.1 7010 ,
在进入7009,可以看到不能写入数据了,并且有了主节点,但是需要重启redis(kill,然后redis-server),才会在在哨兵文件中看到更新的信息:
yp-tc-m-7129deMacBook-Air:7009 yp-tc-m-7129$ cat sentinel.conf
port 26384
sentinel monitor master1 127.0.0.1 7009 1
sentinel failover-timeout master1 900000
sentinel config-epoch master1 0
sentinel leader-epoch master1 1
#sentinel auth-pass mymaster 123456  #如果你的redis集群有密码
# Generated by CONFIG REWRITE
dir "/Users/yp-tc-m-7129/redis/redis-3.0.7/src"
sentinel current-epoch 1

要想在主机没有宕机的情况下,解除哨兵模式监控的主从节点:
方式1)在7009从节点上发送命令: slaveof no one,然后哨兵配置文件的监控信息会自动变化,可以写入数据了,这种方式redis启用后无效
方式2)如果是配置文件写slaveof的方式,要想在主机没有宕机的情况下,接触哨兵监控的主从节点,需要kill -9 redis 7009 7010的实例和哨兵,
还需要手动注释slaveof
还需要修改哨兵配置文件
检查有没有在文件中默认的新增信息,还需要进入7009,检查他的节点信息info replication,然后重启7009 7010即可。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: