Redis复制(replica)

一 定义

就是主从复制,master以写为主,Slave以读为主。当master数据变化的时候,自动将新的数据异步同步到其它slave数据库。

二 作用

  • 读写分离
  • 容灾备份
  • 数据备份
  • 水平扩容支撑高并发

三 实践

3.1 配置

配从(库)不配主(库)

3.2 权限细节

  • master如果配置了requirepass参数,需要密码登录。
  • 那么slave就要配置masterauth来设置校验密码,否则的话master会拒绝slave的访问请求。
535 # masterauth <master-password>
536 masterauth 111111

3.3 基本操作命令

3.3.1 info replication

可以查看复制节点的主从关系和配置信息

3.3.2 replicaof 主库IP 主库端口

一般写入仅redis.conf配置文件内

3.3.3 slaveof 主库IP 主库端口

每次与master断开之后,都需要重新连接,除非你配置进redis.conf文件。
在运行期间修改slave节点的信息,如果该数据库已经是某个主数据库的从数据库,那么会停止和原主数据库的同步关系转而和新的主数据库同步,重新拜码头

3.3.4 slaveof no one

使当前数据库停止与其他数据库同步,转成主数据库,自立为王

3.4 配置文件修改

  1. 开启daemobize yes在这里插入图片描述

  2. 注释掉bind 127.0.0.1在这里插入图片描述

  3. protected-mode no在这里插入图片描述

  4. 指定端口在这里插入图片描述

  5. 指定当前工作目录,dir在这里插入图片描述

  6. pid文件名字,pidfile在这里插入图片描述

  7. log文件名字,logfile在这里插入图片描述

  8. requirepass在这里插入图片描述

  9. dump.rdb名字在这里插入图片描述

  10. aof文件,appendfilename在这里插入图片描述

  11. 从机访问主机的通行密码masterauth,必须 在这里插入图片描述

3.5 具体操作(一主二仆)

3.5.1 查看主从信息

info replication

3.5.2 细节及问题

  1. 从机可以执行写命令吗?在这里插入图片描述

  2. 从机切入点问题:
    slave是从头开始复制还是从切入点开始复制?
    master启动,写到k3。slave1跟着master同时启动,跟着写到k3,slave2写到k3后才启动,那之前的是否也可以复制?
    Y,首次一锅端,后续跟随,master写,slave跟。

  3. 主机shutdown后,从机会上位吗?
    从机不动,原地待命,从机数据可以正常使用,等待主机重启动归来。

  4. 主机shutdown后,重启后主从关系还在吗?从机还能否顺利复制?
    主从关系还在,从机可以顺利复制。

  5. 某台从机down后,master继续运行,从机重启后它能跟上大部队吗?
    可以。

3.6 薪火相传

  • 上一个slave可以是下一个slave的master,slave同样可以接收其他slave的连接和同步请求,那么该slave作为了链条中下一个的master,可以有效减轻主master的写压力。
  • 中途变更转向:会清除之前的数据,重新建立拷贝最新的。
  • slaveof 新主库IP 新主库端口

3.7 反客为主

SLAVEOF no one:使当前数据库停止与其他数据库同步,转成主数据库,自立为王

四 复制原理和工作流程

4.1 slave启动,同步初请

  • slave启动成功连接到master后会发送一个sync命令。
  • slave首次全新连接master,一次完全同步(全量复制)将会被自动执行。slave自身原有数据会被master数据覆盖清除。

4.2 首次连接,全量复制

  • master节点收到sync命令后会开始在后台保存快照(即RDB持久化,主从复制时会触发RDB),同时收集所有接收到的用于修改数据集命令缓存起来,master节点执行RDB持久化完后,master将rdb快照文件和所有缓存的命令发送到所有slave,以完成一次完全同步。
  • 而slave服务在接收到数据库文件数据后,将其存盘并加载到内存中,从而完成复制初始化。

4.3 心跳持续,保持通信

# master 发出ping包的周期,默认是10秒
repl-ping-replica-period 10 

4.4 进入平稳,增量复制

Master继续将新的所有收集到的修改命令自动依次传给slave,完成同步。

4.5 从机下线,重连续传

master会检查backlog里面的offset,master和slave都会保存一个复制的offset还有一个masterId,offset是保存在backlog中的。Master只会把已经复制的offset后面的数据复制给Slave,类似断点续传。

五 复制的缺点

  • 复制延时,信号衰减:由于所有的写操作都是先在Master上操作,然后同步更新到Slave上,所以从Master同步到Slave机器有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,Slave机器数量的增加也会使这个问题更加严重。
    在这里插入图片描述

  • master挂了如何办?

    • 默认情况下,不会在slave节点中自动重选一个master。
    • 那每次都要人工干预?(无人值守安装变成更需
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值