mysql哨兵模式_redis 哨兵模式集群搭建

Sentinel(哨兵)，顾名思义就是站岗放哨的，是redis提供的高可用解决方案，它是对主从模式的优化升级，在主从模式下，如果主库发生宕机，需要人工介入将某个从节点提升为主库，同时需要修改应用配置的主节点地址，而在Sentinel模式下，每个哨兵(Sentinel)进程会向其它哨兵(Sentinel)、Master、Slave定时发送消息，以确认对方是否”活”着，如果发现对方在指定时间内未得到回应，会对节点做下线标识，如果被标识的是主节点，它还会与其他Sentinel节点进行协商，当多数派都认为主节点不可达时，它们会选举出一个Sentinel节点来完成故障转移的工作，同时会通知应用方主节点已经发生转移。下面我们就来搭建一个Sentinel集群。

安装部署

环境准备

在这里我们使用的是Redis 4.0.10，在一台服务器上启动三个server来模拟一主两从的架构，redis的安装过程这里就不在演示了，可以参考文章【redis】部署及参数详解(吐血整理,建议收藏)。

部署过程

启动主节点

修改配置文件

/usr/local/redis/etc/redis_6377.conf，主要注意以下几个参数

port 6377

daemonize yes

logfile "/redis_data/log/redis_6377.log"

dir "/redis_data/data/6377"

dbfilename "dump_6377.rdb"

执行启动命令

redis-server /usr/local/redis/etc/redis_6377.conf

通过redis客户端连接测试

redis-cli -h 127.0.0.1 -p 6377

127.0.0.1:6377> ping

PONG

启动从节点

从节点配置文件和主节点配置文件的主要区别是将6377改成从节点对应的端口号，本次实验两个从节点的端口号分别为6378和6379。同时配置需要同步的主节点的IP和端口。

slaveof 127.0.0.1 6377

启动从节点

redis-server /usr/local/redis/etc/redis_6378.conf

redis-server /usr/local/redis/etc/redis_6379.conf

确认主从是否生效

[redis@localhost etc]$ redis-cli -h 127.0.0.1 -p 6377 info replication

Replication

role:master

connected_slaves:2

slave0:ip=127.0.0.1,port=6378,state=online,offset=308,lag=0

slave1:ip=127.0.0.1,port=6379,state=online,offset=308,lag=1

启动Sentinel节点

Sentinel节点至少3个且奇数，这样才能在协议中形成多数派。配置Sentinel节点配置文件/usr/local/redis/sentinel-26377.conf，主要注意以下参数

port 26377

dir "/redis_data/data/26377"

logfile "/redis_data/log/redis-26377.log"

#配置主节点的IP和端口，2代表主节点判断失败至少需要2个Sentinel节点同意，一般设置为Sentinel节点数的一半加1.

sentinel monitor mymaster 127.0.0.1 6377 2

#30秒ping不通主节点的信息，主观认为master宕机

sentinel down-after-milliseconds mymaster 30000

#故障转移时从节点同时向新主发起复制请求的数量，1代表从节点会轮询发起复制。

sentinel parallel-syncs mymaster 1

#故障转移开始，180秒内没有完成，则认为转移失败

sentinel failover-timeout mymaster 180000

启动Sentinel节点

redis-sentinel sentinel-26377.conf

redis-sentinel sentinel-26378.conf

redis-sentinel sentinel-26379.conf

通过Sentinel节点查看哨兵是否生效

[redis@localhost redis]$ redis-cli -h 127.0.0.1 -p 26377 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:6377,slaves=2,sentinels=3

至此，Sentinel模式的redis集群搭建就完成了。

故障转移

模拟主库宕机，通过kill命令杀死主库，查看故障转移情况：

128.127.0.0.1:26377> 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:6378,slaves=2,sentinels=3

可以看到master改为127.0.0.1:6378了。

故障转移的大体步骤如下：

每个Sentinel节点每隔1秒对主、从、其他Sentinel阶段发送ping探测，超过down-after-milliseconds未返回响应，则判断该节点主观下线。

Sentinel节点向其他Sentinel节点询问对于异常节点的判断，当达到 quorum个sentinel节点都认为被主观下线的节点异常时，则对该节点做客观下线。

在sentinel节点中通过Raft算法选举出一个leader来完成故障转移。

当出现故障的节点是主节点时，sentinel leader会根据优先级、复制偏移量、runid等在从节点中选出一个作为主节点，执行slaveof no one命令。

leader向其他从节点发送指令，让他们成为新主的从节点，并将原来的主节点更新为从节点，当旧主恢复后去复制新主的数据。

复制完成后，发布主节点的切换消息。