Redis linux - Sentinel 开启哨兵模式以及监控

                Redis linux - Sentinel 开启哨兵模式以及监控

主从复制读写分离

• 1主2从，读写分离，主节点（master）写，从节点（slave）读，集群搭建
• 查看当前节点集群状态（redis命令）：info replication
  • 如图表示当前服务器是主节点，单机服务

• 配置（redis.conf），主节点只需要修改密码（masterauth）即可
  • replicaof：主节点ip和端口配置，样例：replicaof <masterip> <masterport>
  • masterauth：主节点认证-密码，样例：masterauth <master-password>
  • replica-read-only：yes当前节点只允许读，no关闭只读模式，默认开启状态
• 启动后查看集群当前节点状态
  • 主节点

•  
  • 从节点

•  注意
  • 同步数据有两种模式，磁盘同步和无磁盘同步
    • 磁盘同步是主节点与从节点同步数据，初始化会传输RBD文件，从节点下载后读取数据，以后的每次写操作主节点都会同步至从节点，因此建议集群搭建1主2从，减少同步数据性能消耗。
      • 默认开启磁盘化同步，主节点必须开启持久化RDB。
    • 无磁盘同步尚且不太成熟，是从内存分化出RDB去，直接从内存中将数据进行同步，建议应用环境为磁盘io差但带宽大的环境使用。
      • 在配置文件中（redis.conf）配置
        • repl-diskless-sync：yes开启无磁盘化同步，no为关闭，默认为关闭状态
• 测试
  • 在主节点写入三条数据，并获取

•  
  • 从节点写入失败，从节点只允许读操作，读取数据成功

哨兵监控

什么是哨兵

• Sentinel（哨兵）是用于Redis集群中的Master状态的工具，哨兵可以监视一个或者多个Redis Master服务，以及这些Master服务的所有Slave从服务，当Master服务宕机了，会把关联Master的Slave从服务升级为Master服务来替换已经宕机的Master继续工作，当原Master恢复后将设定为Slave从服务跟随当前的Master继续工作。
• Redis哨兵(以下称哨兵)是为Redis提供一个高可靠解决方案，对一定程序上的错误，可以不需要人工干预自行解决。
• 哨兵功能还有监视、事件通知、配置功能。以下是哨兵的功能列表：
• 监控：不间断的检查主从服务是否如预期一样正常工作
• 事件通知：对被监视的redis实例的异常，能通知系统管理员，或者以API接口通知其他应用程序。
• 智能援救：当被监视的主服务异常时，哨兵会智能的把某个从服务提升为主服务，同时其他从服务与新的主服务之间的关系将得到重新的配置。应用程序将通过redis服务端重新得到新的主服务的地址并重新建立连接。
• 配置服务：客户端可连接哨兵的接口，获得主从服务的相关信息，如果发生改变，哨兵新通知客户端。
• 注意：
  • 由Master变更为Salve从服务的节点注意masterauth权限配置，否则无法被数据同步。
  • 网络或者防火墙策略是否允许通讯。
  • Redis集群权限masterauth，统一密码。
• 哨兵配置

#普通配置
#端口号
port 26379
#pid 文件
pidfile /usr/local/redis/sentinel/redis-sentinel.pid
#哨兵工作空间路径
dir /usr/local/redis/sentinel
#进程守护，允许后台运行
daemonize yes
#不开启模块保护，允许远程访问
protected-mode no
#日志存放位置
logfile /usr/local/redis/sentinel/redis-sentinel.log

#核心配置
# 配置哨兵，mymaster随意，至少给主节点定的昵称，注意配置一致即可
# 2表示配置哨兵，有2个哨兵作出同样的决策，才有决策权
sentinel monitor mymaster 127.0.0.1 6379 2
# 密码
sentinel auth-pass <master-name> <password>
# master被sentinel认定为失效的间隔时间
sentinel down-after-milliseconds mymaster 30000
# 剩余的slaves重新和新的master做同步的并行个数
sentinel parallel-syncs mymaster 1
# 主备切换的超时时间，哨兵要去做故障转移，这个时候哨兵也是一个进程，如果他没有去执行，超过这个时间后，会由其他的哨兵来处理
sentinel failover-timeout mymaster 180000

•  将配置文件发送只其他两个哨兵
  • scp sentinel.conf root@192.168.213.131:/usr/local/redis/

• 启动哨兵
  • 创建哨兵工作空间
    • mkdir  /usr/local/redis/sentinel/ -p
  • redis-sentinel /配置文件路径/sentinel.conf
• 查看哨兵进程
  • ps -ef | grep redis
• 监控哨兵日志（第一个启动的哨兵）
  • tail -f /usr/local/redis/sentinel/redis-sentinel.log

•  redis客户端操作哨兵
  • redis-cli -h <IP> -p <端口号>：登录

  • PING ：返回 PONG 。

  • SENTINEL masters ：列出所有被监视的主服务器，以及这些主服务器的当前状态

  • SENTINEL slaves <master name> ：列出给定主服务器的所有从服务器，以及这些从服务器的当前状态

  • SENTINEL get-master-addr-by-name <master name> ： 返回给定名字的主服务器的 IP 地址和端口号。 如果这个主服务器正在执行故障转移操作， 或者针对这个主服务器的故障转移操作已经完成， 那么这个命令返回新的主服务器的 IP 地址和端口号

  • SENTINEL reset <pattern> ： 重置所有名字和给定模式 pattern 相匹配的主服务器。 pattern 参数是一个 Glob 风格的模式。 重置操作清楚主服务器目前的所有状态， 包括正在执行中的故障转移， 并移除目前已经发现和关联的， 主服务器的所有从服务器和 Sentinel

  • SENTINEL failover <master name> ： 当主服务器失效时， 在不询问其他 Sentinel 意见的情况下， 强制开始一次自动故障迁移。 （不过发起故障转移的 Sentinel 会向其他 Sentinel 发送一个新的配置，其他 Sentinel 会根据这个配置进行相应的更新）

  • SENTINEL MONITOR <name> <ip> <port> <quorum> 这个命令告诉sentinel去监听一个新的master

  • SENTINEL REMOVE <name> 命令sentinel放弃对某个master的监听

  • SENTINEL SET <name> <option> <value> 这个命令很像Redis的CONFIG SET命令，用来改变指定master的配置。支持多个<option><value>。例如以下实例：SENTINEL SET objects-cache-master down-after-milliseconds 1000
    只要是配置文件中存在的配置项，都可以用SENTINEL SET命令来设置。这个还可以用来设置master的属性，比如说quorum(票数)，而不需要先删除master，再重新添加master。例如：SENTINEL SET objects-cache-master quorum 5

• 测试
  • 手动关闭redis（master）节点，查看其他两个（slave）节点状态
  • 192.168.213.130被哨兵切换为新的master节点
  • 当前slave节点只有一个192.168.213.131

• 测试 
  • 查看当前数据，数据没有丢失

•  测试
  • 在新的master插入数据，ok

•  测试
  • 重启挂掉的原master节点
  • 查看哨兵日志，发现129节点变更为slave，并且归属与130节点master
  • 原master节点已经变更为slave
  • 获取所有key，数据已经被同步

• 注意 
  • 集群密码需要统一
  • 3个节点都需要配置密码（masterauth），如果没有配置则无法与集群关联，宕机的master节点恢复后变更为slave也将会与集群脱离
  • 默认开启磁盘化同步，主节点必须开启持久化RDB
• 建议：
  • 哨兵集群节点基本数量推荐3个为好
    • 1个独权，主观误判
    • 2个容易脑裂，意见不统一，选举失败
    • 3个少数服从多数，客观