Redsi Sentinel 26379

主从复制高可用

• 为主提供备份 读写分离 故障转移

  • 手动故障转移
  • 写能力和存储能力受限

• 手动故障转移

  • slaveof
  • no one
  • slaveof new master

架构说明

• 自动故障转移

  • 多个sentinel发现master 问题
  • 选举一个sentinel作为领导
  • 选举一个slave作为master
  • 通知其余slave成为新的master的slave
  • 通知客户端从变化
  • 等待老的master复活成为新master的slave

• 监控多个集群

  • master-name

配置启动

• 配置开启主从节点 自动发现从节点

  • 配置主节点 redis-server redis-7000.conf
    prot 7000
    daemonize yes
    pidfile /var/run/redis-7000.pid
    logfile "7000.log"
    dir "/opt/soft/redis/data"
  • 配置从节点 redis-server redis-7001.conf
    redis-server redis-7002.conf
    prot 7001
    daemonize yes
    pidfile /var/run/redis-7001.pid
    logfile "7001.log"
    dir "/opt/soft/redis/data"
    slaveof 127.0.0.1 7000
  • sentinel主要配置 sentinel.conf prot ${prot}
    daemonize yes
    dir "/opt/soft/redis/data"
    logfile "${port}.log"
    sentinel monitor mymaster 127.0.0.1 700 2 # 2 指有两个sentinel发现故障 就进行故障转移
    sentinel down-after-millisenconds mymaster 30000# 30s 连接不成功 故障转移
    sentinel parallel-syncs mymaster 1 # 每次只能复制一个
    sentinel failover-timeout mymaster 180000 #故障转移时间

• 配置开启sentinel监控主节点(sentinel是特殊的redis)

• 实际应该多台机器

• 详细配置从节点

客户端连接

• 服务端高可用

• 客户端高可用

  • 获取所有的sentinel节点集合 +masterName
  • redis数据节点变化通知 发布订阅

• 客户端接入流程

  • sentinel地址集合
  • masterName
  • 不是代理模式 ###jedis

• jedis new JedisSentinelPool(masterName,sentinelSet,poolConfig,timeout);
  redisSentinelPool.getResource();
  // jedis command
  jedis.close() 归还到池子

redis-py

form redis.sentinel import Sentinel sentinel = Sentinel([(‘localhost‘,26379),(‘localhost‘,26380),(‘localhost‘,26381),],socket_timeout=0.1) sentinel.discover_master("mymaster") sentinel.discover_slaves("mymaster")

故障转移演练

1. 客户端高可用观察

2. 服务端日志分析：数据节点和sentinel节点

   • 单个定时任务

     • 每10秒每个sentinel对master和slave执行info

       • 发现slave节点
       • 确认主从关系

     • 每2秒每个sentinel通过master节点的channel交换信息(pub/sub)

       • 通过sentinel:hello频道交互
       • 交互对节点的“看法”和自身信息

     • 每1秒每一个sentinel对其他sentinel的redis执行ping

       • 心跳检测，失败判定依据

3. 主主下线和客观下线

   • 配置

     • sentinel monitor
     • sentinel monitor mymaster 127.0.0.1 6379 2
     • sentinel down-after-millisenconds # 主观判断
     • sentinel down-after-millisenconds mymaster 30000

   • 主观下线

     • 每一个sentinel节点对Redis节点失败的“偏见”

   • 客观下线

     • 所有sentinel节点对Redis节点失败“达成共识”(超过quorum个统一)
     • sentinel is-master-down-by-addr ###领导者选举

• 原因：只有一个sentinel节点完成故障转移
• 选举：通过sentinel is-master-down-by-addr命令都希望成为领导者

1. 每个主观下线的sentinel节点向其他sentinel节点发送命令，要求将它设置为领导者
2. 收到命令的sentinel节点如果没有同意其他sentinel节点发送的命令，name将同意该请求，否则拒绝
3. 如果该sentinel节点发现自己的票数已经超过了sentinel集合半数且超过quorum，name它将成为领导者
4. 如果此过程有多个sentinel节点成为领导者，那么将等待一段时间重新进行选举 ###故障转移
5. 从slave节点选出一个“哈市的”节点作为新的master节点
6. 对上面的slave节点执行slaveof no one命令让其成为master节点
7. 向剩余的slave节点发送命令，让他们成为新master节点的slave节点，复制规则和parallel-syncs参数有关
8. 更新对原来master节点配置为slave，并保持找对其“关注”，当其回复后命令他去复制新的master节点

合适的slave节点

1. 选择slave-prioruty(slave节点优先级)最高的slave节点，如果存在则返回，不存在则继续
2. 选择复制偏移量最大的slave节点（复制的最完整），如果存在则返回，不存在继续
3. 选择runid最小的slave节点

常见开发运维问题

1. 节点运维

   • 下线原因分析

     • 机器下线：例如过保等情况
     • 机器性能不足：例如CPU 内存 硬盘 网络等
     • 节点本身故障： 例如服务不稳定等

   • 主节点

     • sentinel failover

   • 从节点

     • 临时下线还是永久下线，例如是否做一些清理工作，但是要考虑读写分离的情况

   • sentinel节点：同上

   • 节点上线

     • 主节点

       • sentinel failover 进行替换

     • 从节点

       • slaveof即可，sentinel节点可以感知

     • sentinel节点：

       • 参开其他sentinel节点启动即可

2. 高可用读写分离 客户端

   • 通过循环连接sentinel集合 如果所有都能不能连接 异常

   • 订阅sentinel 频道 +switch-master

     • 收到+switch-master信息

       • 重新进行连接sentinel

3. 从节点的作用

   1. 副本：高可用的基础

   2. 扩展：读能力

   3. 故障转移 三个消息

      1. +switch-master ： 切换节点
      2. +convert-to-slave:切换从节点
      3. +sdown : 主观下线 ##总结

• sentinel是redis高可用实现方案

  • 故障发现，故障自动转移，配置中心，客户端通知

• sentinel2.8版本开始正式生产可用，之前版本生产不可用

• sentinel节点应该大于等于3且最好是奇数

• sentinel中的数据节点和普通数据节点没有区别

• sentinel 通过三个定时任务对主从和其余sentinel接的监控

• sentinel对接点做判定时分为主观下线和客观下线