Redis之高可用方案

Redis之高可用方案

 

Redis以其高效的访问速度著称。但由于官方还未发布redis-cluster,而redis的replica又有诸多不便:比如一组master-slave的机器,如果之间有链接瞬段,或者对slave重新执行slaveof命令,会导致slave机器从头开始同步一次master的数据,造成较大的开销。

 

以下描述了使用keepalived+redis主从的一种高可用方法。安装方法在这里就不赘述了,google之则可。

1. redis服务配置

主机     端口   角色

redis0 6379   master

redis1 6379   slave

 

2. keepalived的配置

redis0和redis1使用一个虚拟ip

 

并使用如下脚本监控redis服务是否存活。监控脚本:

 

 

[html] view plaincopy

 

  1. #!/bin/bash  
  2. /usr/local/bin/redis-cli -h 192.168.1.53 -p 6379 info > /dev/null  
  3. if [ $? -eq 0 ]; then  
  4. echo "redis OK"  
  5. exit 0  
  6. else  
  7. echo "no redis service found!"  
  8. /usr/local/bin/redis-server /path/to/redis.conf  
  9.   
  10. # try to start it again  
  11. /usr/local/bin/redis-cli -h 192.168.11.53 -p 6380 info > /dev/null  
  12. if [ $? -eq 0 ]; then  
  13. exit 0  
  14. else  
  15.   
  16. # restart failed  
  17. killall keepalived  
  18. echo "error"  
  19. fi  
  20. fi  

 

要实现redis故障恢复,可以使用keepalived配置的notify_master, notify_backup这两个方法执行特有的脚本。实际上只要在slave(即redis1)上有2个脚本,第一个用于在redis1接管虚拟ip之后,执行slaveof no one把自己变成master。第二个用户在redis1交出虚拟ip之后,在redis0执行slaveof no one确保redis0恢复为主的状态,并对自己执行slaveof redis0 6379开始重新从master同步数据,如果自己已经是slave就没必要同步了。

 

redis1上keepalived的配置方法如下,redis0只要去掉notify_master, notify_backup两行即可。

[cpp] view plaincopy

 

  1. ! Configuration File for keepalived  
  2. global_defs {  
  3. router_id redis1  
  4. }  
  5. vrrp_script Monitor_Redis {  
  6.  script "/opt/redis_keepalive.sh"  
  7.  interval 10  
  8.  weight 2  
  9. }  
  10. vrrp_instance 360 {  
  11.  state BUCKUP #(主机为MASTER,备用机为BACKUP)  
  12.  interface eth0 #(HA监测网络接口)  
  13.  virtual_router_id 110 #(主、备机的virtual_router_id必须相同)  
  14.  mcast_src_ip 192.168.11.53 #(多播的源IP,设置为本机外网IP,与VIP同一网卡)此项可不设置  
  15.  priority 70 #(主、备机取不同的优先级,主机值较大,备份机值较小,值越大优先级越高)  
  16.  advert_int 1 #(VRRP Multicast广播周期秒数)  
  17.  authentication {  
  18.   ......  
  19. }  
  20.  notify_master /opt/redis_2master.sh  
  21.  notify_backup /opt/redis_2backup.sh  
  22.  track_script {  
  23.  Monitor_Redis #(调用nginx进程检测脚本)  
  24. }  
  25.  virtual_ipaddress {  
  26.  192.168.11.4 #(VRRP HA虚拟地址)  
  27.  }  
  28. }  
时间: 2024-10-29 01:23:22

Redis之高可用方案的相关文章

Redis Cluster 高可用方案

一.Redis Cluster Cluster介绍  Redis 集群采用无中心的方式,为了维护集群状态统一,节点之间需要互相交换消息.Redis采用交换消息的方式被称为 Gossip ,基本思想是节点之间互相交换信息最终所有节点达到一致,更多关于 Gossip 可参考 https://en.wikipedia.org/wiki/Gossip_protocol .   Redis 集群是一个提供在多个Redis间节点间共享数据的程序集.   Redis集群并不支持处理多个keys的命令,因为这需

云数据库Redis版主从热备高可用方案

引言 高可用(High Available)是线上生产环境所必不可少的重要条件,阿里云数据库Redis版作为一款成熟稳定的数据库产品,针对Redis的特性也支持高可用,本文将介绍云Redis是如何实现这一方案. 架构 目前云Redis有主从版和集群版两种架构,本次主要针对主从版做HA的解析. 下图为主从版架构: 由图可知,云Redis实例有主备两个节点,平时只有Master提供服务,Slave只做热备不提供访问,Slave通过slaveof命令挂载到Master上,不断从Master接收数据,保

基于Redis Sentinel的Redis集群(主从Sharding)高可用方案(转)

本文主要介绍一种通过Jedis&Sentinel实现Redis集群高可用方案,该方案需要使用Jedis2.2.2及以上版本(强制),Redis2.8及以上版本(可选,Sentinel最早出现在Redis2.4中,Redis2.8中Sentinel更加稳定),Redis集群是以分片(Sharding)加主从的方式搭建,满足可扩展性的要求: Redis Sentinel介绍 Redis Sentinel是Redis官方提供的集群管理工具,主要有三大功能: 监控,能持续监控Redis的主从实例是否正常

5项优化4种高可用方案,MySQL常用架构调优这样做!

选择Percona Server.MariaDB还是MYSQL   1.Mysql三种存储引擎   MySQL提供了两种存储引擎:MyISAM和 InnoDB,MySQL4和5使用默认的MyISAM存储引擎.从MYSQL5.5开始,MySQL已将默认存储引擎从MyISAM更改为InnoDB.   MyISAM没有提供事务支持,而InnoDB提供了事务支持.   XtraDB是InnoDB存储引擎的增强版本,被设计用来更好的使用更新计算机硬件系统的性能,同时还包含有一些在高性能环境下的新特性.  

MySQL数据库的几种常见高可用方案

随着人们对数据一致性的要求不断的提高,越来越多的方法被尝试用来解决分布式数据一致性的问题,如MySQL自身的优化.MySQL集群架构的优化.Paxos.Raft.2PC算法的引入等等,本文介绍MySQL数据库的几种常见高可用方案. 一.概述 我们在考虑MySQL数据库的高可用的架构时,主要要考虑如下几方面: 如果数据库发生了宕机或者意外中断等故障,能尽快恢复数据库的可用性,尽可能的减少停机时间,保证业务不会因为数据库的故障而中断. 用作备份.只读副本等功能的非主节点的数据应该和主节点的数据实时或

10款常见MySQL高可用方案选型解读

作者介绍 王松磊,现任职于UCloud,从事MySQL数据库内核研发工作.主要负责UCloud云数据库udb的内核故障排查工作以及数据库新特性的研发工作.   一.概述   我们在考虑MySQL数据库的高可用架构时,主要考虑如下几方面:   如果数据库发生了宕机或者意外中断等故障,能尽快恢复数据库的可用性,尽可能的减少停机时间,保证业务不会因为数据库的故障而中断. 用作备份.只读副本等功能的非主节点的数据应该和主节点的数据实时或者最终保持一致. 当业务发生数据库切换时,切换前后的数据库内容应当一

MySQL数据库的高可用方案总结_Mysql

高可用架构对于互联网服务基本是标配,无论是应用服务还是数据库服务都需要做到高可用.虽然互联网服务号称7*24小时不间断服务,但多多少少有一些时候服务不可用,比如某些时候网页打不开,百度不能搜索或者无法发微博,发微信等.一般而言,衡量高可用做到什么程度可以通过一年内服务不可用时间作为参考,要做到3个9的可用性,一年内只能累计有8个小时不可服务,而如果要做到5个9的可用性,则一年内只能累计5分钟服务中断.所以虽说每个公司都说自己的服务是7*24不间断的,但实际上能做到5个9的屈指可数,甚至根本做不到

联想企业云盘高可用方案:为数据提供万无一失的保障

 云存储和大数据背景下,数据呈爆炸式增长.研究显示,2020年全球非结构化数据总量将达到35.2 ZB,比2009年的0.8 ZB猛增44倍.对企业来讲,如何高效管理数据并发挥数据价值,进而为企业创造更大的效益成为亟待解决的问题.面对这一问题,越来越多的企业采用网盘系统,作为企业数据存储.分享及管理的工具. 然而,任何计算机硬件和软件都会不可避免的发生故障,这些故障可能给企业造成无法挽回的损失.在网盘的运用中,如何保证网盘系统的高可用性就显得尤为重要.网盘系统的高可用性是指当任何一个节点坏掉时,

MySQL高可用方案选型参考

本文由「MySQL中文网」原创,"MySQL中文"公众号是 http://imysql.com 的官方唯一公众号,微信首发. 欢迎关注「MySQL中文」公众号(ID: imysql_wx),我们会不定期推送MySQL相关原创干货. 本次专题是 MySQL高可用方案选型,这个专题想必有很多同学感兴趣. 高可用的意义以及各种不同高可用等级相应的停机时间我就不必多说了,直接进入主题. 可选MySQL高可用方案 MySQL的各种高可用方案,大多是基于以下几种基础来部署的: 基于主从复制: 基于