Redis篇6-replication主从复制与哨兵模式

概述

  • 官方说明:https://redis.io/topics/replication
  • 作用:读(Slave)写(Master)分离,容灾恢复
  • 哨兵模式可以实现无人值守
  • 缺点:主从复制无疑会带来延迟(Master机器同步到Slave机器),使用哨兵模式则延迟会更明显。

测试配置准备(一台主机两台备机)

拷贝多个配置文件分别命名区分 redis{port}.conf

  • Master 端口6379
  • Slave1 端口6380
  • Slave2 端口6381
  • 其他方便区别配置
    • 使用后台方式启动服务 daemonize yes
    • pidfile redis{port}.pid
    • logfile redis{port}.log
    • dbfilename dump{port}.rdb

测试1 Master<Slave1, Slave2

  • 分别启动并连接上三个服务
    redis-server redis{port}.conf ps -ef|grep redis|grep -v grep redis-cli -p {port}
  • 客户端分别查看主从复制的信息 info replication
    # Replication role:master connected_slaves:0 master_replid:d3d1de9a393d82c4dc1787800471fffba1323b3a master_replid2:0000000000000000000000000000000000000000 master_repl_offset:0 second_repl_offset:-1 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0
  • 开始数据主从复制
    • Master

      set k1 v1
      set k2 v2
    • Slave1和Slave2
      get k1
      slaveof 127.0.0.1 6379
      get k1
      get k2
    • 可以看到Slave已经把Master的数据复制过来了
    • Master继续设置KV,验证Slave数据同步
    • 再次查看主从复制信息 info replication 可以看到匹配的信息
    • Slave上进行写操作则会报错
      (error) READONLY You can‘t write against a read only replica.
  • 将Master shutdown,Slave不动
    • Slave查看 info replication
    • 可以看到Slave数据依然在,且与Master的关系还在
    • 当Master重新启动,主从关系恢复如初
  • 将Slave1 shutdown,Master不动
    • Slave2的主从关系不会有变化
    • Slave1重新启动后,主从关系消失了,需要重新 slaveof 127.0.0.1 6379 进行数据同步
    • 如果希望Slave挂/断掉重启后“再续前缘”,需进行Slave-server的配置 replicaof 127.0.0.1 6379

测试2 Master<Slave1<Slave2(Slave1是Slave2的Master)

  • 上一个Slave可以是下一个Slave的Master,这样可以分担Master的写压力
  • Slave2改变Master:slaveof 127.0.0.1 6380
  • 查看Slave1的主从信息变化:info replication
  • 目前从整体上看,数据完整性和之前“一主二仆”模式是一样的,只是现在Slave2是从Slave1同步数据,变成“薪火相传”模式,那么Slave1怎么分担Master的压力?继续操作..
  • 将Master shutdown,模拟Master机器挂掉了,此时可以对Slave1 slaveof no one,让Slave1“反客为主”新的Master(role有Slave变成Master),这样就可以对其进行写操作,并和Slave2继续主从关系
  • 此时,原Master服务重启恢复,将成为单独的Master服务,被原Slave1、Slave2孤立在外。
  • 然后,将Slave1重新挂给Master,恢复最原始的“一主二仆”关系,会发现Slave1和Slave2在Slave1“反客为主”时期写的数据消失了,而变成了Master的数据。由此可知Slave变更Master后,Slave的数据会先清空,然后同步为新的Master的数据

哨兵(sentinel)模式

说明

  • 前面的测试中,当Master挂掉,还需要人为的将某个Slave转换为Master,而实际上机器挂掉可能发生在任意时刻,比如凌晨,所以不能依靠人为处理。
  • 哨兵模式弥补了上面的缺点,达到所谓“无人值守”的效果。
  • 效果1:使用哨兵模式,会另启动一个进程,对Master进行监控,如果监控到Master故障,则根据投票机制自动将某个Slave升级为新的Master(查看sentinel日志可以看到投票细节)。
  • 效果2:哨兵模式将Slave1升级为Master后,如果原Master恢复,哨兵监控到后,会自动把原Master降级挂给Slave1,主从关系完全变更。

配置与测试

  • 恢复“一主二仆”模式,一个Master(79),两个Slave(80、81)
  • 新建sentinel配置文件 vi sentinel.conf,内容:
    sentinel monitor master6379 127.0.0.1 6379 1
    说明:

    • sentinel monitor ... 指示sentinel监听后面机器上的Master
    • master6379 给后面要监听的Master取个名字
    • 127.0.0.1 6379 监听目标Master服务的ip和端口
    • 最后的数字m=1表示sentinel投票数,即当有n个sentinel(sentinel集群)认为这个Master挂了时,才会认为它真的挂了,然后进行故障迁移动作。这里是单机测试,所以n直接设置为1。
    • 可以新行,监听多个主机Master
  • 启动哨兵
    redis-sentinel sentinel.conf 或者 redis-server sentinel.conf --sentinel
    启动后可以看到日志:
    # Sentinel ID is 89568e210930ec9fe58e4cf856a5ef8e14501955 # +monitor master master6379 127.0.0.1 6379 quorum 1 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ master6379 127.0.0.1 6379 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ master6379 127.0.0.1 6379
  • 将Master shutdown,观察哨兵日志
    # +sdown master master6379 127.0.0.1 6379 # +odown master master6379 127.0.0.1 6379 #quorum 1/1 # +new-epoch 1 # +try-failover master master6379 127.0.0.1 6379 # +vote-for-leader 89568e210930ec9fe58e4cf856a5ef8e14501955 1 # +elected-leader master master6379 127.0.0.1 6379 # +failover-state-select-slave master master6379 127.0.0.1 6379 # +selected-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ master6379 127.0.0.1 6379 * +failover-state-send-slaveof-noone slave 127.0.0.1:6380 127.0.0.1 6380 @ master6379 127.0.0.1 6379 * +failover-state-wait-promotion slave 127.0.0.1:6380 127.0.0.1 6380 @ master6379 127.0.0.1 6379 # +promoted-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ master6379 127.0.0.1 6379 # +failover-state-reconf-slaves master master6379 127.0.0.1 6379 * +slave-reconf-sent slave 127.0.0.1:6381 127.0.0.1 6381 @ master6379 127.0.0.1 6379 * +slave-reconf-inprog slave 127.0.0.1:6381 127.0.0.1 6381 @ master6379 127.0.0.1 6379 * +slave-reconf-done slave 127.0.0.1:6381 127.0.0.1 6381 @ master6379 127.0.0.1 6379 # +failover-end master master6379 127.0.0.1 6379 # +switch-master master6379 127.0.0.1 6379 127.0.0.1 6380 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ master6379 127.0.0.1 6380 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ master6379 127.0.0.1 6380 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ master6379 127.0.0.1 6380
    可以看出,哨兵监控到79Master挂掉了,然后投票确定,然后重新选举80为新的Master。
  • 查看原Slave的主从信息,可以看出80Slave的role变成了Master
  • 重启79Master,查看哨兵日志和主从关系
    * +convert-to-slave slave 127.0.0.1:6379 127.0.0.1 6379 @ master6379 127.0.0.1 6380
    从日志也能看出,哨兵对79进行了convert-to-slave操作

原文地址:https://www.cnblogs.com/noodlerkun/p/11549842.html

时间: 2024-11-05 21:36:29

Redis篇6-replication主从复制与哨兵模式的相关文章

redis的主从复制和哨兵模式

Redis主从复制是什么? 行话:也就是我们所说的主从复制,主机数据更新后根据配置和策略, 自动同步到备机的master/slaver机制,Master以写为主,Slave以读为主 Redis主从复制能干些什么? (1)读写分离 (2)容灾恢复 Redis配置主从复制(1主2从) 知识注意: (1)配从(库)不配主(库) (2)从库配置:slaveof 主库IP 主库端口 (3)info replication查看当前redis节点信息(是主还是从等等) redis配置1主2从 开始配置: 这里

(六) Docker 部署 Redis 高可用集群 (sentinel 哨兵模式)

参考并感谢 官方文档 https://hub.docker.com/_/redis GitHub https://github.com/antirez/redis happyJared https://blog.csdn.net/qq_28804275/article/details/80938659 下载redis镜像(不带tag标签则表示下载latest版本) docker pull redis 从github 下载最新的redis.conf,注意重要参数 # 端口 port 6379 #

学习记录02 --- redis数据库的安装,以及主从复制和哨兵模式开启

emmmmmm,这个其实是28号老师布置下来的任务,但博客今天才开,思来想去还是把昨天的给补上吧,按住顺序来吧! 1.redis的安装 redis数据库的安装并不难,首先安装好依赖,因为redis是C语言编写,需要安装gcc来编译 yum install gcc-c++ -y(安装gcc) 执行上面的命令就安装完了gcc,接下来我们需要一个目录,用来安装redis 我是安装在/usr/local/redis里面的,所以直接执行下面的代码就可以创建一个目录 mkdir /usr/local/red

redis学习三,Redis主从复制和哨兵模式

Redis主从复制 java架构师项目实战,高并发集群分布式,大数据高可用,视频教程 1.Master可以拥有多个slave 2.多个slave可以连接同一个Master外,还可以连接到其他的slave 3.主从复制不会阻塞Master在主从复制时,Master可以处理client请求. 4.提供系统的伸缩性. 主从复制的过程 1.slave与Master建立连接,发送sync同步命令. 也就是说当用户在Master写入一条命令后,他们之间会通过一些算法把数据同步到每一个slave上. 2.Ms

Redis主从复制、哨兵模式

1.部署主从 环境:主IP:10.0.0.15,端口6379;从IP:10.0.0.16,端口6379. 原理:基于RDB持久化的功能来实现主从复制的功能. a.linux-redis1(10.0.0.15) cd /usr/local/redis/ grep "^[a-Z]" redis.conf # 列出几个修改过的配置 bind 10.0.0.15 protected-mode no port 6379 daemonize yes loglevel notice logfile

部署redis主从集群并开启哨兵模式

一.部署环境系统:centos7通过在Linux系统上启动两个不同的redis实例来完成主从集群的部署yum源已部署 二.redis的下载与安装1.下载:官网下载2.安装创建/app/目录,redis安装在/app/目录下 [[email protected] ~]# mkdir /app [[email protected] ~]# cd /usr/local/src/ [[email protected] src]# ls redis-4.0.11.tar.gz [[email protec

Redis集群redis主从自动切换Sentinel(哨兵模式)

Redis SentinelSentinel(哨兵)是用于监控redis集群中Master状态的工具,其已经被集成在redis2.4+的版本中 一.Sentinel作用:1):Master状态检测 2):如果Master异常,则会进行Master-Slave切换,将其中一个Slave作为Master,将之前的Master作为Slave3):Master-Slave切换后,master_redis.conf.slave_redis.conf和sentinel.conf的内容都会发生改变,即mast

Redis主从复制之哨兵模式(sentinel)

介绍:反客为主的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库 调整结构:6379带着80.81 自定义的/myredis目录下新建sentinel.conf文件,名字绝不能错 配置哨兵,填写内容,sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379 1 ,上面最后一个数字1,表示主机挂掉后salve投票看让谁接替成为主机,得票数多少后成为主机 启动哨兵 正常主从演示 主机master挂了 投票选取 选81为主机  问题:如果

[转]Redis哨兵模式(sentinel)学习总结及部署记录(主从复制、读写分离、主从切换)

Redis的集群方案大致有三种:1)redis cluster集群方案:2)master/slave主从方案:3)哨兵模式来进行主从替换以及故障恢复. 一.sentinel哨兵模式介绍Sentinel(哨兵)是用于监控redis集群中Master状态的工具,是Redis 的高可用性解决方案,sentinel哨兵模式已经被集成在redis2.4之后的版本中.sentinel是redis高可用的解决方案,sentinel系统可以监视一个或者多个redis master服务,以及这些master服务的