Redis哨兵高可用性(包含创建sentinel节点以及配置文件)

Redis哨兵 (Redis Sentinel)

声明:本次笔记全本人手写,如果想看redis数据节点的配置文件和sentinel节点的配置文件请直接跳到9.2.2和9.2.3

22/4/29/lsj

本次笔记主要了解Redis Sentinel,实现Redis主从复制高可用,以及实现原理

• Redis Sentinel 的概念
• Redis Sentinel 的安装部署
• Redis Sentinel 的API详解

9.1基本概念

9.1.1 主从复制的问题

Redis 的主从复制可以将主节点的数据同步给从节点,实现主从一致,这样从节点起到两个作用:

0. 作为主节点的一个备份,主节点出现故障不可达的时候,可以作为主节点的一个备份,并且保证数据尽量不丢失。
1. 从节点可以扩展主节点的读能力,进行读写分离,一旦主节点撑不住大量的并发读操作,那么从节点可以分担读压力。

但是主从复制也有几个问题:

• 一旦主节点出现故障,需要手动将一个从节点升为主节点(slave no one),同时需要修改应用方的主节点地址(改为之前的从节点地址),还需要命令其他从节点去复制新的主节点,整个过程都需要人工的干预
• 主节点的写能力受到单机的限制
• 主节点的存储能力受到单机的限制 其中第一个问题是高可用问题,用redis Sentinel可以解决,下面两个问题是分布式的问题,将在后续笔记中展现。

9.1.2 高可用

在Redis的主从复制下,一旦主节点出现了故障不可达的情况,需要人工进行干预,把从节点升级为主节点,其他从接待你复制新的主节点,还要干预应用方,这样是不能接受的,会造成一些数据的丢失。

接下来会介绍主从复制模式下,主节点出现故障是如何进行故障转移的 :

0. 主节点发生故障之后,客户端连接失败,两个从节点与主节点连接失败造成连接中断
1. 主节点无法正常启动,需要选择一个从节点成为一个新的主节点(执行命令slave no one)
2. 原来的从节点成为新的主节点之后通知应用方主节点信息然后重启
3. 客户端命令其他从节点复制新的主节点
4. 原来的主节点恢复之后复制新的主节点

上述的这些流程如果是人工干预那么就不是高可用的,整个故障转移过程有些公司已经自动化了,但也要考虑三个问题:

0. 判断节点不可达机制是否健全
1. 如果有多个从节点,那么怎样保证只有一个从节点晋升成主节点
2. 通知客户端新的主节点机制是否足够健壮

以上的所有问题都可以用Redis Sentinel实现(主从复制故障转移的高可用问题)

9.1.3 Redis Sentinel 的高可用性

Redis Sentinel是一个分布式架构(Redis数据节点,Sentinel节点集合,客户端分布在多个物理节点的架构),其中包含多个Redis Sentinel节点和Redis数据节点

• 每个Sentinel节点都会对Redis数据节点和其他Sentinel节点进行监控,当发现其他节点不可达的时候,会对节点做一个下线的标志
• 如果被标志的是主节点,他会和其他的Sentinel节点协商,大多数Sentinel节点认为主节点不可达的时候,会推选出一个Sentinel节点完成主从故障的功能
• 这一套都是自动的,完成后会通知应用方,这实现了高可用性

Redis主从复制模式和Redis Sentinel架构的区别(如图):

结构上可以知道redis Sentinel会定期对所有节点进行监控和进行故障转移

下面进行Redis Sentinel的例子进行故障转移说明(一共四步,第四步是Redis Sentinel领导者节点执行故障转移的步骤):

0. 主节点出现故障,从节点与主节点失去连接

1. Redis Sentinel通过检测,检测到主节点故障

2. Redis Sentinel推选出一个Sentinel节点进行执行故障转移

3. Redis Sentinel进行故障转移

   • 从节点执行slave no one
   • 从节点复制新的节点
   • Sentinel通知客户端
   • 原来主节点复制新的主节点 如图:

• 故障转移后的拓扑结构图如下:

通过Redis Sentinel故障转移可以得知Redis Sentinel具有以下几个功能:

• 监控
• 通知
• 主节点故障转移
• 配置提供者

Redis Sentinel包含了若干个Sentinel节点,这样做的好处如下:

9.2 安装和部署

9.1讲解了Redis Sentinel基本架构,接下来讲解一下安装和部署以及使用

9.2.1 部署拓扑结构

9.2.2 部署Redis数据节点

首先配置三个redis.conf,分别是:

• redis-6379.conf

  主节点重点配置文件:
  port:6379
  daemoize yes   #默认挂在服务器上
  logfile "6379.log"
  dbfilename "dump-6379.rdb"
  dir "/root/redis-5.0.0/data"
  ​
  #启动主节点 redis-server redis-6379.conf
  #连接主节点 redis-cli -h 127.0.0.1 -p 6379
  

redis-6380.conf

   从节点1重点配置文件:
    port:6380
    daemoize yes   #默认挂在服务器上
    logfile "6380.log"
    dbfilename "dump-6380.rdb"
    dir "/root/redis-5.0.0/data"
    slaveof 127.0.0.1 6379   #默认启动自动复制6379节点
    
    #启动从节点1 redis-server redis-6380.conf
    #连接从节点1 redis-cli -h 127.0.0.1 -p 6380

redis-6381.conf

   从节点2重点配置文件:
    port:6381
    daemoize yes   #默认挂在服务器上
    logfile "6381.log"
    dbfilename "dump-6381.rdb"
    dir "/root/redis-5.0.0/data"
    slaveof 127.0.0.1 6379   #默认启动自动复制6379节点
    
    #启动从节点1 redis-server redis-6381.conf
    #连接从节点2 redis-cli -h 127.0.0.1 -p 6381

重点避坑:如果主节点设置密码了,那么从节点的conf里面的masterauth一定要设置的主节点一模一样,如果主节点没有设置密码,那么从节点的masterauth要注释掉,否则会链接失败,所以有密码的尽量全设置成一样,主从节点的auth都设置一样,主从节点的masterauth也都设置一样,这样主节点宕机之后,从节点成为新的主节点,其他从节点复制新的主节点不会因为密码问题连接不上

9.2.3 部署Sentinel节点

三个文件都一样,只不过端口不一样,所以这里就配置了一个

• redis-sentinel-26379.conf

  主节点重点配置文件:
  port:26379
  daemoize yes   #默认挂在服务器上
  logfile "26379.log"
  dir "/root/redis-5.0.0/data"
  ​
  #启动哨兵方式一: redis-server redis-sentinel-26379.conf --sentinel
  #启动哨兵方式二: redis-sentinel redis-sentinel-26379.conf
  #连接哨兵节点 redis-cli -h 127.0.0.1 -p 26379
  

连接成功之后的info sentinel命令,可以看出当前这个哨兵节点检测了所有的哨兵节点,检测了两个从节点

至此,Redis Sentinel都搭建起来了,下面这个图是最终的拓展图:

9.2.4看另一章笔记

9.2.5 部署的建议和技巧

以上的部署方法已经掌握了,那么在实际环境下的部署技巧,本小节就来总结一下

• 在生产环境中Redis Sentinel接待你不应该部署在一台物理机上面,应该部署在多台物理机上,同一台物理机可能会故障,那么这台物理机上的所有虚拟机都将会受到影响,影响Sentnel的高可用性
• 部署至少三个且基数个数的Sentinel节点
  • 3个以上是通过添加Sentinel节点来提高对于故障判断的准确性,欣慰领导者选举至少需要一半+1个节点,奇数可以满足在这个条件下节省一个节点
• 只有一套Sentinel还是多套Sentinel,每个主节点配置一套Sentinel,两种各有各的优势

9.3 Sentinel的API

1)展示所有被监控的主节点以及相关统计的信息
sentinel masters

2)展示指定(master-name)的主节点状态以及相关的统计信息
sentinel master (master-name)

3)展示指定(master-name)的从节点状态以及相关的统计信息
sentinel slaves (master-name)

4)展示指定的(master-name)的Sentinel节点集合(不包含当前的节点)
sentinel sentinels (master-name)

5)返回指定的(master-name)主节点的IP地址和端口
sentinel get-master-addr-by-name (master-name)

6)对当前主节点进行重置
sentinel reset (pattern)

7)对指定的节点进行强制故障转移,没有和其他节点进行协商,其他Sentinel节点按照故障转移的结果更新自身配置
sentinel failover (master-name)
执行之前:

现在对6380进行强制故障转移:

8)检查当前可达的Sentinel节点总数是否达到(quorum)的个数,例如quorum=3,而Sentinel节点数量=2这样就不太行
sentinel ckquorum (mymaster)

9)将Sentinel节点的配置强制刷新到磁盘上,这个命令对Sentinel节点自身用的较多,当外部磁盘损坏造成配置文件丢失的时候,这个命令很有用
sentinel flushconfig

10)取消当前这个sentinel节点对当前主节点的监控
sentinel remove (master-name)

11)sentinel监控主节点命令,这个命令跟配置文件上的配置文件一样,只不过是通过命令的形式来完成
sentinel monitor (mastername) (ip) (port) (quorum)

12)动态修改Sentinel节点的选项,这个在9.2.4节讲过

sentinelset (master-name)
13)Sentinel节点之间用来交换对主节点是否下线的判断,根据参数不同,可以作为Sentinel领导者选举的通信方式

sentinel is-master-down-by-addr