缓存架构实战-05-哨兵

概述

集群监控\消息通知\故障转移
哨兵本身也是分布式的,投票选举
哨兵至少需要3个实例
哨兵+主从不保证数据不丢失
quorum设为1,则只要有一个哨兵认为master宕机则进行切换
如果master哨兵同一节点,master所在机器挂掉,哨兵也挂掉,如果只有两个哨兵则无法进行切换

数据丢失问题

master异步复制数据过程挂掉,数据丢失
集群脑裂,由于网络问题认为master挂掉,slave切为master,客户端和旧的master连通继续写数据,网络恢复后数据丢失

# 要求至少1个slave,数据复制延迟不超过10s,否则master不接受请求
# 一般会在client做降级,减少数据涌入速度
# 或者使用mq
min-slaves-to-write 1
min-slaves-max-lag 10

哨兵底层原理

sdown 自己觉得master宕机
odown quorum个哨兵认为master宕机
哨兵之间发现是通过redis的pub/sub
通过slave跟master断开连接的时长\slave优先级\复制offset\runid选举master

哨兵部署

每一个哨兵可以监控不同的redis主从架构集群

# 创建哨兵目录
mkdir -p /var/sentinel/5000
---------------
# 修改配置sentinel.conf
bind 127.0.0.1 192.168.68.101
port 5000
dir /var/sentinel/5000
sentinel monitor mymaster 192.168.68.101 6379 2
# 超过多少毫秒断开连接认为一个redis实例挂掉
sentinel down-after-milliseconds mymaster 30000
# 执行故障转移的超时时长
sentinel failover-timeout mymaster 60000
# 口令
sentinel auth-pass mymaster redis-pass
# 每次挂接1个slave到master上
sentinel parallel-syncs mymaster 1
---------------

mkdir /etc/sentinel
cp sentinel.conf /etc/sentinel/5000.conf

# 复制配置到redis-02\redis-03节点,并修改bind ip

# 启动哨兵
redis-sentinel /etc/sentinel/5000.conf
# 连接到哨兵
redis-cli -h 192.168.68.101 -p 5000
# 查看master信息
sentinel master mymaster
# 查看slave信息
sentinel slaves mymaster

# 哨兵节点的增加会自动发现

# 哨兵节点的删除
# 停止sentinel进程
# 其他所有节点执行
sentinel reset *
# slave的永久下线
# 所有哨兵节点执行
sentinel reset mastername

容灾演练

# kill master redis进程
# 哨兵自动将slave提升为master
# 旧master重新启动，设为slave

哨兵生产环境部署

daemonize yes
logfile /var/log/sentinal/5000/sentinel.log

mkdir -p /var/log/sentinal/5000