Redis 高可用之主从哨兵集群实战

搭建集群

架构规划为一个主库节点，一个从库节点，三个哨兵节点，其中主从库节点内存配置需保持一致，哨兵节点对配置要求较低，可配置在主从节点上。

搭建主库

主从库节点内存配置需保持一致，主从库连接密码保持一致。主库不进行任何持久化配置，交给从库完成。

编写配置文件

需要注意的是，主库中部分配置也需要和从库保持一致，如masterauth、dir等。

在主库节点宕机重新启动后，如果哨兵已经完成选主，原来的主库就只能作为一个从库。被设置为从库后，会重写redis.conf，在其中新增{replicaof masterIP masterPort}信息，如

然后根据relpicaof配置与新的主库建立连接，而建立连接需要​masterauth​，如果没有事前进行该配置的话，会无法与主库建立连接。那为什么配置重写的时候不写masterauth配置？

vi redis.conf

port 6380
bind 0.0.0.0
requirepass passwd@190
masterauth passwd@190
dir​ /data
protected-mode no
save ""
replica-priority 100
maxmemory 4294967296
maxmemory-policy allkeys-lru

容器化​部署

挂载配置文件和data目录到容器，需要保证拥有读写权限

docker run --name redis -d --network host \
-v /data/redis/redis.conf:/etc/redis/redis.conf \
-v /data/redis_slave/data:/data \
redis:5.0.14 redis-server /etc/redis/redis.conf

搭建从库

从库开启持久化配置，AOF和RDB结合使用。

编写配置文件

vi redis.conf

port 6388
bind 0.0.0.0
requirepass passwd@190
protected-mode no
appendonly yes
appendfsync everysec
appendfilename appendonly.aof
dir /data
# 主节点连接信息 ip port
replicaof 172.0.0.1 6380
masterauth passwd@190
replica-priority 80
maxmemory 4294967296
maxmemory-policy allkeys-lru

容器化​部署

挂载配置文件和data目录到容器，需要保证拥有读写权限

docker run --name redis_slave -d --network host \
-v /data/redis_slave/redis.conf:/etc/redis/redis.conf \
-v /data/redis_slave/data:/data \
redis:5.0.14 redis-server /etc/redis/redis.conf

搭建哨兵

为了保证高可用，哨兵节点数量应该不少于三个。

编写配置文件

三个哨兵节点，端口分别为6390、6391、6393，其余配置保持一致。

vi sentinel.conf

port 26390
bind 0.0.0.0
protected-mode no
requirepass passwd@190
sentinel monitor master_6380 127.0.0.1 6380 2
sentinel auth-pass master_6380 passwd@190 
sentinel down-after-milliseconds master_6380 5000
sentinel failover-timeout master_6380 18000

容器化​部署

挂载配置文件到容器，需要保证拥有读写权限

docker run --name sentinel_1 -d --network host \
-v /data/redis_sentinel/node1/sentinel.conf:/etc/redis/sentinel.conf \
redis:5.0.14 redis-sentinel /etc/redis/sentinel.conf

集群验证

哨兵部署后，需要通过日志判断是否与主从库节点连接成功、哨兵之间是否已经组成了集群。需要注意的是，哨兵与从库和其余哨兵创建连接均需要通过主库节点，如果与主库的连接不通，那么哨兵将无法正常工作。

主从库连接

+monitor 表示正在对主库进行监控

+salve 表示与从库建立连接成功

如果在紧接着+ monitor master 后紧接着出现+ sdown master，这就表示主库宕机或者哨兵无法访问主库，需要做如下检查

• 主节点redis是否可以从外部访问
• 哨兵中配置的主节点访问密码是否正确

哨兵节点连接

+sentinel 表示与其他哨兵建立连接成功

主从切换

停掉redis主库，查看sentinel日志，可以发现sentinel发现了主库宕机并完成新主库的选举。原来的主库作为从库，并且当前状态为下线状态。

+sdown表示主库主观下线

+new-epoch 1表示开启第一次选主

配置重写

redis中支持运行时的配置修改，可以通过命令修改节点配置。

哨兵节点

在与主从库、其它哨兵完成连接和完成后主从切换后，都会将相关信息写入到sentinel.conf中，如

主库节点

在主库节点宕机后，哨兵集群会选举新的主库。选举出新的主库后，原来的主库可用后，会被作为从库加入集群。这个时候就会进行redis.conf配置重写，比较重要的是配置replicaof。

从库节点

在从库节点被选举为主库后，首先会重写redis.conf配置中的replicaof信息，将其删除。对其集群中的其他节点，也会重写replicaof信息，将其masterIP masterPort更新为新的主库节点信息。

注意事项

配置

在运行redis实例时，需要确保拥有配置文件、目录的读写权限。在没有文件的写入权限时，无法进行配置重写，从而无法完成主从切换。

同时，确保主从库的内存、连接密码等配置是一样的，主从库均需要配置masterauth信息。

持久化

在持久化配置方面，关闭主库的持久化，选择一个从库进行持久化。在集群完成主从切换后，需要关注主从库状态。

如果选举的新主库同时也是持久化节点，需要通过重写命令关闭其持久化，选择一个从库开启持久化。因为既是主库又是持久化节点，对集群的写入性能会影响较大。

但这种方式比较傻，不可靠，只适用于只有一个从库时。在有多个从库存在时，我们可以根据哨兵选主的逻辑，即优先选择优先级高的从库作为主库。为从库设置不同的优先级（replica-priority），在优先级低的从库进行持久化操作，这样就可以避免其被选择为主库节点。

主库也可能变成从库，所以同样需要配置replica-priority。

配置解析

Server

redis.conf

Bash
# 绑定端口
port 6380
# 绑定主机上所有网络接口
bind 0.0.0.0
# 连接密码
requirepass passwd@190
# 关闭保护模式，允许客户端连接
protected-mode no

# 不进行持久化操作
save ""
# 开启AOF日志进行持久化操作
appendonly yes
# AOF日志文件名
appendfilename appendonly.aof
# 数据目录，包括rdb和aof文件
dir /data
# 要连接的主库信息
replicaof 172.0.0.1 6380
# 主库密码
masterauth passwd@190
# 从库权重，默认100
replica-priority 100

# 最大可分配内存4GB，单位是byte
maxmemory 4294967296
# 达到最大分配内存后进行得策略，默认为noeviction，不进行额外操作，在接收到写入操作时返回错误。
# 这里配置为lru
maxmemory-policy allkeys-lru

Sentinel

sentinel.conf

# 端口
port 6390
# 绑定主机上所有网络接口
bind 0.0.0.0
# 关闭保护模式
protected-mode no
# 访问密码
requirepass passwd@190

# 配置主库master_6380（主库别名）连接信息，并设置主从切换时需获得的最少投票数（这里设置为2，计算公式为（哨兵节点数/2）+ 1）
sentinel monitor master_6380 127.0.0.1 6380 2
# 配置主库master_6380的连接密码
sentinel auth-pass master_6380 passwd@12p 
# 判断主master的挂机时间（毫秒），超时未返回正确信息后标记为sdown状态（主观下线）
sentinel down-after-milliseconds master_6380 5000
# 若sentinel在该时间值内（毫秒）未能完成failover操作（即故障时master/slave自动切换），则认为本次failover失败。
sentinel failover-timeout master_6380 18000