Redis复制的高可用详解
一、sentinel基础
在Redis的主从复制中有一个问题很明显,比如说在一主三从的架构下,如果主节点宕机,那么所有的写操作也就不能执行了,这个主从复制架构也就瘫痪了,所以Redis引入了sentinel机制。
sentinel其实就是一个额外的主机,这个主机既可以提供监控,也可以提供配置的功能,也就是说他可以监控所有的主机状态,当主节点宕机,他可以自动的从所有的从节点中挑选一个将其升级为主节点,当产生了新的主节点之后,其他的性节点会向sentinel发送查询请求,查看当前主节点是哪个,以此来获得新的主节点。所以sentinel是Redis主从架构中,实现高可用的解决方案。
还有一个问题,如果是sentinel自己出了问题导致其检测不到主节点,但是主节点其实并没有出问题,这就会导致脑裂,所以为了解决这个问题,我们往往设置多个sentine节点,他们共同监控主节点,当有任意一台sentinel发现找不到主节点的时候,这些sentinel会相互商议并投票确定是否主节点真的出了问题,这样还能解决一个问题就是当某个sentinel出现故障,其他sentinel节点还可以继续监控主从复制架构。
需要注意的是,sentinel只监控主节点服务器,因为它会通过主服务器的信息发现各个从服务器节点,并将从服务器节点纳入到被监控节点中。
sentinel的配置文件
sentinel的专用配置文件:/etc/redis-sentinel.conf
sentinel的端口:26379
在这个配置文件中每个sentinel实例大概需要四项配置
- 设置所监控的主节点的信息
# sentinel monitor <master-name> <ip> <redis-port> <quorum>sentinel monitor mymaster 10.220.5.171 6379 2
说明:master-name
如果不是用主机名来唯一区分每个节点的话,这个名字可以随便写
如果监控多组主从的话这个名称应该不同
ip:主节点的IP地址
redis-port:主节点监听的端口
quorum:
这个数值是表明这个主节点至少拥有几票才能认为这个节点是有效的
如果只有一个sentinel节点的话,这个数值应该设置为1
通常sentinel节点建议设置为奇数个,这样这个数值可以设置成半数以上,这样才有意义(防止脑裂)
注意:一个sentinel集群,可以监控多组redis主从复制集群,所以上面这行代码配置可以出现多次
- 设置主节点多长时间没有信息认为其已经离线
# Default is 30 seconds.
sentinel down-after-milliseconds mymaster 30000
注意:这里的时间单位是毫秒,30000就是30秒
- 设置当主服务器宕机的时候,允许多少从服务器同时向sentinel发送链接请求。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1
- 发生故障转移的超时时间
# Default is 3 minutes.
sentinel failover-timeout mymaster 180000
说明:这里就是设置在将从节点设置为主节点的时候,如果多久没有提升成功,就认为这次提升失败了。
启动sentinel方式
sentinel其实就是Redis的一个组件而已,在安装Redis的时候就已经自带了,就叫做redis-sentinel,另外,用redis-server启动时候指定选型 --sentinel,也可以实现启动sentinel。
需要注意的是在启动sentinel的时候,必须指定起自己的配置文件,这个配置文件会用于保存redis的配置信息。
总结启动方式有两种:
redis-sentinel /path/to/file.conf
redis-server /path/to/file.conf --sentinel
启动sentinel的步骤
- 初始化sentinel:运行redis-server专用于sentinel的代码
- 初始化sentinel的状态:根据配置文件,初始化天空master的主机列表
- 创建连接到主服务器的网络连接
sentinel的专用命令
SENTINEL master :显示所有被监控的master节点
SENTINEL slaves <masterName>:获取指定主服务器的从节点
SENTINEL get-master--addr-by-name <masterName> :根据名字来获取IP地址
SENTINEL reset :清除sentinel的全部状态,包括正在执行的故障转移
SENTINEL failover:手动执行故障转移,也就是当主节点故障时,在不询问其他节点的情况下,强制执行故障转移
sentinel主观下线、客观下线概念
主观下线,也就是一个sentinel认为主节点下线了,对于这个sentinel来说主机下线在目前是主观下线,但是此时还需要征求其他sentinel的意见,如果所有的sentinel都认为这个主节点下线了,那么此时主观下线就变成了客观下线。
sentinel用于实现监控各个节点的方式就是,当master被sentinel监控之后,master每隔一秒向sentinel发送ping,用这个来作为心跳信息。
二、 演示:Redis复制的高可用
这里我来模拟一个一主两从的架构,可以在多个主机上来做,但是这里我用redis多实例来做,多个实例分别监听6379、6380、6381端口。
第一步:配置redis多实例
需要注意的是:在配置多实例的时候端口、pid文件、日志文件、数据文件路径、不能相同。
- 创建目录
[root@171 ~]# mkdir /redis/{6379,6380,6381} -pv
[root@171 ~]# cp /etc/redis.conf /redis/6379/redis1.conf
[root@171 ~]# cp /etc/redis.conf /redis/6380/redis2.conf
[root@171 ~]# cp /etc/redis.conf /redis/6381/redis3.conf
[root@171 ~]# chown -R redis.redis /redis
- 编辑配置文件
# 第一个节点配置
[root@171 ~]# vim /redis/6379/redis1.conf
port 6379
daemonize yes
pidfile /var/run/redis_6379.pid
logfile /var/log/redis/redis_6379.log
dir /redis/6379# 第二个节点配置
[root@171 ~]# vim /redis/6380/redis2.conf
port 6380
daemonize yes
pidfile /var/run/redis_6380.pid
logfile /var/log/redis/redis_6380.log
dir /redis/6380# 第三个节点配置
[root@171 ~]# vim /redis/6381/redis3.conf
port 6381
daemonize yes
pidfile /var/run/redis_6381.pid
logfile /var/log/redis/redis_6381.log
dir /redis/6381
- 启动服务
[root@171 ~]# redis-server /redis/6379/redis1.conf
[root@171 ~]# redis-server /redis/6380/redis2.conf
[root@171 ~]# redis-server /redis/6381/redis3.conf
[root@171 ~]# ss -tnl
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 10.220.5.171:6379 *:*
LISTEN 0 128 10.220.5.171:6380 *:*
LISTEN 0 128 10.220.5.171:6381 *:*
第二步:配置redis主从
将6379设置为主,6380 6381都设置为从
- 查看6379的复制状态
[root@171 ~]# redis-cli -h 10.220.5.171 -p 6379
10.220.5.171:6379> info replication
# Replication
role:master
connected_slaves:0
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:0
- 将6380的主设置为6379
[root@171 ~]# redis-cli -h 10.220.5.171 -p 6380
10.220.5.171:6380> SLAVEOF 10.220.5.171 6379
OK
- 将6381的主设置为6379
[root@171 ~]# redis-cli -h 10.220.5.171 -p 6381
10.220.5.171:6381> SLAVEOF 10.220.5.171 6379
OK
- 此时在主节点可以看到连接的从节点
10.220.5.171:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=10.220.5.171,port=6380,state=online,offset=308,lag=1
slave1:ip=10.220.5.171,port=6381,state=online,offset=308,lag=1
- 测试一下主从是否正常
# 主节点写入数据
10.220.5.171:6379> set name xiaoming
OK
# 从节点查看是否有数据
10.220.5.171:6380> get name
"xiaoming"
10.220.5.171:6381> get name
"xiaoming"
第三步:配置监控节点
这里我启用一个sentinel做节点监控
- 创建目录
[root@171 ~]# mkdir /redis/sentinel
[root@171 ~]# cp /etc/redis-sentinel.conf /redis/sentinel/
[root@171 ~]# chown redis.redis /redis/sentinel/ -R
- 修改配置文件
[root@171 ~]# vim /redis/sentinel/redis-sentinel.conf
sentinel monitor mymaster 10.220.5.171 6379 1
sentinel down-after-milliseconds mymaster 3000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
protected-mode no
daemonize yes
- 启动sentinel
[root@171 ~]# redis-sentinel /redis/sentinel/redis-sentinel.conf
[root@171 ~]# ss -tnl |grep 26379
LISTEN 0 128 *:26379 *:*
LISTEN 0 128 :::26379 :::*
- 连入sentinel查看master的状态
[root@171 ~]# redis-cli -h 10.220.5.171 -p 26379
10.220.5.171:26379> sentinel masters
1) 1) "name"2) "mymaster"3) "ip"4) "10.220.5.171"5) "port"6) "6379"7) "runid"8) "e8deacd44d2f3d99a005a110f6600cebd42c9a5f"9) "flags"10) "master"# 也可以查看一下mymaster这个节点的从节点有哪些10.220.5.171:26379> sentinel slaves mymaster
第四步:模拟主节点故障
这里我直接关闭主节点服务来模拟主节点宕机
[root@171 ~]# ps aux |grep 6379
root 1810 0.6 0.9 147356 9764 ? Ssl 03:50 0:13 redis-server 10.220.5.171:6379
[root@171 ~]# kill -9 1810
# 稍等一分钟,查看一下此时的主节点
10.220.5.171:26379> sentinel masters
1) 1) "name"2) "mymaster"3) "ip"4) "10.220.5.171"5) "port"6) "6381" <<<<<<已经主节点变成了63817) "runid"
注意:即使故障节点恢复了,也不会直接变为主节点而是会成为从节点。
到这里redis的主从复制高可用就大功告成了,如有疑问欢迎评论留言,公共探讨,共同进步。
------做运维之前很矫情的小年轻-----
Redis复制的高可用详解相关推荐
- redis作用_Redis高可用详解:持久化技术及方案选择
本文将先说明上述几种技术分别解决了Redis高可用的什么问题,然后详细介绍Redis的持久化技术,主要是RDB和AOF两种持久化方案.在介绍RDB和AOF方案时,不仅介绍其作用及操作方法,同时还会介绍 ...
- Redis的高可用详解:Redis哨兵、复制、集群的设计原理,以及区别
谈到Redis服务器的高可用,如何保证备份的机器是原始服务器的完整备份呢?这时候就需要哨兵和复制. 哨兵(Sentinel):可以管理多个Redis服务器,它提供了监控,提醒以及自动的故障转移的功能. ...
- Redis高可用详解:持久化技术及方案选择
文章摘自:https://www.cnblogs.com/kismetv/p/9137897.html 前言 在上一篇文章中,介绍了Redis的内存模型,从这篇文章开始,将依次介绍Redis高可用相关 ...
- 运维企业专题(8)LVS高可用与负载均衡后篇——LVS健康检查与高可用详解
实验准备 1.下面的实验使用的是rhel6系列(rhel6.5)的虚拟机,因此你需要有对应的镜像和yum源 2.准备三台虚拟机,为了区分主机名与IP分别为 server1 172.25.6.1 ser ...
- Nginx简介配置及高可用详解
1.Nginx简介 2.nginx指令配置详解 3.nginx负载均衡及反向代理实现 4.nginx浏览器跨域问题 5.nginx防盗链 6.nginx缓存 7.nginx压缩 8.nginx配置ht ...
- sparkstreaming监听hdfs目录如何终止_HDFS—HA高可用详解
一.HA概述 1)所谓HA(high available),即高可用(7*24小时不中断服务). 2)实现高可用最关键的策略是消除单点故障.HA严格来说应该分成各个组件的HA 机制:HDFS的HA和Y ...
- 互联网架构之 “高可用” 详解
一.什么是高可用 高可用HA(High Availability)是分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计减少系统不能提供服务的时间. 假设系统一直能够提供服务,我们说系统的可用 ...
- keepalived实现haproxy高可用详解
一,keepalived介绍 keepalived是一个可以实现某些资源高可用的开源软件,其主要的组件包括core,check,vrrp,libipfwc,libipvs,这里说下各个组件的功能. c ...
- LVSKeepalived—集群、负载均衡、企业高可用详解
LVS负载均衡集群及配置 负载均衡概述 1.集群 通过集群(cluster)技术,可以在付出较低成本的情况下获得在性能.可靠性.灵活性方面的相对高的收益,其任务调度则是集群系统中的核心技术. 集群搭建 ...
最新文章
- tomcat安装apr优化
- python处理数据的优势-【Python数据分析基础】: 数据缺失值处理
- java获取当前tomcat线程pid_java 查看tomcat线程信息(示例代码)
- 三维重建:重定位问题
- Angular Route数据结构里常用字段使用方法一览
- 兄弟机cnc系统面板图解_FANUC软操作面板的应用介绍,真的太详细了
- mysql游标表间数据迁移_FalseMySQL存储过程--gt;通过游标遍历和异常处理迁移数据到历史表-mysql-第二电脑网...
- Azure SQL性能调优实践
- linux 基础学习之常用命令
- Spring中采用公共变量并发问题解决
- 安装MySQL-python时发生错误:error: command 'gcc' failed with exit status 1
- 护卫神 mysql 升级_护卫神php套件 php版本升级方法
- 国土防线2计算机内存不足,国土防线2革命配置要求高吗?PC配置要求介绍
- 配置DeepStreaks环境
- 数据分析-主成分分析流程(R语言)
- [图文]历届奥斯卡影后(上)
- 数据库基础知识汇总!
- 目前大部分的游戏框架_简单的Windows游戏-第1部分:游戏框架
- 安卓开发学习笔记1:简单控件
- 民锋国际期货量化交易策略源代码大全