redis哨兵，集群和运维

Redis Sentinel(哨兵)

7.1 哨兵介绍
Sentinel介绍
redis的主从模式下，主节点一旦发生故障不能提供服务，需要人工干预，将从节点晋升为主节点同时还需要修改客户端配置。对于很多应用场景这种方式无法接受。
Sentinel(哨兵)架构解决了redis主从人工干预的问题。
redis sentinel是redis的高可用实现方案，实际生产环境中，对提高整个系统可用性非常有帮助的。

7.2 哨兵主要功能
Redis Sentinel 是一个分布式系统, Redis Sentinel为 Redis 提供高可用性。可以在没有人为干预的情况下阻止某种类型的故障。
redis的sentinel系统用于管理多个redis服务器(instance)该系统执行以下三个任务:
1.监控(Monitoring):
Sentine1 会不断地定期检查你的主服务器和从服务器是否运作正常。
2.提醒(Notification):
当被监控的某个 Redis服务器出现问题时， sentinel可以通过 API 向管理员或者其他应用程序发送通知。
3.自动故障迁移(Automatic failover)
当一个主服务器不能正常工作时， sentine1 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器; 当客户端试图连接失效的主服务器时，集群也会向客户端返回新主服务器的地址，
使得集群可以使用新主服务器代替失效服务器

 

安装命令

哨兵是基于主从复制，所以需要先部署好主从复制手工操作步骤如下:
1.先配置和创建好1台服务器的节点和哨兵
2.使用 rsync 传输到另外2台机器
3.修改另外两台机器的ip地址 建议使用 ansible 脚本本批量部署

db01命令

 配置文件详解：

 

db02/db03命令

主从关系:
从库执行:
SLAVEOF 10.0.0.51 6379

启动哨兵:
redis-sentinel /opt/redis_cluster/redis_26379/conf/redis_26379.conf

master服务器日志

 从服务器日志

 

 故障转移

 

 

停掉其中1个节点，然后观察其他节点的日志变化
故障转移后配置文件变化
Redis sentine1 存在多个从节点时,如果想将指定的从节点晋升为主节点,可以将其他从节点的 slavepriority配置为 0,但是需要注意 failover后,将 slave-priority 调回原值
1.查询命令:CONFIG GET slave-priority
2.设置命令:CONFIG SET slave-priority 0
3.主动切换:sentinel failover mymaster
操作过程:
db02/db03 操作
redis-cli -h db02 -p 6379 CONFIG SET slave-priority 0
redis-cli -h db03 -p 6379 CONFIG SET slave-priority 0

db01操作
redis-cli -h db01 -p 26379 Sentinel failover mymaster

哨兵故障恢复
1,先启动db01
redis-server /opt/redis-cluster/redis_6379/conf/redis_6379.conf
2.启动哨兵
redis-sentinel /opt/redis_cluster/redis_26379/conf/redis_26379.conf
3.设置权重db01调大权重
CONFIG SET slave-priority 150
4.重新发起选举
在db01上的26379节点执行
rcedis-cli -h 10.0.0.51 -p 26379 Sentinel failover mymaster
5.观察主从复制是否正常
redis-cli
CONFIG GET slaveof
6.db01恢复权重
CONFIG SET slave-priority 100

 

哨兵的不足

• 1.配置复杂
• ansible利用模块和模板
• 2.中断时间长
• 3.资源利用率低，只有一台主库对外提供服务
• 4.3台只能挂1台
• 5.依赖于redis数据节点
• 6.主库压力比较大，性能有瓶颈

 

二，redis cluster集群

集群介绍
Redis Cluster 是redis的分布式解决方案，在3.0版本正式推出
当遇到单机、内存、并发、流量等瓶颈时，可以采用 Cluster 架构方案达到负载均衡目的。
Redis Cluster 之前的分布式方案有两种:

• 1)客户端分区方案，优点分区逻辑可控，缺点是需要自己处理数据路由，高可用和故障转移等。
• 2)代理方案，优点是简化客户端分布式逻辑和升级维护便利，缺点加重架构部署和性能消耗。

官方提供的 Redis Cluster 集群方案，很好的解决了集群方面的问题

数据分布
分布式数据库首先要解决把整个数据库集按照分区规则映射到多个节点的问题，即把数据集划分到多个节点上，每个节点负责整体数据的一个子集，需要关注的是数据分片规则，Redis Cluster 采用哈希分片规则。

 目录规划

 

搭建集群互相发现 

手动部署集群：

思路:
1)部署一台服务器上的 2个集群节点2)发送完成后修改其他主机的 P 地址
3)使用 ansible 批量部署实现命令:
db01 操作

mkdir -p /opt/redis_cluster/redis_{6880,6381}/{conf,logs,pid)
mkdir -p /data/redis_cluster/redis_{6380,6381}

cat >/opt/redis_cluster/redis_6380/conf/redis_6380.conf<<EOF
bind 10.0.0.51
port 6380
daemonize yes
pidfile "/opt/redis_cluster/redis_6380/pid/redis_6380.pid"
logfile "/opt/redis_cluster/redis_6380/logs/redis_6380.log"
dbfilename "redis_6380.rdb"
dir "/data/redis_cluster/redis_6380/"
cluster-enabled yes
cluster-config-file nodes_6380.conf
cluster-node-timeout 15000
EOF

cd /opt/redis_cluster
cp redis_6380/conf/redis_6380,conf  redis_6381/conf/redis_6381.conf
sed -i 's#6380#6381#g' redis_6381/conf/redis_6381.conf 
rsync -avz /opt/redis_cluster/redis_688* db02:/opt/redis_cluster/
rsync -avz /opt/redis_cluster/redis_638* db03:/opt/redis cluster/
redis-server /opt/redis_cluster/redis_6380/conf/redis_6380.conf
redis-server /opt/redis_cluster/redis_6381/conf/redis_6381. conf

db02操作

find /opt/redis_cluster/redis_638*  -type f -name "*.conf"| xargs sed -i "/bind/s#51#52#g" 
mkdir -p /data/redis_cluster/redis_{6380,6381}
redis-server /opt/redis_cluster/redis_6380/conf/redis_6380.conf
redis-server /opt/redis_cluster/redis_6381/conf/redis_6381.conf

db03操作

find /opt/redis_cluster/redis_638*  -type f -name "*.conf"| xargs sed -i "/bind/s#51#53#g" 
mkdir -p /data/redis_cluster/redis_{6380,6381}
redis-server /opt/redis_cluster/redis_6380/conf/redis_6380.conf
redis-server /opt/redis_cluster/redis_6381/conf/redis_6381.conf

启动服务

当把所有节点都启动后查看进程会有 c1uster 的字样

集群发现

 

 

 节点发现

使用命令:CLUSTER MEET {IP}{PORT}提示:在集群内任意一台机器执行此命令就可以

 

集群分配操作

 通讯流程

在分布式存储中需要提供维护节点元数据信息的机制，所谓元数据是指:节点负责哪些数据，是否出现故障灯状态信息，redis 集群采用 Gossip(流言)协议，Gossip 协议工作原理就是节点彼此不断交换信息，一段时间后所有的节点都会知道集群完整信息，这种方式类似流言传播通信过程:

• 1)集群中的每一个节点都会单独开辟一个 Tcp 通道，用于节点之间彼此通信，这通信端口在基础端口上家 10000.
• 2)每个节点在固定周期内通过特定规则选择结构节点发送ping消息
• 3)接收到 ping消息的节点用 pong消息作为响应。集群中每个节点通过一定规则挑选要通信的节点，每个节点可能知道全部节点，也可能仅知道部分节点，只要这些节点彼此可以正常通信，最终他们会打成一致的状态，当节点出现故障，新节点加入，主从角色变化等，它能够给不断的ping/pong消息，从而达到同步目的。

 

 通讯消息类型

Gossip
Gossip 协议职责就是信息交换，信息交换的载体就是节点间彼此发送 cossip 消息。常见 Gossip 消息分为:ping、pong、meet、fail等
meet
meet 消息:用于通知新节点加入，消息发送者通知接受者加入到当前集群，meet消息通信正常完成后，接收节点会加入到集群中并进行 ping、pong 消息交换

ping
ping 消息:集群内交换最频繁的消息，集群内每个节点每秒想多个其他节点发送 ping 消息，用于检测节点是否在线和交换彼此信息。
Pong
Pong 消息:当接收到 ping，meet 消息时，作为相应消息回复给发送方确认消息正常通信，节点也可以向集群内广播自身的 pong消息来通知整个集群对自身状态进行更新。
fail
fail 消息:当节点判定集群内另一个节点下线时，回向集群内广播一个 fai1 消息，其他节点收到 fai1 消息之后把对应节点更新为下线状态。

手动分配槽位 Redis Cluster

虽然节点之间已经互相发现了,但是此时集群还是不可用的状态,因为并没有给节点分配槽位,而且必须是所有的槽位都分配完毕后整个集群才是可用的状态反之,也就是说只要有一个槽位没有分配,那么整个集群就是不可用的测试命令:

[root@db01# sh redis_shell.sh login 6380
10.0.0.51:6380> set kl v1
(error)CLUSTERDOWN Hash slot not served

 前面说了,我们虽然有6个节点,但是真正负责数据写入的只有3个节点,其他3个节点只是作为主节点的从节点,也就是说,只需要分配期中三个节点的槽位就可以了分配槽位的方法:

分配槽位需要在每个主节点上来配置,此时有2种方法执行:

• 1.分别登录到每个主节点的客户端来执行命令
• 2.在其中一台机器上用 redis客户端远程登录到其他机器的主节点上执行命令

  分配完所有槽位之后我们再查看一下集群的节点状态和集群状态可以看到三个节点都分配了槽位,而且集群的状态是 OK 的

 

51机器

ask路由

 

 -c 命令会帮我们找到正确节点写入命令

集群的高可用》

 

 

 故障恢复过程

准备工作：

 

 

 [root@db01 ~]#  redis-cli -c -h db01 -p 6381 cluster nodes|grep -v "6381" | awk '{print $1,$2}'

 

 停掉db01机器的6380端口redis

• 杀掉进程或者shutdown
• 查看集群状态都显示正常

• 

   

启动db01的6380后发现

 让db01的6380恢复成master节点命令

CLUSTER FAILOVER

执行过程一定要等数据同步完成后再执行，不然会出现数据清空的情况，查看日志下面的xxxx.rdb.tmp文件 是否同步完成