网站的着陆页,太原推广型网站开发,企业宣传片拍摄公司,wordpress 侧边栏短代码是什么
官网理论#xff1a;https://redis.io/docs/management/sentinel/
吹哨人巡查监控后台 master 主机是否故障#xff0c;如果故障了根据投票数自动将某一个从库转换为新主库#xff0c;继续对外服务。
作用#xff1a;无人值守运维
哨兵的作用#xff1a; 1…是什么
官网理论https://redis.io/docs/management/sentinel/
吹哨人巡查监控后台 master 主机是否故障如果故障了根据投票数自动将某一个从库转换为新主库继续对外服务。
作用无人值守运维
哨兵的作用 1、监控redis运行状态包括master和slave 2、当master down机能自动将slave切换成新master 能干嘛 主从监控监控主从 redis 库运行是否正常
消息通知哨兵可以将故障转移的结果发送给客户端
故障转移如果Master异常则会进行主从切换将其中一个Slave作为新Master
配置中心客户端通过连接哨兵来获得当前Redis服务的主节点地址 案例演示及步骤
前提说明
案例需要实现的 Redis Sentinel 架构 3个哨兵自动监控和维护集群不存放数据只是吹哨人
1主2从用于数据读取和存放
配置文件参数说明
先看看目录下默认的sentinel.conf文件的内容 重点参数项说明 bind服务监听地址用于客户端连接默认本机地址 daemonize是否以后台daemon方式运行 protected-mode安全保护模式 port端口 logfile日志文件路径 pidfilepid文件路径 dir工作目录 下面两个标红的表示重要 sentinel monitor master-name ip redis-port quorum 设置要监控的master服务器quorum表示最少有几个哨兵认可客观下线同意故障迁移的法定票数。
行尾最后的quorum代表什么意思呢quorum确认客观下线的最少的哨兵数量。 我们知道网络是不可靠的有时候一个sentinel会因为网络堵塞而误以为一个master redis已经死掉了在sentinel集群环境下需要多个sentinel互相沟通来确认某个master是否真的死了quorum这个参数是进行客观下线的一个依据意思是至少有quorum个sentinel认为这个master有故障才会对这个master进行下线以及故障转移。因为有的时候某个sentinel节点可能因为自身网络原因导致无法连接master而此时master并没有出现故障所以这就需要多个sentinel都一致认为该master有问题才可以进行下一步操作这就保证了公平性和高可用。 sentinel auth-pass master-name password master设置了密码连接master服务的密码 其它 sentinel down-after-milliseconds master-name milliseconds 指定多少毫秒之后主节点没有应答哨兵此时哨兵主观上认为主节点下线
sentinel parallel-syncs master-name nums 表示允许并行同步的slave个数当Master挂了后哨兵会选出新的Master此时剩余的slave会向新的master发起同步数据
sentinel failover-timeout master-name milliseconds 故障转移的超时时间进行故障转移时如果超过设置的毫秒表示故障转移失败
sentinel notification-script master-name script-path 配置当某一事件发生时所需要执行的脚本
sentinel client-reconfig-script master-name script-path 客户端重新配置主节点参数脚本
案例步骤
在目录下新建或者拷贝sentinel.conf文件名字绝不能错配置三个哨兵。
配置sentinel文件 sentinel26379.conf bind 0.0.0.0
daemonize yes
protected-mode no
port 26379
logfile /myredis/sentinel26379.log
pidfile /var/run/redis-sentinel26379.pid
dir /myredis
sentinel monitor mymaster 192.168.111.169 6379 2
sentinel auth-pass mymaster 111111 sentinel26380.conf bind 0.0.0.0
daemonize yes
protected-mode no
port 26380
logfile /myredis/sentinel26380.log
pidfile /var/run/redis-sentinel26380.pid
dir /myredis
sentinel monitor mymaster 192.168.111.169 6379 2
sentinel auth-pass mymaster 111111 sentinel26381.conf bind 0.0.0.0
daemonize yes
protected-mode no
port 26381
logfile /myredis/sentinel26381.log
pidfile /var/run/redis-sentinel26381.pid
dir /myredis
sentinel monitor mymaster 192.168.111.169 6379 2
sentinel auth-pass mymaster 111111
看一眼sentinel26379.conf、sentinel26380.conf、sentinel26381.conf我们填写的内容 配置Redis
具体配置查看Redis复制 (replica)_Please Sit Down的博客-CSDN博客
一主二从3个redis实例测试正常的主从复制。 169机器上新建redis6379.conf配置文件由于要配合本次案例请设置masterauth项访问密码为111111不然后续可能报错master_link_status:down 172机器上新建redis6380.conf配置文件设置好replicaof masterip masterport 173机器上新建redis6381.conf配置文件设置好replicaof masterip masterport 启动Redis并连接 启动redis-server redis6379.conf 连接redis-cli -a 111111 -p 6379 启动redis-server redis6380.conf 连接redis-cli -a 111111 -p 6380 启动redis-server redis6381.conf 连接redis-cli -a 111111 -p 6381 启动sentinel redis-server sentinel26379.conf --sentinel redis-server sentinel26380.conf --sentinel redis-server sentinel26381.conf --sentinel 或 redis-sentinel sentinel26379.conf --sentinel redis-sentinel sentinel26380.conf --sentinel redis-sentinel sentinel26381.conf --sentinel 启动后查看启动实例信息 测试sentinel
我们自己手动关闭6379服务器模拟master挂了 三个问题
两台从机数据是否OK
结果数据OK
主节点下线后从节点获取数据会出现两个小问题 两种问题都一样都是broken pipe造成的pipe是管道的意思管道里面是数据流通常是从文件或网络套接字读取的数据。当该管道从另一端突然关闭时会发生数据突然中断即是broken对于socket来说可能是网络被拔出或另一端的进程崩溃。
解决问题其实当该异常产生的时候对于服务端来说并没有多少影响。因为可能是某个客户端突然中止了进程导致了该错误。
总结 Broken Pipe这个异常是客户端读取超时关闭了连接,这时候服务器端再向客户端已经断开的连接写数据时就发生了broken pipe异常 是否会从剩下的2台机器上选出新的master
结果投票新选
查看日志文件
sentinel26379.log sentinel26380.log sentinel26381.log 之前down机的master机器重启回来谁将会是新老大会不会双master冲突
本次案例6381选为新的master查看信息 以前的6379从master降级变成了slave 结果6380还是slave只不过换了个新老大63816379变63816380还是slave
配置文件变化
文件的内容在运行期间会被sentinel动态进行更改。
Master--Slave 切换后master redis.conf、slave redis.conf 和 sentinel..conf 的内容都会发生改变即 master中redis.conf中会多一行slave of的配置sentinel.conf的监控目标会随之调换。
redis6379.conf 哨兵运行流程和选举原理
当一个主从配置中的 master 失效之后sentinel 可以选举出一个新的 master 用于自动接替原 master 的工作主从配置中的其他 redis 服务器自动指向新的 master 同步数据。
一般建议 sentinel 采取奇数台防止某一台 sentinel 无法连接到 master 导致误切换。
运行流程
首先三个哨兵监控一主二从正常运行结构如下 1、SDown主观下线(Subjectively Down)
SDOWN主观不可用是单个sentinel自己主观上检测到的关于master的状态从sentinel的角度来看如果发送了PING心跳后在一定时间内没有收到合法的回复就达到了SDOWN的条件。
sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长度。
说明所谓主观下线Subjectively Down 简称 SDOWN指的是单个Sentinel实例对服务器做出的下线判断即单个sentinel认为某个服务下线有可能是接收不到订阅之间的网络不通等等原因。主观下线就是说如果服务器在[sentinel down-after-milliseconds]给定的毫秒数之内没有回应PING命令或者返回一个错误消息 那么这个Sentinel会主观的(单方面的)认为这个master不可以用了o(╥﹏╥)o sentinel down-after-milliseconds masterName timeout 表示master被当前sentinel实例认定为失效的间隔时间这个配置其实就是进行主观下线的一个依据master在多长时间内一直没有给Sentine返回有效信息则认定该master主观下线。也就是说如果多久没联系上redis-servevr认为这个redis-server进入到失效SDOWN状态。
2、ODown客观下线(Objectively Down)
ODOWN需要一定数量的sentinel多个哨兵达成一致意见才能认为一个master客观上已经宕掉
说明 四个参数含义
masterName 是对某个 masterslave 组合的一个区分标识一套 sentinel 可以监听多组masterslave这样的组合
quorum这个参数是进行客观下线的一个依据法定人数/法定票数重要参数
意思是至少有quorum个sentinel认为这个master有故障才会对这个master进行下线以及故障转移。因为有的时候某个sentinel节点可能因为自身网络原因导致无法连接master而此时master并没有出现故障所以这就需要多个sentinel都一致认为该master有问题才可以进行下一步操作这就保证了公平性和高可用。
3、选举出领导者哨兵哨兵中选出兵王 当主节点被判断客观下线以后各个哨兵节点会进行协商先选举出一个领导者哨兵节点兵王并由该领导者节点也即被选举出的兵王进行failover故障迁移
3哨兵日志文件分析
sentinel26379.log
sentinel26380.log 注本次是选举出26380位leader进行推选。
sentinel26381.log 哨兵领导者兵王如何选出来的
答案Raft算法 原理是监视该主节点的所有哨兵都有可能被选为领导者选举使用的算法是Raft算法Raft算法的基本思路是先到先得即在一轮选举中哨兵A向B发送成为领导者的申请如果B没有同意过其他哨兵则会同意A成为领导者
4、由兵王开始推动故障切换流程并选出一个新master
步骤一新主登基
某个Slave被选中成为新Master
选出新master的规则剩余slave节点健康前提下进行选举 a、redis.conf文件中优先级slave-priority或者replica-priority最高的从节点数字越小优先级越高 b、复制偏移位置 offset 最大的从节点
c、最小Run ID的从节点字典顺序ASCII码
步骤二群臣俯首
朝天子一朝臣换个码头重新拜
执行slaveof no one命令让选出来的从节点成为新的主节点并通过slaveof命令让其他节点成为其从节点Sentinel leader会对选举出的新master执行slaveof no one操作将其提升为master节点Sentinel leader向其它slave发送命令让剩余的slave成为新的master节点的slave
步骤三旧主拜服
老master回来也认怂
将之前已下线的老master设置为新选出的新master的从节点当老master重新上线后它会成为新naster的从节点Sentinel leader会让原来的naster降级为slave并恢复正常工作 小总结上述的failover操作均由sentinel自己独自完成完全无需人工干预。 哨兵使用建议
哨兵节点的数量应为多个哨兵本身应该集群保证高可用哨兵节点的数量应该是奇数各个哨兵节点的配置应一致如果哨兵节点部署在Docker等容器里面尤其要注意端口的正确映射哨兵集群主从复制并不能保证数据零丢失
