代码编织梦想

Redis主从复制原理

主从复制是只将堕胎redis服务器 一般是一主二从三台 作为一个集群

一台是master 主节点 另外的节点称为slave/follower 称为从节点

集群内 主节点有读写功能,以写为主 从节点只有只读功能,不能写入数据

从节点的数据是从主节点复制过来的

主从复制的优点

  1. 实现了数据冗余,主备复制上的数据是一样的 实现了热备功能
  2. 故障恢复 当主节点故障时,备节点可以提供恢复数据的功能
  3. 负载均衡,主备机群配合读写分离,可以大大提高服务器并发量,分担访问量负载
  4. 实现了服务的高可用,主从复制+哨兵模式 实现了redis集群的高可用

生产环境下的redis

  1. 一般不会使用单台 redis是内存数据库 内存数据断电即失,
  2. 从访问响应速度上来说 不论一个服务器真实物理内存有多大,当单台redis的使用内存量超过20G的时候,已经不适合单机使用了。
  3. 不论关系型数据库还是非关系型数库 往往都是“少写多读”的环境,一次写入 会不断读取数据,建议使用集群环境实现读写分离。

Redis主从复制

环境搭建

只配置从库 不配置主库

127.0.0.1:6379> info replication #查询当前库的信息
# Replication
role:master #角色 master
connected_slaves:0  #没有从机
master_replid:78bc4f2d4fb4f0985b99db4b5ad45bf32d35513b
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
127.0.0.1:6379> 

一台虚拟机上搭建redis主从复制

开启4个会话窗口

image-20220420102200769

  1. 复制三份配置文件配置文件

image-20220420102611716

  1. 编辑redis6379.conf
port 6379
daemonize yes #后台启动打开
logfile "6379.log" #日志格式改一下 因为有多个服务
dbfilename dump6379.rdb #dump文件名字改成dump6379.rdb
  1. 编辑redis6380.conf
port 6380
daemonize yes
pidfile /var/run/redis_6380.pid #后台运行pid改完6380
logfile "6380.log"
dbfilename dump6380.rdb
  1. 编辑redis6381.conf
port 6381
daemonize yes
pidfile /var/run/redis_6381.pid
logfile "6381.log"
dbfilename dump6381.rdb
  1. 修改端口信息
  1. 修改后台启动
  1. 修改pid名称
  1. 修改log文件名称
  1. 修改rdb文件名称
  1. 启动6379端口的redis服务

image-20220420104205203

  1. 启动6380端口的redis服务

image-20220420104315254

  1. 启动6381端口的redis服务

image-20220420104341518

  1. 查询服务进程

3个端口都启动了

image-20220420104424409

配置主从关系

上面配置完默认都是三台主节点 我们要配置一主二从

  1. 会话1 端口6379 主节点

image-20220420104738892

  1. 会话2 6380端口 主节点

image-20220420104859259

  1. 会话3 6381端口 主节点

image-20220420104940072

默认三台都是master

一般情况下只用配置从机就可以

一主(6379)二从(6380/6381)

  1. 会话2 6380端口

image-20220420105408729

127.0.0.1:6380> SLAVEOF 127.0.0.1 6379 #配置主机的ip和端口
OK
127.0.0.1:6380> info replication
# Replication
role:slave # 再次查询自己变成从机了
master_host:127.0.0.1 #主机的ip
master_port:6379  #主机的端口
master_link_status:up
master_last_io_seconds_ago:2
master_sync_in_progress:0
slave_repl_offset:0
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:ac317b05cedf82644441b02ffe11b67755daf53f
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
  1. 会话1主机中去验证

image-20220420105604029

# Replication
role:master
connected_slaves:1 
slave0:ip=127.0.0.1,port=6380,state=online,offset=224,lag=0 #备机 ip端口 状态
master_replid:ac317b05cedf82644441b02ffe11b67755daf53f
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:224
  1. 会话3 6381上设置自己为从节点

image-20220420110117701

127.0.0.1:6381> SLAVEOF 127.0.0.1 6379  #设置主机为从节点  主节点的ip端口 127.0.0.1 6379
OK
127.0.0.1:6381> info replication
# Replication
role:slave #本机角色
master_host:127.0.0.1  #master ip
master_port:6379 #master port
master_link_status:up
master_last_io_seconds_ago:5
master_sync_in_progress:0
slave_repl_offset:616
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:ac317b05cedf82644441b02ffe11b67755daf53f
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:616
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
  1. 去会话1 主机上去验证

image-20220420110154743

使用命令配置 是暂时的 永久配置需要在配置文件中配置!!!

  1. 永久配置 在配置文件中写入主的ip端口即可

image-20220420110521932

# 6380、6381都配置从属到6379
replicaof 127.0.0.1 6379

主机可以写 从机只能读

主机的数据从机都会自动保存

image-20220420112637196

image-20220420112704617

image-20220420112725361

故障模拟

模拟主机down机后 从机可以用

image-20220420112925443

  1. 6379端口已经down机

image-20220420113002900

  1. 从机仍然可以获取信息

image-20220420113050907

  1. 主节点启动后写入

image-20220420113136724

  1. 从节点可以查看到新写入的信息

image-20220420113215988

总结

主节点down机后 从节点依旧连接主节点 整个主从没有了写入操作 主节点恢复后写入的数据 会同步到从节点

模拟故障2

  1. 模拟6381从机down掉

image-20220420113622956

image-20220420113610581

  1. 主节点写入值

image-20220420113703288

  1. 没有down掉的主机可以查到

image-20220420113738739

  1. down掉的从机查不到信息

image-20220420113817651

  1. 查询down掉从机的角色 启动服务后 变成了master 主节点

image-20220420113902158

  1. 再次设置down掉的机器为从机 查询刚才set的key3的值 可以查到
127.0.0.1:6381> get key3
(nil)
127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:0
master_replid:3eb0b967bc167f368df2ced66251dce8a4b73367
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
127.0.0.1:6381> SLAVEOF 127.0.0.1 6379  #再次设置为从机
OK
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:2
master_sync_in_progress:0
slave_repl_offset:827
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:4f660b5694c705fb64403b08984b92602de96317
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:827
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:814
repl_backlog_histlen:14
127.0.0.1:6381> get key3 #可以查询到down机前master写入的信息
"v3"
127.0.0.1:6381> 

*总结 *

命令行设置的主从 从机down机后重启后会变为主机 无法查询到集群主机写入的信息 重新设置为从机后可以查询到down机后主机写入的信息

以上集群架构图

image-20220420143958678

以上的架构是一主二从 当主节点挂掉之后 整个集群不具有写入功能,

另一种主从架构尝试

以上架构的问题是 当主节点挂掉后 整个集群只有读功能 不具备写入功能

我们也可以尝试配置成如下架构

image-20220420144230147

6379端口的服务仍然作为主节点

6380端口的服务 把自己设置为salve 同时把主节点设置为 6379

6381端口的服务 把自己设置为slave 同时把主节点设置为6380

这样6380端口的服务 既作为 6379端口服务的salve 又是6381端口服务的master

接上面的环境进行改造

6379端口服务

改造前 主节点 同时有两个slave节点

image-20220420144829202

6380端口服务这个不需要修改

目前是从节点 同时主节点是6379端口

image-20220420144954670

修改6381端口这台服务

6381这台的master修改为6380端口的服务

image-20220420145132250

再次查询6379端口master这台服务

salve变成了一个

image-20220420145235893

6380此时即使主节点也是从节点

我们查询的时候这台仍然是从节点

也就是目前是不能写入只能查询

image-20220420145550908

确认三台主机同步是否正常

6379端口写入

image-20220420145650800

6380端口查询

image-20220420145715760

6381端口查询

image-20220420145740632

同步没有问题

模拟故障3

6379端口服务故障关机

image-20220420145952095

6380仍然是从节点

image-20220420150018715

同时6381也是从节点 目前集群也是一种群龙无首的状态 哨兵模式之前 这个问题是无法解决的 只能通过手动配置6380端口服务为主节点

6380端口服务操作

127.0.0.1:6380> SLAVEOF no one #设置没有主节点
OK
127.0.0.1:6380> info replication #再次查询自己就变成了主节点
# Replication
role:master #主节点
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=8077,lag=1 #设置的从节点6381信息还在正常
master_replid:9de587961909c012366d01ef97578ef118226747
master_replid2:4f660b5694c705fb64403b08984b92602de96317
master_repl_offset:8091
second_repl_offset:8078
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:8091
127.0.0.1:6380> 

当6379端口服务重启服务再次回归的时候

已经不属于整个集群 是一个单独的master了

image-20220420150632064

以上问题 自动选举master,master挂掉重新回归的问题 可以通过哨兵模式实现。

哨兵模式

哨兵模式介绍

主从切换 是当主服务down机之后 需要干预把服务切换到另外一台作为备机上作为主服务器,人工切换存在时间差,一段时间内服务不可用 ,redis从2.8开始提供sentinel哨兵模式,。

哨兵模式启动后 哨兵会生成一个独立的进程,作为进程它会独立存在,

哨兵通过发送命令 等待redis响应回复 从而监控多个redist服务,一段时间内没有回复哨兵 则判断为故障,通过一定算法在集群内选举另外一台slave为主节点,当旧的主节点恢复服务加入集群后,会被设置为集群的slave节点。

哨兵工作原理

  1. Slave 启动成功连接到 master 后会发送一个sync同步命令

  2. Master 接到命令,启动后台的存盘进程,同时收集所有接收到的用于修改数据集命令,在后台进程执行 完毕之后,master将传送整个数据文件到slave,并完成一次完全同步。

全量复制:slave服务在接收到数据库文件数据后,将其存盘并全部加载到内存中。 相当于复制一份当前master状态的副本。

增量复制:Master 继续将新的所有收集到的修改命令依次传给slave,完成同步 只修改master修改的部分,其它部分不动。增删改查。

  1. 只要是slave重新连接master 一定会进行一次全量复制!!

哨兵模式主要作用

通过发送命令 返回并监控redis服务运行状态 包含master和slave的状态

当检测到主机master服务down掉 会自动选举一台slave为master 通过发布订阅的方式通知到其它slave主机,修改配置文件 让它们切换master主机

配置哨兵模式

环境恢复至 127.0.0.1 6379 主/6380/6381作为从节点

image-20220420152229479

与 redis.conf 同目录下 配置文件sentinel.conf

image-20220420152604951

sentinel monitor myredis 127.0.0.1 6379 1 #sentinel monitor 哨兵监控 myredis这个随便起名 后面是监控的主机 ip port  1表示这个主服务挂掉后 哨兵选举谁作为新的master

启动哨兵

image-20220420153156722

redis-sentinel peizhi/sentinel.conf 

启动后可以看到当前的master和slave

image-20220420153312306

模拟故障 主节点挂掉

image-20220420153459099

6380端口服务变成了主节点

image-20220420153544680

6381端口服务上验证 6380成为了主节点

image-20220420153640931

哨兵日志输出

主节点故障通过算法选举6380端口服务为主节点

image-20220420153924967

重新启动6379端口服务查询自己是独立的master

image-20220420154102932

追踪哨兵日志 发现哨兵自动把 127.0.0.1 6379设置为7380主节点的从节点

image-20220420154132945

再次查询6379端口服务的信息

发现变成了salve节点 同时master主机是6380端口服务 与哨兵日志输出的信息一致。

image-20220420154329246

哨兵模式配置文件解析

# Example sentinel.conf
# 哨兵sentinel实例运行的端口 默认26379
port 26379 #像redis.cong   如果有哨兵集群  需要配置多个端口
# 哨兵sentinel的工作目录
dir /tmp  #定义自己的工作目录 生成自己的文件
# 哨兵sentinel监控的redis主节点的 ip port
# master-name 可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。
# quorum 配置多少个sentinel 哨兵统一认为master主节点失联 那么这时客观上认为主节点失联了
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2
# 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供
密码
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000
# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步,
这个数字越小,完成failover所需的时间就越长,
但是如果这个数字越大,就意味着 越多的slave因为replication而不可用。
可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1
# 故障转移的超时时间 failover-timeout 可以用在以下这些方面:
#1. 同一个sentinel对同一个master两次failover之间的间隔时间。
#2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那
里同步数据时。
#3.当想要取消一个正在进行的failover所需要的时间。
#4.当进行failover时,配置所有slaves指向新的master所需的最大时间。不过,即使过了这个超时,
slaves依然会被正确配置为指向master,但是就不按parallel-syncs所配置的规则来了
# 默认三分钟
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000
# SCRIPTS EXECUTION
#配置当某一事件发生时所需要执行的脚本,可以通过脚本来通知管理员,例如当系统运行不正常时发邮件通知
相关人员。
#对于脚本的运行结果有以下规则:
#若脚本执行后返回1,那么该脚本稍后将会被再次执行,重复次数目前默认为10
#若脚本执行后返回2,或者比2更高的一个返回值,脚本将不会重复执行。
#如果脚本在执行过程中由于收到系统中断信号被终止了,则同返回值为1时的行为相同。
#一个脚本的最大执行时间为60s,如果超过这个时间,脚本将会被一个SIGKILL信号终止,之后重新执行。
#通知型脚本:当sentinel有任何警告级别的事件发生时(比如说redis实例的主观失效和客观失效等等),
将会去调用这个脚本,这时这个脚本应该通过邮件,SMS等方式去通知系统管理员关于系统不正常运行的信
息。调用该脚本时,将传给脚本两个参数,一个是事件的类型,一个是事件的描述。如果sentinel.conf配
置文件中配置了这个脚本路径,那么必须保证这个脚本存在于这个路径,并且是可执行的,否则sentinel无
法正常启动成功。
#通知脚本
# shell编程
# sentinel notification-script <master-name> <script-path>
sentinel notification-script mymaster /var/redis/notify.sh
# 客户端重新配置主节点参数脚本
# 当一个master由于failover而发生改变时,这个脚本将会被调用,通知相关的客户端关于master地址已
经发生改变的信息。
# 以下参数将会在调用脚本时传给脚本:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
# 目前<state>总是“failover”,
# <role>是“leader”或者“observer”中的一个。
# 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通
信的
# 这个脚本应该是通用的,能被多次调用,不是针对性的。
# sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh # 一般都是由运维来配
置!

多哨兵模式介绍

一个哨兵对redis监控可能会出现问题,可以使用多哨兵模式进行监控,各个哨兵之间会进行监控 这样就形成了多哨兵模式

image-20220420205315943

哨兵模式优缺点

优点

主从复制的优点他都有

自动切换master 实现集群高可用,实现故障转移

缺点

Redis集群不容易在线扩容

哨兵模式的配置项很多,哨兵模式配置比较麻烦。

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/m0_60700102/article/details/124324950

利用redis主从复制+哨兵模式搭建高可用集群_qi_ming88的博客-爱代码爱编程_redis主从搭建哨兵

由于资源的问题,本次测试只是在一个CentOS虚拟机,搭建多个端口的redis集群,以及一个哨兵。 1.创建三个redis服务,复制copy redis.conf成多个 2。在redis安装目录(/usr/local/bin)启动redis服务 redis-server /myredis/redis6379.conf redis-cli -p

redis主从复制与哨兵模式_岸远水声微的博客-爱代码爱编程

本文基于redis-5.0.3版本,环境为Mac OS,单机器上部署。 Redis单机存在的问题 单机故障容量瓶颈QPS瓶颈 Redis主从复制 主机数据更新后根据配置和策略,自动同步到备机的master/slave

redis主从复制+哨兵_南山浪子的博客-爱代码爱编程

sentinel是为了解决主从模式下,如果主节点由于故障下线了,自动升级从节点为主节点。 每个sentinel节点其实就是一个redis实例,与主从节点不同的是sentinel节点作用是用于监控redis数据节点的,而sentinel节点集合则表示监控一组主从redis实例多个sentinel监控节点的集合,比如有主节点master和从节点slave-1、

docker-compose配置redis主从复制,哨兵模式-爱代码爱编程

1.首先是docker-compose.yml文件 配置好3个容器 version: "3" services: redis-1: image: redis #目标镜像 restart: always #是否跟随

redis集群之主从复制+哨兵模式+cluster群集(理论+实战,收获满满!!!)-爱代码爱编程

文章目录 一、redis集群类型二、主从复制2.1、主从复制概念2.2、工作原理2.3、主从复制启用2.4、主从复制优缺点2.4.1、优点2.4.2、缺点三、哨兵模式3.1、基本概念3.2、哨兵模式的优缺点3.2.1、优点3.2.2、缺点四、Redis-Cluster集群4.1、cluster集群概述4.2、优缺点五、redis-cluster集群

redis集群之主从复制+哨兵模式-爱代码爱编程

文章目录 一、redis集群之主从复制1.1、集群介绍1.2、搭建过程1.3、验证二、redis集群之哨兵模式2.1、部署过程1、搭建主从复制集群2、设置哨兵模式的配置文件3、启动哨兵服务2.2、故障模拟 redis集群的理论知识请参考我之前的博客,链接为:redis集群之主从复制+哨兵模式+cluster群集(理论+实战,收获满满!!!) 一

Redis的主从架构+哨兵模式-爱代码爱编程

1、新建文件夹,位置:/opt/redis09033/,所有文件及操作均在此文件夹下 2、创建docker-compose.yml文件 version: "3.1" services: redis1: image: 10.0.134.175:5000/redis:5.0.9 #镜像位置 restart: always co

centos7 Redis主从复制+哨兵模式)redis集群部署搭建-爱代码爱编程

今天下午有搭建了公司测试环境的redis集群模式,主从复制+哨兵模式,现详细记录下搭建过程以及遇到的问题,有兴趣的可以参看本人写的mysql主从复制,nginx集群高可用等等相关部署搭建。 172.16.21.238 6379主机(master) 172.16.21.151 6380从机(slave) 一:redis安装 这里我采用的是压缩包安装,

Redis主从复制和哨兵模式介绍-爱代码爱编程

文章目录 1.Redis主从复制1.1 概述1.2 redis结构分类1.2.1 redis全量同步1.2.2 redis增量复制1.3 主从同步策略2.搭建Redis主从复制2.1 在服务器上开启redis_server服务2.1.1 解压并安装2.1.2 创建链接文件,并启动服务2.2 修改配置文件2.2 master主服务器上验证从节点2.3

Redis主从模式+哨兵模式-爱代码爱编程

目录 1、Redis主从模式概述1.1、同步方式2、哨兵模式3、Redis一主两从模式案例3.1、同步会话模式,关闭防护墙,放入安装包3.2、取消会话模式,进入主模式配置文件,进行修改3.3、进入Slave1节点配置文件进行修改3.4、进入Slave2节点配置文件进行修改3.5、重启所有主机redis服务3.6、进入Master查看日志,验证主从效

Redis主从复制和哨兵模式-爱代码爱编程

Redis主从复制一主二从配置使用规则哨兵模式 Redis主从复制 1、概念 主从复制,是指将一台Redis服务器的数据,复制到其他的Redis服务器。前者称为主节点(Master/Leader),后者称为从节点(Slave/Follower), 数据的复制是单向的!只能由主节点复制到从节点(主节点以写为主、从节点以读为主)。 默认情

Redis主从复制之哨兵模式-爱代码爱编程

哨兵模式 概述 主从切换技术的方法是:当主服务器宕机后,需要手动把一台从服务器切换为主服务器,这就需要人工干预,费事费力,还会造成一段时间内服务不可用。这不是一种推荐的方式,更多时候,我们优先考虑哨兵模式。Redis从2.8开始正式提供了 Sentinel(哨兵)架构来解决这个问题。 自动选择一个新主机,能够后台监控主机是否故障,如果故障了根据投票数

redis主从复制,哨兵模式-爱代码爱编程

redis集群环境搭建 主从复制概念 主从复制是指,将一台redis服务器的数据复制到其他redis服务器。主节点(master)以写为主,从节点(slave)以读为主。 数据复制时单向的,只能从主节点到从节点。 主从复制的主要作用 数据冗余 故障恢复 负载均衡 高可用(集群)基石:主从复制是哨兵和集群能实施的基础 集群搭建 redis使用中,