当前位置: 首页 > news >正文

Redis(七)复制

文章目录

    • 是什么
    • 功能
    • 配置
      • 配主库不配从库
      • 权限细节
    • 案例
      • 配置文件修改
    • 一主二仆
      • 固定配置文件
      • 主从问题
      • 命令操作手动指定
    • 薪火相传
    • 反客为主
    • 复制原理和工作流程
    • 存在问题

是什么

https://redis.io/docs/management/replication/

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

功能

  1. 读写分离
  2. 容灾恢复
  3. 数据备份
  4. 水平扩容支撑高并发

配置

配主库不配从库

权限细节

  1. master如果配置了requirepass参数,需要密码登陆
  2. 那么slave就要配置masterauth来设置校验密码,否则的话master会拒绝slave的访问请求

基本操作命令

# 可以查看复制节点的主从关系和配置信息
info replication
# 一般写入进redis.conf配置文件内
replicaof 主库IP 主库端口
# 每次与master断开之后,都需要重新连接,除非你配置进redis.conf文件在运行期间修改slave节点的信息
# 如果该数据库已经是某个主数据库的从数据库,那么会停止和原主数据库的同步关系转而和新的主数据库同步,重新拜码头
slaveof 主库IP 主库端口
# 使当前数据库停止与其他数据库的同步,转成主数据库,自立为王
slaveof no one

案例

配置文件修改

# 开启daemonize yes
# 注释掉bind 127.0.0.1 
# protected-mode no 
# 指定端口port 6379
# 指定当前工作目录,dir 
# pid文件名字,pidfile 
# log文件名字,logfile 
# 密码requirepass
# dump.rdb名字dbfilename
# aof文件,appendfilename 
# 从机访问主机的通行密码masterauth,必须 从机需要配置,主机不用

一主二仆

固定配置文件

# 配置文件执行
replicaof 主库IP 主库端口

在这里插入图片描述

  • 配从(库)不配主(库)
  • 先master后两台slave依次启动
  • 主从关系查看
  • info replication命令查看

主从问题

  1. 从机不可写入
    在这里插入图片描述
  2. 从机切入点
    首次一锅端,后续跟随,master写,slave跟
  3. 主机shutdown从机
    从机不动,原地待命,从机数据可以正常使用;等待主机重启动归来
  4. 主机shutdown,重启后主从关系依旧存在

命令操作手动指定

  • 预设的从机上执行命令 slaveof 主库IP 主库端口
  • 用命令使用的话,2台从机重启后,关系不再生效

配置持久有效
命令临时有效

薪火相传

上一个slave可以是下一个slave的master,slave同样可以接收其他slaves的连接和同步请求,那么该slave作为了链条中下一个的master可以有效减轻主master的写压力

中途变更转向:会清除之前的数据,重新建立拷贝最新的

slaveof 新主库IP 新主库端口

反客为主

SLAVEOF no one

使当前数据库停止与其他数据库的同步,转成主数据库

复制原理和工作流程

  1. slave启动,同步申请:slave启动成功连接到master后会发送一个sync命令,slave首次全新连接mater,一次完全同步(全量复制)将被自动执行,slave自身原有数据会被master数据覆盖
  2. 首次连接,全量复制:master节点收到sync命令后会开始在后台保存快照(即RDB持久化,主从复制时会触发RDB),同时收集所有接收到的用于修改数据集命令缓存起来,master节点执行RDB持久化完后同时收集所有接收到的用master将rdb快照文件和所有缓存的命令发送到所有slave,以完成一次完全同步
  3. 心跳持续保持通信:repl-ping-replica-perid 10日
  4. 进入平稳,增量复制:Master继续将新的所有集到的修改命令自动依次传给slave,完成同步
  5. 从机下线,重连续传:master会检查backlog里面的offset,master和slave都会保存一个复制的offset还有一个masterId,offset是保存在backlog,Master只会把已经复制的offset后面的数据复制给Slave,类似断点续传

存在问题

存在的问题:由于所有的写操作都是先在Master上操作,然后同步更新到Slave上,所以从Master同步到Slave机器有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,Slave机器数量的增加也会使这个问题更加严重。

挂了咋办

  1. 默认情况下,不会在slave节点中自动重选-个master
  2. 无人值守

相关文章:

  • 【数据库】聊聊explain如何优化sql以及索引最佳实践
  • 【七、centos要停止维护了,我选择Almalinux】
  • 网络协议基础
  • k8s 容器 java 应用内存限制不生效
  • 网络安全热门岗位大盘点
  • 微信小程序个人中心、我的界面(示例三)
  • 【每日一题】YACS P817:两数归零
  • 搭建k8s集群实战(三)安装配置containerd、kubelet、kubeadm、kubectl
  • 栈和队列的动态实现(C语言实现)
  • Web3:B站chainlink课程Lesson5遇到的小坑汇总
  • uniapp app更新
  • Node.js Cool 框架分页数据 如果在一个状态下获取多个状态的数据
  • 2024年预制菜行业市场发展趋势分析(2021-2023年预制菜行业数据分析)
  • 【C++】入门基础
  • 自动化防DDoS脚本
  • 免费激活Vmware16且配置虚拟机网络
  • 独立站怎么建设对seo好?
  • 如何自己制作一个属于自己的小程序?
  • 【MQ02】基础简单消息队列应用
  • 《WebKit 技术内幕》学习之十五(5):Web前端的未来
  • 马上评丨全民定制公交,打开城市出行想象空间
  • 巴基斯坦对印度发起网络攻击,致其约70%电网瘫痪
  • 墨西哥宣布就“墨西哥湾”更名一事起诉谷歌
  • 101条关于减重的知识,其中一定有你不知道的
  • 青年与人工智能共未来,上海创新创业青年50人论坛徐汇分论坛举办
  • 城管给商户培训英语、政银企合作纾困,上海街镇这样优化营商环境