Redis进阶实践之十 Redis哨兵集群模式
一、引言 1.1、### NETWORK 设置: bind 192.168.127.128 //绑定IP地址,可以通过ifconfig 获取Ip地址(在Linux系统下) port 6379 保持默认值,也可以修改 timeout 30 Client 端空闲断开连接的时间 1.2、### GENERAL 设置: daemonize yes 默认值是no,把值修改为yes,以后台模式运行 logfile /root/application/program/redis-tool/logs/redis.log 日志文件的位置 1.3、### SNAPSHOTTING 设置: dir /root/application/program/redis-tool/datas SNAPSHOTTING文件的路径 1.4、### APPEND ONLY MODE 设置: appendonly yes 默认值是No,意思是不使用AOF增量持久化的方式,使用RDB全量持久化的方式。把No值改成Yes,使用AOF增量持久化的方式 appendfsync always
2.1、### NETWORK 设置: bind 127.129 port 6379 timeout Client 端空闲断开连接的时间 2.2、### GENERAL 设置: daemonize yes logfile /root/application/program/redis/logs/redis.log 日志文件的位置 2.3、### SNAPSHOTTING 设置: dir /root/application/program/redis/datas SNAPSHOTTING文件的路径 2.4、### REPLICATION 设置: slaveof 127.128 主服务器的Ip地址和Port端口号 slave-serve-stale-data no 如果slave 无法与master 同步,设置成slave不可读,方便监控脚本发现问题。 2.5、### APPEND ONLY MODE 设置: appendonly yes appendfsync always
3.1、 ### Port 设置: port 26379 哨兵端口号保持不变,可以修改,但是我没有修改 3.2、### dir 设置: dir /root/application/program/redis/sentinel/ 哨兵程序的日志路径 3.3、### Sentinel Monitor 设置: sentinel monitor mymaster 127.129 6379 1 3.4、### Down-After-Milliseconds 设置: sentinel down-after-milliseconds mymaster 5000 哨兵程序每5秒检测一次Master是否正常 3.5、### Parallel-Syncs 设置: sentinel parallel-syncs mymaster 3.5、### Failover-Timeout 设置: sentinel failover-timeout mymaster 60000 3.5、### 启动:redis-sentinel redis-server sentinel.conf --sentinel & (&有这可以Ctrl +C退到命令行,没有这个就直接退出哨兵进程) redis-sentinel /path/to/sentinel.conf & 对于 redis-sentinel 程序, 你可以用以下命令来启动 Sentinel 系统 3.6、### 关闭:redis-sentinel pkill redis-server 这个会关掉Redis服务器和Sentinel(哨兵)进程 kill 进程号 可以关掉指定进程号的进程
???????? ? ? ? 4.2、在Sentinel.conf配置文件设置 sentinel down-after-milliseconds: ?????????????????????????? ???????? ? ? ? 4.3、在Sentinel.conf配置文件设置 sentinel parallel-syncs: ?????????????????????????? ???????? ? ? ? 4.4、Master 主服务器的配置详情: ????????????????????????? ???????? ? ? ? 4.5、Slave 从服务器配置详情: ???????????????????????? ???????? ? ? ? 4.6、启动Sentinel(哨兵)进程,开始对Master主服务器进行监控: ????????????????????????? ???????? ? ? ? 4.7、我们人为模仿Master主服务器宕机: ?????????????????????????? ???????? ? ? ? 4.8、实现Master主服务器和Slave从服务器的切换: ????????????????????????? ???????? ? ? ? 4.9、主从切换后,主服务器变成了Slave 从服务器,详情如下: ??????????????????????????? ???????? ? ? ? 4.10、主从切换后,从服务器变成了Master 主服务器,详情如下: ?????????? 注意: ??????????????? ① INFO ??????????????????? sentinel的基本状态信息 ?????????????? ②SENTINEL masters ?????????? ? ? ? ? 列出所有被监视的主服务器,以及这些主服务器的当前状态 ?????????????? ③ SENTINEL slaves ?????????????????? 列出给定主服务器的所有从服务器,以及这些从服务器的当前状态 ?????????????? ④SENTINEL get-master-addr-by-name ??????????????????? 返回给定名字的主服务器的 IP 地址和端口号 ?????????????? ⑤SENTINEL reset ??????????????????? 重置所有名字和给定模式 pattern 相匹配的主服务器。重置操作清除主服务器目前的所有状态, 包括正在执行中的故障转移, 并移除目前已经发现和关联的, 主服务器的所有从服务器和 Sentinel 。 ?????????????? ⑥SENTINEL failover ?????????????????? 当主服务器失效时, 在不询问其他 Sentinel 意见的情况下, 强制开始一次自动故障迁移,但是它会给其他sentinel发送一个最新的配置,其他sentinel会根据这个配置进行更新 四、主观下线和客观下线 ?????????? 下面我们来解释一下两个“下线”的概念,一个是“主观下线”,另一个就是“客观下线”。 ??????????? 主观下线(Subjectively Down, 简称 SDOWN)指的是单个 Sentinel 实例对服务器做出的下线判断。 ??????????? 客观下线(Objectively Down, 简称 ODOWN)指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断,并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后,得出的服务器下线判断。(一个 Sentinel 可以通过向另一个 Sentinel 发送 SENTINEL is-master-down-by-addr 命令来询问对方是否认为给定的服务器已下线。) ?????????? 如果一个服务器没有在 master-down-after-milliseconds 选项所指定的时间内,对向它发送 PING 命令的 Sentinel(哨兵)进程返回一个有效回复(valid reply),那么? Sentinel(哨兵)进程就会将这个服务器标记为主观下线。 ?????????? 服务器对 PING 命令的有效回复可以是以下三种回复的其中一种: ?????????????? 1、返回 +PONG 。 ?????????????? 2、返回 -LOADING 错误。 ????????????? 3、返回 -MASTERDOWN 错误。 ???????????? 如果服务器返回除以上三种回复之外的其他回复,又或者在指定时间内没有回复 PING 命令,那么 Sentinel(哨兵)进程认为服务器返回的回复无效(non-valid)。 ???????????? 如果一个服务器在 master-down-after-milliseconds 毫秒内,一直返回无效回复才会被 Sentinel 标记为主观下线。 ???????????? 举个例子,如果 master-down-after-milliseconds 选项的值为 30000 毫秒(30 秒),那么只要服务器能在每 29 秒之内返回至少一次有效回复, 这个服务器就仍然会被认为是处于正常状态的。 ????? ? ? ? 从“主观下线”状态切换到“客观下线”状态并没有使用严格的法定人数算法(strong quorum algorithm),而是使用了流言协议,该协议解释为:如果 Sentinel(哨兵)进程在给定的时间范围内,从其他 Sentinel(哨兵)进程那里接收到了足够数量的主服务器下线报告, 那么 Sentinel(哨兵)进程就会将主服务器的状态从“主观下线”改变为“客观下线”。如果之后其他 Sentinel(哨兵)进程不再报告主服务器已下线,那么“客观下线”状态就会被移除。 ???? ? ? ? “客观下线”条件只适用于主服务器:对于任何其他类型的 Redis 实例,? Sentinel(哨兵)进程在将它们判断为下线前不需要进行协商,所以Slave从服务器或者其他 Sentinel(哨兵)进程永远不会达到“客观下线”条件。 ??????????? 只要有一个 Sentinel(哨兵)进程发现某个主服务器进入了“客观下线”状态,这个 Sentinel(哨兵)进程就可能会被其他 Sentinel(哨兵)进程推选出,并对失效的主服务器执行自动故障迁移操作。 五、Sentinel(哨兵)配置文件简介 ????????? 在Redis的源码中包含了一个名为 sentinel.conf 的文件, 这个文件就是带有注释的Sentinel(哨兵)的配置文件的示例。 ????????? 如果想要运行一个“哨兵”程序,以下配置项是最少配置: ??????????? sentinel monitor mymaster 127.0.0.1 6379 1 ??????????? sentinel down-after-milliseconds mymaster 60000 ??????????? sentinel failover-timeout mymaster 180000 ??????????? sentinel parallel-syncs mymaster 1 ?????? ?? 第一行配置表示 Sentinel(哨兵)进程去监视一个名为 mymaster 的主服务器,这个主服务器的 IP 地址为 127.0.0.1 , 端口号为 6379,而将这个主服务器判断为失效至少需要 1 个 Sentinel(哨兵)进程的同意。如果在架构系统中已经配置类多个Sentinel(哨兵)进程,在同意“Master主服务器”下线的 Sentinel(哨兵)进程的数量不达标的情况下,Sentinel(哨兵)进程就不会执行自动故障迁移。在设置多Sentinel(哨兵)进程的情况下,无论设置多少个 Sentinel(哨兵)进程同意才能判断一个服务器失效,一个 Sentinel 都需要获得架构系统中多数 Sentinel(哨兵)进程的支持, 才能发起一次自动故障迁移,并预留一个给定的配置纪元 (configuration Epoch ,一个配置纪元就是一个新主服务器配置的版本号)。如果您只配置了一个Sentinel(哨兵)进程来做监控,那一个Sentinel(哨兵)进程也可以决定“Master主服务器”是否下线。 ?????????? 其他选项的基本格式如下:sentinel <选项的名字> <主服务器的名字> <选项的值> ?????????? 配置选项的解释如下: ??????????? 1、down-after-milliseconds : Sentinel(哨兵)进程判断服务器已经掉线所需的毫秒数。 ??????????????? 如果被监控的服务器在给定的毫秒数之内,并没有返回 Sentinel(哨兵)进程发送的 PING 命令的回复,或者返回一个错误,那么 Sentinel(哨兵)进程将这个服务器标记为主观下线(subjectively down,简称 SDOWN )。如果在架构系统中配置了多个Sentinel(哨兵)进程的情况下,只有一个Sentinel(哨兵)进程将服务器标记为主观下线并不一定会引起服务器的自动故障迁移,只有在足够数量的 Sentinel(哨兵)进程都将一个服务器标记为主观下线之后,服务器才会被标记为客观下线(objectively down, 简称 ODOWN ),这时才回执行自动故障迁移。另外一种情况是,在架构系统中只配置了一个Sentinel(哨兵)进程的话,那这Sentinel(哨兵)进程也可以决定被监控的服务器的是否“下线”。 ??????????????? 将服务器标记为客观下线所需的 Sentinel(哨兵)进程数量由对主服务器的配置决定。 ?????????? 2、parallel-syncs :在执行故障转移时,最多可以有多少个从服务器同时对新的主服务器进行同步,这个数字越小,完成故障转移所需的时间就越长。 ?????????????? 如果“Slave从服务器”被设置为允许使用过期数据集(参见对 redis.conf 文件中对 slave-serve-stale-data 选项的说明),那么你可能不希望所有“Slave从服务器”都在同一时间向新的“Master主服务器”发送同步请求, 因为尽管复制过程的绝大部分步骤都不会阻塞“Slave从服务器”,但“Slave从服务器”在载入“Master主服务器”发来的 RDB 文件时, 仍然会造成“Slave从服务器”在一段时间内不能处理命令请求,如果全部“Slave从服务器”一起对新的“Master主服务器”进行同步, 那么就可能会造成所有“Slave从服务器”在短时间内全部不可用的情况出现。 ?????????????? 你可以通过将这个值设为 1 来保证每次只有一个Slave从服务器处于不能处理命令请求的状态。 ?????????? 3、failover-timeout:实现主从切换,完成故障转移的所需要的最大时间值。若Sentinel(哨兵)进程在该配置值内未能完成故障转移的操作(即故障时master/slave自动切换),则认为本次故障转移操作失败。 ?????????? 4、notification-script: 指定Sentinel(哨兵)进程检测到Master-Name所指定的“Master主服务器”的实例异常的时候,所要调用的报警脚本。该配置项可选,但线上系统建议配置。 六、哨兵模式的优缺点 ???? 优点: ??????? 1、哨兵集群模式是基于主从模式的,所有主从的优点,哨兵模式同样具有。 ??????? 2、主从可以切换,故障可以转移,系统可用性更好。 ??????? 3、哨兵模式是主从模式的升级,系统更健壮,可用性更高。 ???? 缺点: ??????? ??????? 1、Redis较难支持在线扩容,在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题,运维人员在系统上线时必须确保有足够的空间,这对资源造成了很大的浪费。 七、结束 ?????????? 今天就写到这里了,Redis的哨兵模式是以主从模式为基础的,所以说,主从模式拥有的一些缺点,在哨兵模式下也具有。哨兵模式主要是监控Master主服务器的运行情况,当然也会监控Slave从服务器的运行情况,如果Master主服务器发生了故障,该模式可以保证Slave从服务器顺利升级为Master主服务器继续提供服务,以此提高系统的高可用性。虽然哨兵模式比主从模式提高了不少系统的高可用性,但是该模式不能水平扩容,不能动态的增、删节点,这也是限制哨兵模式广泛应用的主要原因。Redis也看到了这个情况,所在在Redis的3.x以后的版本提供了一个更加强大集群模式,那就是Cluster集群模式,这个模式也是我们下一篇文章的主题。 (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |