redis主从架构宕机问题手动解决

1    主机宕机

1、  设置端口6379是主机,端口6380是从机,全部都正常启动

2、  验证在6379写入数据,在6380也能得到数据

3、  现在将6379主机停掉,模拟主机宕机

4、  由于主机宕机了,现在就要将6380从机设置为主机,使用slaveof no one命令,此时原来的从机变为

主机也用了写的权限

5、  要是原来6379经过修复后,能够正常工作,先将6380主机数据进行保存持久化,将rdb文件,覆盖原主机6379的rdb文件,进行数据的统一。

6、  启动原来的主机6379

7、  将6380再次设置为从机

8、  先验证主机和从机数据是否一致

主机:

从机:

9、  在主机设置值,看能否同步到从机。

主机设置数据

从机得到数据

10、 测试从机是否还有写权限

作为从机之后,不再具有写权限了。

1.2    从机宕机

这个相对而言比较简单,在Redis中从库重新启动后会自动加入到主从架构中,自动完成同步数据;

原文地址:https://www.cnblogs.com/xiao-xue-di/p/11102315.html

时间: 2024-09-30 15:58:27

redis主从架构宕机问题手动解决的相关文章

10.Redis 主从架构

作者:中华石杉 Redis 主从架构 单机的 redis,能够承载的 QPS 大概就在上万到几万不等.对于缓存来说,一般都是用来支撑读高并发的.因此架构做成主从(master-slave)架构,一主多从,主负责写,并且将数据复制到其它的 slave 节点,从节点负责读.所有的读请求全部走从节点.这样也可以很轻松实现水平扩容,支撑读高并发. redis replication -> 主从架构 -> 读写分离 -> 水平扩容支撑读高并发 redis replication 的核心机制 red

Redis主从架构

Redis 主从架构 一.简单介绍 单机的 redis,能够承载的 QPS 大概就在上万到几万不等.对于缓存来说,一般都是用来支撑读高并发的.因此架构做成主从(master-slave)架构,一主多从,主负责写,并且将数据复制到其它的 slave 节点,从节点负责读.所有的读请求全部走从节点.这样也可以很轻松实现水平扩容,支撑读高并发. redis replication -> 主从架构 -> 读写分离 -> 水平扩容支撑读高并发 二.redis replication 的核心机制 re

Keepalived+nginx+redis主从+tomcat一机多实例实现会话共享

Keepalived+nginx+redis主从+tomcat一机多实例实现会话共享 2014-09-09 14:14:25 标签:会话共享 主从 原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 .作者信息和本声明.否则将追究法律责任.http://lovelace.blog.51cto.com/1028430/1550198 ### keepalived配置 ### nginx安装培训 - 安装nginx 1 2 3 ``` cpp yum install nginx -y `

Redis(六)——高可用之哨兵sentinel配置与启动及主从服务宕机与恢复

.主从复制高可用 #主从复制存在的问题: 1 主从复制,主节点发生故障,需要做故障转移,可以手动转移:让其中一个slave变成master 2 主从复制,只能主写数据,所以写能力和存储能力有限 哨兵是对Redis的系统的运行情况的监控,它是一个独立进程,它会独立运行,功能有二个: 通过发送命令,让Redis服务器返回监控其运行状态,包括主服务器和从服务器. 当哨兵监测到master宕机,会自动将slave切换成master,然后通过发布订阅模式通知其他的从服务器,修改配置文件,让它们切换主机.

linux 双Redis + keepalived 主从复制+宕机自主切换

主要核心思想,如果master 和 salve 全部存活的情况,VIP就漂移到 master.读写都从master操作,如果master宕机,VIP就会漂移到salve,并将之前的salve切换为master,当宕机的master可以继续服务的时候,首先会从salve同步数据,然后VIP漂移到master服务器上面,持续提供服务. 环境准备: master:ip 192.168.28.139:redis 19020:redis 19021:keepalived slave :ip 192.168

mysql主从同步宕机切换问题

1)mysql各版本一直在优化主从同步 2)5.7是loss less,但不是zero loss,切换的时候还是会丢数据 3)5.7真正做到了并发复制降低主从延时,5.6没有(基于schema级别做到了) 4)pg有全同步复制方式,mysql原生版本没有(只是半同步).galera,phxsql,alisql都解决了切换丢数据和主从延时问题. 5)即使是主从延时在特殊业务(金融)下发生切换的时候也不能接受(如钱相关的业务),这种场景必须全同步方式例如用galera,phxsql,alisql.对

REDIS 主从架构key过期时间失效问题

活动中用到了Redis来存放用户的奖励票信息,原则上是一天一清,现在设置的是expireAt(零点)但是最近运营反馈有部分用户有异常票,经过加log排查后发现指定在零点过期的key并没有准时过期,从库中在0点23秒的时候还能读到数据,程序中用了简单的exists(key) 判断key是否存在,存在就取值.这么想可能是主库在零点过期了,但是没有及时同步到从库.在网上一看,有用户遇到同样的情况,Redis版本3.2之前的会存在这种情况,然后查看了一下我们的redis版本,发现是3.0 这也就难怪了,

nginx+redis主从+tomcat一机多实例实现会话共享

1.安装nginx 2.用两个虚拟机安装两个reids(reids1.redis2) 其中一个配置slaveof 192.168.1.86 6379(另一个redis的IP与端口) 3.安装两个tomcat 修改tomcat的context.xml: <Context>                <!-- Default set of monitored resources -->          <WatchedResource>WEB-INF/web.xml&

Mysql主从架构-主库宕机如何恢复业务

在我们日常工作场景,首先要做到架构无单点隐患,其次在优化[安全.性能.高可用.高并发等],Mysql这款关系型数据库稳定.高效,所以使用广泛,如果企业架构是1主多从,那如果Mysql主库宕机,如何解决? ----MySQL 主从同步原理图 一.Mysql主库宕机情况分类: 1)硬件问题,(服务器.ecs.虚拟主机等等)宕机 2)service问题,Mysql宕机,服务异常,端口异常等 二.硬件问题处理思路 硬件问题我们可以查看IDC巡检记录,或通过远程控制卡查看硬件运行状态,根据事实情况就行硬件