Redis主从复制、读写分离

一.Redis的主从复制是什么

主机数据更新后根据配置和策略,自行同步到备机的master/slave机制,Master以写为主,Slave以读为主。

二.Redis的主从复制能干什么

  读写分离

  容灾备份

三.怎么用

1.配从不配主

2.从库配置:slaveof 主库ip 主库端口(如果当前服务器已经是某台主服务器的从属服务器,那么执行SLAVEOF host port 将使当前服务器停止对旧主服务器的同步,并清除旧的数据集,转而向新的主服务器进行同步

  每次从库和主库断开之后,都需要重新连接,除非配置进Redis.conf文件

  使用info replication指令可以查看当前Redis实例的情况(包括是主库还是从库,如果是主库,有几个从库,从库监听的端口号.......)

3.常见的应用情况:
  3.1当master关闭之后,那么这个master的所有slave将原地待命,当master重新启动之后,那么这些slave将自动连接上这个master

  3.2当master的某个从库slave挂掉之后,并不影响主库master和其余从库slave的使用,但是当挂掉的这台重新启动之后,将不再是这台master的从库,而是恢复master身份。

  3.3上一个slave可以是下一个slave的Master,slave同样可以接受其他slaves的连接和同步请求,那么该slave作为链条中下一个slave的master,可以有效减轻master的压力,但是这样就会出现延迟性,不能保证数据的一致性。

  3.4当主服务挂掉之后,此时为了正常使用,在从库中抉择出一个服务器作为主服务器,首先执行SLAVEOF no one使得这个从属服务器关闭复制功能,并恢复自己主服务器的身份(原来同步所得数据集不会被丢弃),然后将另一台从属服务器和它建立主从关系。

四.replication的原理:

  •   全量复制:用于第一次复制或者其他无法进行部分复制的情况,将主库所有数据都发送给从库,这是一个非常重型的操作。
  •   增量复制:用于网络中断后的等情况的复制,只将主库在中断期间执行的写操作发送给从库,比全量复制更加高效。需要注意的是,如果中断的时间过长,导致主库没有完全保存中断期间执行的写操作(见下面的关于复制积压缓冲区的解释),则无法执行部分复制,只能进行全量复制。

  4.1全量复制

   (1)从节点判断无法进行部分复制,向主节点发送全量复制的请求;或从节点发送部分复制的请求,但主节点判断无法进行部分复制,于是进行全量复制;

   (2)主节点收到全量复制的命令后,执行bgsave(BGSAVE 命令用于在后台异步将内存数据库中的数据保存进磁盘中,BGSAVE 命令执行之后立即返回 OK ,然后 Redis fork 出一个新子进程,父进程继续处理客户端请求,而子进程则负责将数据保存到磁盘,然后退出),在后台生成RDB文件,并使用一个缓冲区(称为复制缓冲区)记录从现在开始执行的所有写命令

   (3)主节点的bgsave执行完成后,将RDB文件发送给从节点;从节点首先清除自己的旧数据,然后载入接收的RDB文件,将数据库状态更新至主节点执行bgsave时的数据库状态。

   (4)主节点将前述复制缓冲区中的所有写命令发送给从节点,从节点执行这些写命令,将数据库状态更新至主节点的最新状态

    (5)如果从节点开启了AOF,则会触发bgrewriteaof的执行,从而保证AOF文件更新至主节点的最新状态。

  4.2增量复制

由于全量复制在主节点数据量较大时效率太低,因此Redis2.8开始提供部分复制,用于处理网络中断时的数据同步。

部分复制的实现,依赖于三个重要的概念:

(1)复制偏移量

主节点和从节点分别维护一个复制偏移量(offset),代表的是主节点向从节点传递的字节数;主节点每次向从节点传播N个字节数据时,主节点的offset增加N;从节点每次收到主节点传来的N个字节数据时,从节点的offset增加N。

offset用于判断主从节点的数据库状态是否一致:如果二者offset相同,则一致;如果offset不同,则不一致,此时可以根据两个offset找出从节点缺少的那部分数据。例如,如果主节点的offset是1000,而从节点的offset是500,那么部分复制就需要将offset为501-1000的数据传递给从节点。而offset为501-1000的数据存储的位置,就是下面要介绍的复制积压缓冲区。

(2)复制积压缓冲区

复制积压缓冲区是由主节点维护的、固定长度的、先进先出(FIFO)队列,默认大小1MB;当主节点开始有从节点时创建,其作用是备份主节点最近发送给从节点的数据。注意,无论主节点有一个还是多个从节点,都只需要一个复制积压缓冲区。

在命令传播阶段,主节点除了将写命令发送给从节点,还会发送一份给复制积压缓冲区,作为写命令的备份;除了存储写命令,复制积压缓冲区中还存储了其中的每个字节对应的复制偏移量(offset)。由于复制积压缓冲区定长且是先进先出,所以它保存的是主节点最近执行的写命令;时间较早的写命令会被挤出缓冲区。

由于该缓冲区长度固定且有限,因此可以备份的写命令也有限,当主从节点offset的差距过大超过缓冲区长度时,将无法执行部分复制,只能执行全量复制。反过来说,为了提高网络中断时部分复制执行的概率,可以根据需要增大复制积压缓冲区的大小(通过配置repl-backlog-size);例如如果网络中断的平均时间是60s,而主节点平均每秒产生的写命令(特定协议格式)所占的字节数为100KB,则复制积压缓冲区的平均需求为6MB,保险起见,可以设置为12MB,来保证绝大多数断线情况都可以使用部分复制。

从节点将offset发送给主节点后,主节点根据offset和缓冲区大小决定能否执行部分复制:

  • 如果offset偏移量之后的数据,仍然都在复制积压缓冲区里,则执行部分复制;
  • 如果offset偏移量之后的数据已不在复制积压缓冲区中(数据已被挤出),则执行全量复制。

(3)服务器运行ID(runid)

每个Redis节点(无论主从),在启动时都会自动生成一个随机ID(每次启动都不一样),由40个随机的十六进制字符组成;runid用来唯一识别一个Redis节点。通过info Server命令,可以查看节点的runid:

主从节点初次复制时,主节点将自己的runid发送给从节点,从节点将这个runid保存起来;当断线重连时,从节点会将这个runid发送给主节点;主节点根据runid判断能否进行部分复制:

  • 如果从节点保存的runid与主节点现在的runid相同,说明主从节点之前同步过,主节点会继续尝试使用部分复制(到底能不能部分复制还要看offset和复制积压缓冲区的情况);
  • 如果从节点保存的runid与主节点现在的runid不同,说明从节点在断线前同步的Redis节点并不是当前的主节点,只能进行全量复制。

具体的细节请看下面这篇博文:https://www.cnblogs.com/kismetv/p/9236731.html(大佬就是大佬,整理的是真的详细)

原文地址:https://www.cnblogs.com/wsxdev/p/11686250.html

时间: 2024-10-16 01:09:56

Redis主从复制、读写分离的相关文章

Mysql的主从复制读写分离--简单篇

Mysql基础拓扑图: Mysql环境准备: 一台mysql主服务器(安装mysql) 两台mysql从服务器(安装mysql) 一台mysql代理(安装amoeba和java) 一台mysql客户端(mysql客户端) 部署前先关闭所有的iptables,selinux Mysql的主从复制读写分离所需安装包: cmake-2.8.6.tar.gz mysql-5.5.22.tar.gz amoeba-mysql-binary-2.2.0.tar.gz jdk-7u65-linux-x64.t

mysql数据业务垂直+水平分割+主从复制读写分离

友情提示:本人第一次写技术博客,会继续完善,尽量做到图文并茂,通俗易懂,如果有什么写的不好的地方,还请大家多多提意见,您的意见将是我宝贵的资源.如果有兴趣的话,还可以一起讨论相关技术哦,亲!一定要注意软件版本哦! 联系方式 QQ:794884160 指导老师:双星  冯德勇老师  曾勇老师 一.拓扑图: 垂直+水平分割+主从复制+读写分离完整原理图: 仅说明原理,详细拓扑及参数参考本次实验拓扑图 本次试验拓扑图:(上图左侧部分) 二.实验描述: 根据业务原型先进行数据库垂直切割,然后用户数据根据

mysql主从复制读写分离-Altas

mysql主从复制读写分离 本文读写分离使用的软件是Altas,altas是奇虎360公司开发的开源数据库代理软件.它是基于mysql-proxy开发而成的 它集中地响应应用的请求,依据用户事先设置的规则,将SQL请求发送到特定的数据库上执行.基于此可以实现负载均衡.读写分离.高可用性等需求. mysql读写分离原理: 数据库层在高并发的情况下,i/o会产生瓶颈.而实际上用户读的请求要远远大于写的请求. 使用代理服务作为数据库前端,将不同的请求根据规则分配到不同的后端数据上面去,比如将写的请求分

【实战】Amoeba 代理 MySQL 主从复制 + 读写分离 【提供源码包】

目录简介: 1· Amoeba 的介绍2· MySQL 主从复制原理3· MySQL 读写分离原理4· 实战案例5· 总结归纳 Amoeba 的介绍 1)Amoeba 是什么: 1·Amoeba 的中文名是:变形虫.它是一个以MySQL为底层数据存储,并对应用提供MySQL协议接口的proxy.它集中地响应应用的请求,依据用户事先设置的规则,将SQL请求发送到特定的数据库上执行.基于此可以实现负载均衡.读写分离.高可用性等需求. 2·Amoeba相当于一个SQL请求的路由器,目的是为负载均衡.读

mysql主从复制读写分离之——proxysql应用

一.说明ProxySQL是一个开源的MySQL代理服务器,这意味着它充当MySQL服务器和访问其数据库的应用程序之间的中介.ProxySQL可以通过在多个数据库服务器池之间分配流量来提高性能,并且如果一个或多个数据库服务器发生故障,还可以通过自动故障切换到备用数据库来提高可用性. 系统环境:master1:ubuntu16.04 mysql5.6 192.168.1.10 3307 master2:ubuntu16.04 mysql5.6 192.168.1.20 3307slave1: ubu

数据库---mysql主从复制读写分离

http://m.open-open.com/m/lib/view/1413274853450.html 原理及架构分析 部署前准备 下载好源码包存放位置要与脚本中对应 mysql-5.5.22.tar.gz,cmake-2.8.6.tar.gz,amoeba-mysql-binary-2.2.0.tar.gz,jdk-6u14-linux-x64.bin selinux和iptables不做设置,关闭 系统光盘镜像为本地yum源,配置好yum文件 环境介绍: 主服务器(master):192.

MySQL5.6主从复制(读写分离)

MySQL主从复制(读写分离)和集群的区别: 1.主从复制(读写分离):一般需要两台及以上数据库服务器即可(一台用于写入数据,一台用于同步主的数据并用于数据查询操作).局限性:(1)配置好主从复制之后,同一张表,只能对一个服务器写操作.如果在从上执行了写操作,而之后主也操作了这张表,或导致主从不同步:据说可以配置成主主方式(2)主数据库服务器宕机,需要手动将业务系统切换到从数据库服务器.无法做到高可用性(除非再通过部署keepalive做成高可用方案).2.集群是由N台数据库服务器组成,数据的写

MySQL5.6主从复制(读写分离)教程

一.前言:为什么MySQL要做主从复制(读写分离)? 通俗来讲,如果对数据库的读和写都在同一个数据库服务器中操作,业务系统性能会降低. 为了提升业务系统性能,优化用户体验,可以通过做主从复制(读写分离)来减轻主数据库的负载. 而且如果主数据库宕机,可快速将业务系统切换到从数据库上,可避免数据丢失. 二.MySQL主从复制(读写分离)和集群的区别: 我对MySQL也是刚开始研究,不是很专业.我的理解是: 1.主从复制(读写分离):一般需要两台及以上数据库服务器即可(一台用于写入数据,一台用于同步主

mysql主从复制+读写分离 菜鸟入门

MYsql主从复制 1.mysql主从复制原理: Master将数据变化记录到二进制日志中[binary log] Slave将master的二进制日志[binary log]拷贝到自己的中继日志[relay log]中. Slave将中继入日志[relay log]事件在做一次,将数据变化,反应到自身数据库. 简述:mysql主从复制其实就是完全备份,和二进制日志备份还原的过程.二进制日志的还原基本上是实时进行的.注意不是完全实时,而是异步实时,主从直接的执行有延迟.如果master压力过大,

redis配置读写分离以及利用哨兵sentinel进行自动主从切换

redis利用哨兵(sentinel)进行主从切换,断断续续,自己终于通过配置验证了一下该功能,其中遇到过一些的问题,也是耗费了大量的时间才解决,接下来分享下配置的过程以及遇到的问题和解决方法.希望对各位有所帮助. 首先说一下实验环境: redis软件:redis-3.2.1(安装在虚拟机的linux系统中) 宿主主机:window8.1 x64 secureCRT:宿主主机安装此软件来操作linux,这只是个人喜欢,大家可以不装. 对于redis在linux如何安装这里不进行说明,不懂的朋友可