Redis 自动故障转移sentinel

最近看了Redis自动故障转移Sentinel(哨兵),故将笔记记在次处
注意,实际环境中是,多台机器,本文只是测试,所以在一台机器上配置多个Redis实例,以达到实验的目的

Redis Sentinel(哨兵)

7000配置文件

port 7000 
daemonize yes 
pidfile /var/run/redis-7000.pid 
logfile "7000.log" 
dbfilename "dump-7000.rdb" 
appendonly yes 
appendfilename "appendonly-7000.aof" 
dir "/data/redis"
 
配置文件编写

sed 's/7000/7001/g' redis-7000.conf >>redis-7001.conf
sed 's/7000/7002/g' redis-7000.conf >>redis-7002.conf
cat redis-7001.conf
cat redis-7002.conf
cat redis-7000.conf
 
设置主从关系

echo "slaveof 192.168.1.108 7000" >>redis-7001.conf
echo "slaveof 192.168.1.108 7000" >>redis-7002.conf
 
启动三台redis server

redis-server /etc/redis/redis-7000.conf
redis-server /etc/redis/redis-7002.conf
redis-server /etc/redis/redis-7001.conf
ps -ef | grep redis
 
查看redis 7000端口的复制信息

PHP

127.0.0.1:7000> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.1.108,port=7001,state=online,offset=43,lag=1
slave1:ip=192.168.1.108,port=7002,state=online,offset=43,lag=1
master_repl_offset:43
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:42
 
配置sentinel

vim redis-sentinel-26379.conf

port 26379 
daemonize yes 
pidfile /var/run/redis-26379.pid
logfile "26379.log"
dir /data/redis
sentinel monitor mymaster 192.168.1.108 7000 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
 
生成配置文件

sed 's/26379/26380/g' redis-sentinel-26379.conf >> redis-sentinel-26380.conf
sed 's/26379/26381/g' redis-sentinel-26379.conf >> redis-sentinel-26381.conf
 
启动哨兵

PHP

[root@CentOS redis]# redis-sentinel redis-sentinel-26379.conf
[root@CentOS redis]# redis-sentinel redis-sentinel-26380.conf
[root@CentOS redis]# redis-sentinel redis-sentinel-26381.conf
 
[root@CentOS redis]# ps -ef | grep redis-sentinel| grep -v 'grep'
root      2677     1  0 02:36 ?        00:00:00 redis-sentinel *:26379 [sentinel]
root      2681     1  0 02:36 ?        00:00:00 redis-sentinel *:26380 [sentinel]
root      2685     1  0 02:36 ?        00:00:00 redis-sentinel *:26381 [sentinel]
 
接下来可以测试哨兵的功能了,代码太多就不粘贴上来了,至此Redis自动故障转移简单模型已经完成

时间: 2024-09-26 20:36:49

Redis 自动故障转移sentinel的相关文章

Redis 自动故障转移 集群 解决方案

问题描述 实在无奈,研究不出可行的方案,所以来求助大家.问题:两台服务器,部署redis,一主一从,(主为a1,从为a2)客户端访问redis服务器,如果a1服务器意外关闭,则客户端直接访问a2服务器上的redis,这个需要怎么配置?或者需要什么解决方案.(windows服务器上的) 解决方案 解决方案二:不就是a1连不上,连a2的节奏吗?解决方案三:客户端要连哪个服务器,应该由你的程序来控制,而不是依靠什么"配置"吧?解决方案四:引用2楼rocmemory的回复: 客户端要连哪个服务

MySQL 自动故障转移工具--mysqlfailover

mysqlfailover 是mysql utilities工具包中包含的一个重要的高可用命令,用于对主从复制架构进行健康检测以及实现故障自动转移.它会定期按指定的时间间隔探测各节点的健康状态,一旦在捕获到主节点不可用时,将触发故障转移相关动作,自动执行故障切换到当前最佳的从服务器上.同时整个主从架构内的其他从节点将指向新的主节点,自动完成主从拓扑结构更新. 相关知识点热身 基于mysqldump搭建gtid主从 MySQL GTID 错误处理汇总 配置MySQL GTID 主从复制 使用mys

MHA 自动故障转移步骤及过程剖析

    MHA是众多使用MySQL数据库企业高可用的不二选择,它简单易用,功能强大,实现了基于MySQL replication架构的自动主从故障转移,本文主要描述了MHA自动切换的步骤,对切换过程做了演示以及进行了适当的分析,供大家参考和理解MHA以及MySQL的原理.   1.MHA自动切换的步骤a.MHA manager启动时的校验阶段   根据配置文件校验复制配置以及识别当前的master   导致监控终止情形:复制配置异常,存在的异常slave,一些需要的脚本脚本异常   MHA ma

如何配置vSphere HA实现自动故障转移?

部署VMware vSphere的一个原因在于利用高可用性HA功能.   使用vSphere HA,可让虚拟服务器停止,系统自动将其切换到新服务器上的第二个相同的虚拟机上,并且不会丢失心跳. 首先,配置VMware集群节点,并在通用标准下运行起来.你需要对所有节点后执行相同的更新,该案例中是两台服务器,并拥有一个共享的存储空间,你的第三台存储服务器提供给节点使用.所有虚拟机及其配置文件必须驻留并能访问共享存储.如果不能,当一个节点坏掉,另一个新节点起来,新节点上的数据将不会更新. 创建集群后,使

数据库镜像调整自动故障转移时间

问题 数据库镜像变成SQL Server 2005中很受欢迎的一个功能.通过下面几个简单步骤,使用SQL Server 管理套件或者运行一些T-SQL命令,你可以很容易在你的一个或多个数据库中创建数据库镜像.数据库镜像的某一个配置选项是高可用性模式.有了这个选项,主体服务器.镜像服务器.见证服务器三个服务器被放在适当的位置.这是允许自动故障解决故障转移功能的唯一选项.我注意到的一点是当存在定期网络问题时,即使主体服务器没有问题,一个故障转移也会发生.有没有一些选项可以延迟这个故障转移呢?因为我在

AlwaysOn可用性组功能测试(1)-故障转移测试

一. AlwaysOn可用性组故障转移测试 1. 自动故障转移 1.1 将故障转移模式改成自动,如果实例为SQL Server故障转移实例则配置无效. 1.2 在SERVER03自动转移,CLUSTEST03\CLUSTEST03手动转移的情况下,kill SERVER03的SQL Server服务.如下界面 1.3 无法发送自动故障转移,整个可用性主失败,如下所示 2. 计划手动故障转移 2.1 计划手动故障转移,需要将可用性模式改成同步提交,待所有副本都同步后,开始手动转移 2.2 进入故障

MHA 手动故障转移

        MHA提供了3种方式用于实现故障转移,分别自动故障转移,需要启用MHA监控:在无监控的情况下的手动故障转移以及基于在线手动切换.三种方式可以应对MySQL主从故障的任意场景.本文主要描述在无监控的情形是手动实现故障转移.供大家参考.       有关MHA的其他两种切换方式,可以参考:            MHA 在线切换过程            MHA 自动故障转移步骤及过程剖析   1.手动故障转移的特点    a.在监控节点未启用masterha_manager   

MySQL下高可用故障转移方案MHA的超级部署教程_Mysql

MHA介绍MHA是一位日本MySQL大牛用Perl写的一套MySQL故障切换方案,来保证数据库系统的高可用.在宕机的时间内(通常10-30秒内),完成故障切换,部署MHA,可避免主从一致性问题,节约购买新服务器的费用,不影响服务器性能,易安装,不改变现有部署.      还支持在线切换,从当前运行master切换到一个新的master上面,只需要很短的时间(0.5-2秒内),此时仅仅阻塞写操作,并不影响读操作,便于主机硬件维护.   在有高可用,数据一致性要求的系统上,MHA 提供了有用的功能,

Windows服务器故障转移集群的仲裁

Windows服务器故障转移集群(Windows Server Failover Cluster,简称WSFC)使用仲裁投票(Quorum Voting)决定集群的健康状况,或使故障自动转移,或使集群离线.当集群中的结点发生故障时,会由其他结点接手继续提供服务,不过,当结点之间通信出现问题,或大多数结点发生故障时,集群就会停止服务,可是集群可以容忍多少个结点发生故障呢?这要由仲裁配置(Quorum Configuration)决定,仲裁配置使用多数(Majority)原则,只要集群中健康运行的结