Linux下redis的哨兵集群
Redis-sentinel基础
redis-sentinel是redis官方推荐的高可用性解决方案。
当用redis做master-slave的高可用时， 如果master本身宕机， redis本身或者客户端都没有实现主从切换的功能.
而redis-sentinel就是一个独立运行的进程, 用于监控多个master-slave集群.
自动发现master宕机, 进行自动切换slave > master.
sentinel主要功能如下 :
不时的监控redis是否良好运行, 如果节点不可达就会对节点进行下线标识.
如果被标识的是主节点, sentinel就会和其他的sentinel节点"协商", 如果其他节点也认为主节点不可达, 就会选举一个sentinel节点来完成自动故障转义.
在master-slave进程切换后, master_redis.conf, slave_redis.conf和sentinel.conf的内容都会发生改变, 即master_redis.conf中会多一行slave的配置, sentinel.conf的监控目标户随之调换.
sentinel的工作方式 :
每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令 如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线。 如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。 当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线 在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令 当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次 若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。 若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。 主观下线和客观下线 主观下线：Subjectively Down，简称 SDOWN，指的是当前 Sentinel 实例对某个redis服务器做出的下线判断。 客观下线：Objectively Down， 简称 ODOWN，指的是多个 Sentinel 实例在对Master Server做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，然后开启failover. SDOWN适合于Master和Slave，只要一个 Sentinel 发现Master进入了ODOWN， 这个 Sentinel 就可能会被其他 Sentinel 推选出， 并对下线的主服务器执行自动故障迁移操作。 ODOWN只适用于Master，对于Slave的 Redis 实例，Sentinel 在将它们判断为下线前不需要进行协商， 所以Slave的 Sentinel 永远不会达到ODOWN。
redis主从复制的背景问题 :
Redis主从复制可将主节点数据同步给从节点, 从节点此时有两个作用 :
1. 一旦主节点宕机, 从节点作为主节点的备份可以随时顶上来
2. 扩展主节点的读能力, 分担主节点读压力
但是问题是 :
1. 一旦主节点宕机, 从节点上位, 那么需要人为修改所有应用 方的主节点地址(改为新的master地址), 还需要命令所有从节点复制新的主节点.
这个问题使用Redis-sentinel就可以解决.
主从复制架构 :
Rdis sentinel架构 :
redis命令整理 :
# 官网地址 http://redisdoc.com/ # 查看redis数据库信息 redis-cli info # 查看redis的复制授权信息 redis-cli info replication # 查看redis的哨兵信息 redis-cli info sentinel
redis-sentinel安装与配置
准备三个redis服务器环境, 一个主节点两个从节点
主节点master的redis-6379.conf配置 :
port 6379 daemonize yes logfile "6379.log" dbfilename "dump-6379.rdb" dir "/var/redis/data/"
从节点slave的redis-6380.conf配置 :
port 6380 daemonize yes logfile "6380.log" dbfilename "dump-6380.rdb" dir "/var/redis/data/" slaveof 127.0.0.1 6379 // 从属主节点
从节点slave的redis-6381.conf配置 :
port 6381 daemonize yes logfile "6380.log" dbfilename "dump-6380.rdb" dir "/var/redis/data/" slaveof 127.0.0.1 6379 // 从属主节点
启动主节点 :
redis-server /etc/redis-6379.conf
测试主节点是否通信 :
redis-cli ping
启动两个从节点的redis服务 :
redis-server /etc/redis-6380.conf
redis-server /etc/redis-6381.conf
验证从节点的redis服务 :
redis-cli -p 6380 ping
redis-cli -p 6381 ping
确定主从关系 :
在节点上查看主从通信关系
[root@master ~]# redis-cli -p 6378 info replication # Replication role:master connected_slaves:2 slave0:ip=192.168.119.10,port=6381,state=online,offset=407,lag=0 slave1:ip=192.168.119.10,port=6382,state=online,offset=407,lag=0 master_repl_offset:407 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:2 repl_backlog_histlen:406
在从节点上查看主从关系(6381, 6382)
[root@slave 192.168.119.11 ~]$redis-cli -p 6381 info replication # Replication role:slave master_host:192.168.119.10 master_port:6380 master_link_status:up master_last_io_seconds_ago:3 master_sync_in_progress:0 slave_repl_offset:505 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
此时在master上写入数据, 在slave上查看数据, 此时主从复制配置完成
Redis sentinel配置
配置三个哨兵并启动(和配置redis-server方法基本一致) :
# 配置文件信息 // Sentinel节点的端口 port 26380 dir /var/redis/data/ logfile "26380.log" // 当前Sentinel节点监控 127.0.0.1:6380 这个主节点 // 2代表判断主节点失败至少需要2个Sentinel节点节点同意 // mymaster是主节点的别名 sentinel monitor mymaster 127.0.0.1 6380 2 //每个Sentinel节点都要定期PING命令来判断Redis数据节点和其余Sentinel节点是否可达，如果超过30000毫秒30s且没有回复，则判定不可达 sentinel down-after-milliseconds mymaster 30000 //当Sentinel节点集合对主节点故障判定达成一致时，Sentinel领导者节点会做故障转移操作，选出新的主节点， //原来的从节点会向新的主节点发起复制操作，限制每次向新的主节点发起复制操作的从节点个数为1 sentinel parallel-syncs mymaster 1 //故障转移超时时间为180000毫秒 sentinel failover-timeout mymaster 180000
其他两个哨兵的配置和上面的差距仅仅是port(端口)的不同而已.
启动三个redis哨兵(启动方法和redis-server基本一致) :
// redis-sentinel sentinel的配置文件 redis-sentinel /data/26381/sentinel.conf redis-sentinel /data/26382/sentinel.conf
查看哨兵是否成功通信 :
[root@master ~]# redis-cli -p 26380 info sentinel # Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 sentinel_simulate_failure_flags:0 master0:name=mymaster,status=ok,address=192.168.119.10:6380,slaves=2,sentinels=3 #看到最后一条信息正确即成功了哨兵，哨兵主节点名字叫做mymaster，状态ok，监控地址是192.168.119.10:6379，有两个从节点，3个哨兵
哨兵监控拓补图 :
redis故障实验 :
1. 杀掉主节点的redis进程6380端口, 观察从节点是否会进行新的master选举, 进行切换
2. 重新恢复旧的master节点, 查看此时的redis身份
检查三个redis的进程状态 :
ps -ef | grep redis
杀死6380端口的进程等待片刻后会发现6381成为了主节点, 而6382端口成为了6381的从节点.
