Redis进阶:Redis的哨兵模式搭建

2019/12/04 18:04
阅读数 155

Redis进阶:Redis的哨兵模式搭建

哨兵机制介绍

单机版的Redis存在性能瓶颈,Redis通过提高主从复制实现读写分离,提高了了Redis的可用性,另一方便也能实现数据在多个Redis直接的备份。

上一篇文章我们通过配置Redis的主从复制机制来提高了Redis的可用性,但是一旦主节点出现问题,就需要运维手工切换主从服务节点,即增加了人工成本,且容易出错,而且无法自动化切换,Redis的哨兵机制就能实现自动的主从切换,以及实现对Redis服务的切换,那就让我们来感受下哨兵机制的强大吧。

准备条件

搭建主从服务

这一步在上篇文章以及详细介绍了,这里就简答提一下,细节具体可以翻看上一篇。

# 启动Redis 主从复制集群机制
[root@localhost redis-5.0.7]# src/redis-server  redis6379.conf 
[root@localhost redis-5.0.7]# src/redis-server  redis6380.conf
[root@localhost redis-5.0.7]# src/redis-server  redis6381.conf

查看主从复制集群

127.0.0.1:6379> INFO replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=14,lag=0
slave1:ip=127.0.0.1,port=6381,state=online,offset=14,lag=0
master_replid:7af61d3aee64d388592c3dabb16cd9b4a2158d7e
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:14
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:14

可以看到,我们的主从服务(一主二从)已经搭建完毕。

准备哨兵配置文件

我们下载的Redis.tar.gz 解压后里面是有一个senitel.conf配置文件的,我们复制一个然后进行配置修改。

# 复制配置文件
[root@localhost redis-5.0.7]# cp sentinel.conf sentinel26379conf

# 修改sentinel26379conf配置文件
bind 0.0.0.0
port 26379
daemonize yes
pidfile /var/run/redis-sentinel26379.pid
logfile "/usr/local/redis/logs/sentinel-26379.log"
dir /tmp
# 哨兵   监控	 主节点名称 IP地址  端口  判断失效的哨兵个数
sentinel monitor mymaster 127.0.0.1 6379 2
# 配置主服务的密码(如果主节点设置密码这块必须要进行配置)
sentinel auth-pass mymaster enjoyitlife
sentinel down-after-milliseconds mymaster 1000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 5000

将配置文件sentinel26379.conf 在复制两份,sentinel26380、sentinel26381.conf。这两个配置文件 值需要修改里的端口号就可以。

# sentinel26380 配置文件内容 26381配置文件就不在赘述了。
bind 0.0.0.0
port 26380
daemonize yes
pidfile /var/run/redis-sentinel26380.pid
logfile "/usr/local/redis/logs/sentinel-26380.log"
dir /tmp
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 1000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 5000
sentinel auth-pass mymaster enjoyitlife

运行哨兵

运行哨兵

# 开启三个哨兵监控主节点
[root@localhost redis-5.0.7]# src/redis-sentinel sentinel26379.conf 
[root@localhost redis-5.0.7]# src/redis-sentinel sentinel26380.conf 
[root@localhost redis-5.0.7]# src/redis-sentinel sentinel26381.conf 

也可以通过 redis-server /path/to/sentinel.conf --sentinel 运行哨兵。

查看哨兵状态

# 通过 ps指令
[root@localhost redis-5.0.7]# ps -ef | grep redis
root       7929      1  0 07:49 ?        00:00:01 src/redis-server 0.0.0.0:6379
root       7933   7772  0 07:49 pts/5    00:00:00 src/redis-cli -p 6379 -a enjoyitlife
root       7935      1  0 07:50 ?        00:00:01 src/redis-server 127.0.0.1:6380
root       7941      1  0 07:50 ?        00:00:01 src/redis-server 127.0.0.1:6381
root       7949      1  0 08:00 ?        00:00:00 src/redis-sentinel 0.0.0.0:26379 [sentinel]
root       7954      1  0 08:00 ?        00:00:00 src/redis-sentinel 0.0.0.0:26380 [sentinel]
root       7959      1  0 08:00 ?        00:00:00 src/redis-sentinel 0.0.0.0:26381 [sentinel]
root       7978   7686  0 08:01 pts/4    00:00:00 grep --color=auto redis

# 通过客户端 哨兵机制本质也是Redis服务的一种模式 可以通过客户端指令
[root@localhost ~]# cd /opt/software/redis/redis-5.0.7
[root@localhost redis-5.0.7]# src/redis-cli -p 26379
127.0.0.1:26379> 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=127.0.0.1:6379,slaves=2,sentinels=3

可以看到至此,我们的哨兵机制已经正确搭建完毕,当前有三个哨兵,一主多从,3个服务节点。

哨兵机制验证

我们关闭主节点,然后等待1S后再进行查看。

# 关闭主节点
127.0.0.1:6379> SHUTDOWN
# 在从节点6380上进行查看
127.0.0.1:6380> INFO replication
# Replication
role:master
connected_slaves:0
master_replid:a83e3a8610f2a01691fd859143a4a7dc897b5916
master_replid2:7af61d3aee64d388592c3dabb16cd9b4a2158d7e
master_repl_offset:78278
second_repl_offset:69478
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:78278

可以看到现在的6380节点已经有从节点升级为了主节点。我们再次启动6379节点。

# 启动6379端口节点
[root@localhost redis-5.0.7]# src/redis-server  redis6379.conf 
[root@localhost redis-5.0.7]# src/redis-cli -p 6379 -a enjoyitlife
# 查看集群信息
127.0.0.1:6379> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6380
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:107428
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:a83e3a8610f2a01691fd859143a4a7dc897b5916
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:107428

此时即使6379端口节点恢复正常了,但是它已经失去了主节点的身份,目前降级为了从节点了。下面就哨兵机制的原理在进行说明下。

哨兵机制相关原理

主要功能

  • 监控 检查主从服务节点是否服务正常
  • 提醒 当被监控的节点出现问题时,哨兵机制可以发送通知
  • 自动故障转移 主节点不可以用时,自动进行节点升级和故障转移。
  • 提供配置 作为客户端的配置提供者。

故障转移流程

  • 每个Sentinel每秒钟向主节点、从节点、其他sentinel实例发送PING命令。
  • 如果一个Sentinel发现主服务节点不可用,会将主节点标记为主观下线,并通知其他Sentinel实例向主节点发送消息。
  • 如果有足够数量的Sentinel实例,满足配置文件中需要的个数sentinel monitor mymaster 127.0.0.1 6379 2 这里配置的是2,那就将主服务标记为客观下线。
  • Sentinel通过选举机制选举出一个Lead Sentinel,负责本次故障转移。
  • Sentinle选择一个从服务节点,向其发送SALVE NO ONE 命令,使其升级为主节点。
  • 通过发布与订阅功能, 将更新后的配置传播给所有其他 Sentinel , 其他 Sentinel 对它们自己的配置进行更新。
  • 向从服务器发送 [SLAVEOF] 命令,让他们的主服务节点更新为上一步新主节点。
  • 当所有从服务器都已经开始复制新的主服务器时, 复制本次故障转移的Sentinel 终止这次故障迁移操作。

注意要点

  • Sentinel会在运行中自动的修改配置文件并进行持久化,主要涉及主从配置点。
  • 每一次故障转移Sentinel都会用过选举机制选举从本次故障转移的领头Sentinel,从而有领头的Sentinel来负责故障转移过程。
  • Sentinel之间通过订阅发布来进行消息传输。
  • Sentinel机制很大程度依赖计算机时间,如果计算机出现故障,或者进程被阻塞,Sentinel可能也会出现故障,从而进入TLTL保护模式,进入TILT模式后,哨兵就不会在起作用。如果在30S内恢复正常,就会退出TITL模式。

以上就是Redis哨兵模式操作的相关介绍了,更多其他指令可以参考官网,Redis官网,谢谢阅读,希望对你有所帮助。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
1 收藏
0
分享
返回顶部
顶部