加入收藏 | 设为首页 | 会员中心 | 我要投稿 河北网 (https://www.hebeiwang.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 站长百科 > 正文

redis系列:主从复制

发布时间:2019-02-21 14:42:06 所属栏目:站长百科 来源:云栖社区 原文链接:https://yq.aliyun.co
导读:作者:勿妄 来历:云栖社区 原文链接:https://yq.aliyun.com/articles/624146?spm=a2c4e.11153940.bloghomeflow.211.3538291aV5eFMp 1 简介 这篇文章首要报告Redis的主从复制成果。会依次从情形搭建、成果测试和道理说明几个方面举办先容。 2 筹备事变 服
作者:勿妄 来历:云栖社区

原文链接: https://yq.aliyun.com/articles/624146?spm=a2c4e.11153940.bloghomeflow.211.3538291aV5eFMp


1 简介

这篇文章首要报告Redis的主从复制成果。会依次从情形搭建、成果测试和道理说明几个方面举办先容。

2 筹备事变

处事器架构图如下  
redis系列:主从复制

启动主处事器101,行使 info replication 呼吁查察状态,可以看到role为master(也就是脚色为主主处事器),connected_salaves的值为0(从处事器数目为0)  
redis系列:主从复制

接下来用修改设置文件的方法将102呆板插手的主从复制傍边

然后再用呼吁的方法同样将103呆板插手的主从复制傍边。

2.1 用修改设置文件的方法将102呆板插手到主从

ip地点为192.168.17.102的呆板的Redis设置文件增进slaveof 192.168.17.101 6379  
启动102的redis,状态如下  
redis系列:主从复制

可以看到role变为slave(脚色为从处事器),master_host(主处事器IP地点)为192.168.17.101,master_port(主处事器端口)为6379。  
此时101主处事器的主从状态如下,可以看到connected_salaves的值变为1,以及增进了一行slave0(从处事器的状态)  
redis系列:主从复制

2.2 用呼吁的方法将103呆板插手到主从

未执行slaveof呼吁的主从状态如下  
redis系列:主从复制

开始执行slaveof呼吁

192.168.17.103:6379> slaveof 192.168.17.101 6379OK

再次查察状态,可以看到脚色已经酿成从处事器  
redis系列:主从复制

此刻再来看看主处事器的状态,可以看到从处事器数目酿成2,又多了一条从处事器的信息  
redis系列:主从复制

到这里主从情形就搭好了,此刻来测试一波

2.3 测试

此刻主处事器101输入呼吁

192.168.17.101:6379> set 101 101OK

然后在从处事器102上查察全部的键,发明有键101,接着配置键102

192.168.17.102:6379> keys *1) "101"192.168.17.102:6379> get 101"101"192.168.17.102:6379> set 102 102(error) READONLY You can't write against a read only slave.

发明呈现错误 (error) READONLY You can't write against a read only slave.  后头在报告堕落缘故起因

此刻在从处事器103上查察全部的键,发明也有 101

192.168.17.103:6379> keys *
1) "101"

再向主处事器101输入呼吁

192.168.17.101:6379> set ip ipOK

然后到从处事器103上查察全部的键

192.168.17.103:6379> keys *
1) "101"
2) "ip"

可以看到多了一个键,声名主处事的数据同步到了从处事器上,操纵进程看下图  
redis系列:主从复制

2.4 其他

2.4.1 (error) READONLY You can't write against a read only slave.

呈现错误 (error) READONLY You can't write against a read only slave.  是由于 
从节点默认是只读的,如需修改可以再设置文件中修改下面这个属性

slave-read-only yes

2.4.2 主处事器配置暗码

当主处事配置暗码时,设置文件必要增进如需参数

masterauth <master-password>
3 实现道理

当我在从处事器103上输入slaveof呼吁时,呈现如下日记  
redis系列:主从复制

总的来说主从复制成果的具体步调可以分为7个步调:

  1. 配置主处事器的地点和端口

  2. 成立套接字毗连

  3. 发送PING呼吁

  4. 身份验证

  5. 发送端口信息

  6. 同步

  7. 呼吁撒播

接下来别离论述每个步调

3.1配置主处事器的地点和端口

主从复制的第一步就是配置主处事器的地点和端口,当输入slaveof呼吁可能在设置文件中设置信息时,从处事器会将主处事器的ip地点和端标语生涯随处事器状态的属性内里。

3.2 成立套接字毗连

在slaveof呼吁执行之后,从处事器会按照配置的ip和端口,向主处事器简历socket毗连。

3.3 发送PING呼吁

socket毗连乐成后,从处事器会发送一PING呼吁给主处事器。

这时辰PING呼吁可以搜查socket的读写状态是否正常,还可以搜查主处事器可否正常处理赏罚呼吁哀求。

从处事器在发送PING呼吁时也许赶上的环境如下图 
图片来自Redis计划与实现

3.4 身份验证

从处事器收到主处事器的PONG回覆后,会搜查从处事器是否配置masterauth,配置则举办身份验证,未配置则跳过该步调。从处事器在身份验证时也许赶上的环境如下

图片来自Redis计划与实现

3.5 发送端口信息

身份验证通事后,从处事器会向主处事器发送本身的监听端标语。主处事器收到之后会将端标语记录到从处事器对应的状态属性中。在主处事器挪用 info replication 可以看到从处事器的port,如下

redis系列:主从复制

3.6 同步

发送端口信息之后,从处事器会向主处事器发送PSYNC呼吁,执行同步操纵,并将本身的数据库同步至主处事器数据库当前的状态。

同步这块内容会在后头具体描写

3.7 呼吁撒播

当完成同步操纵之后,主从处事器便会进入呼吁撒播阶段。这时辰主从处事器的数据是同等的,当主处事器有新的写呼吁时,会将改呼吁发送给从处事器,从处事器吸取呼吁并执行便可以担保与主处事器的数据保持同等。  
那么Redis是怎样担保主从处事器同等处于毗连状态以及呼吁是否丢失?  
答:呼吁撒播阶段,从处事器会操作心跳检测机制按时的向主处事发送动静。  
从处事器发送的呼吁如下

REPLCONF ACK <replication_offset>

replication_offset暗示从处事器当前的复制偏移量  
接下来看看心跳机制

3.7.1 心跳检测机制

心跳检测机制的浸染有三个:

  1. 搜查主从处事器的收集毗连状态

  2. 帮助实现min-slaves选项

  3. 检测呼吁丢失

3.7.1.1 搜查主从处事器的收集毗连状态

主处事器信息中可以看到所属的从处事器的毗连信息,state暗示从处事器状态,offset暗示复制偏移量,lag暗示耽误值(几秒之前有过心跳检测机制)

redis系列:主从复制

3.7.1.2 帮助实现min-slaves选项

Redis.conf设置文件中有下方两个参数

# 未到达下面两个前提时,写操纵就不会被执行# 起码包括的从处事器# min-slaves-to-write 3# 耽误值# min-slaves-max-lag 10

假如将两个参数的注释打消,那么假如从处事器的数目少于3个,可能三个从处事器的耽误(lag)大于便是10秒时,主处事器城市拒绝执行写呼吁。

3.7.1.3 检测呼吁丢失

在从处事器的毗连信息中可以看到复制偏移量,假云云时主处事器的复制偏移量与从处事器的复制偏移量纷歧致时,主处事器会补发缺失的数据。

4 同步道理

同步分为全量重同步和部门重同步。那么是什么抉择采纳全量重同步照旧部门重同步操纵?

图片来自Redis计划与实现

4.1 全量重同步

全量重同步的步调如下

  1. 主节点收到从处事器的全量重同步哀求时,主处事器便开始执行bgsave呼吁,同时用一个缓冲区记录以后刻开始执行的全部写呼吁。

  2. 当主处事器的bgsave呼吁执行完毕后,会将天生的RDB文件发送给从处事器。从处事器吸取到RDB文件时,,会将数据文件生涯到硬盘,然后加载到内存中。

  3. 主处事器将缓冲区全部缓存的呼吁发送到从处事器,从处事器吸取并执行这些呼吁,将从处事器同步至主处事器沟通的状态。

4.2 部门重同步

要想相识部门重同步的步调,必要先相识部门重同步所必要的几个属性

  1. 复制偏移量

  2. 复制缓冲区

  3. 运行ID

4.2.1 复制偏移量

从主处事器的复制信息可以看到从处事器slave0和slave1都有一个参数offset,这个参数就是从处事器的复制偏移量。master_repl_offset这个参数就是主处事器的偏移量。如下图

redis系列:主从复制

主处事器的复制偏移量生涯向从处事器发送过的字节数据。  
从处事器的复制偏移量生涯着从主处事器吸取的字节数据。  
通过比拟主处事器和从处事器的复制偏移量就可以知道呼吁是否丢失,丢失则补发复制偏移量相差的字节呼吁。  
那么这些字节数据是存放在那边的呢?

4.2.2 复制缓冲区

这些字节数据都是存放在主处事器的复制缓冲区里的。复制缓冲区是一个牢靠长度(fixed-size)先辈先出(FIFO)的行列,默认巨细为1MB。默认巨细可以对下方的参数举办修改

# repl-backlog-size 1mb

那么复制缓冲区的数据是什么时辰插手进去的呢?

答:在呼吁撒播阶段,主节点除了将写呼吁发送给从节点,还会发送一份给复制积存缓冲区。

redis系列:主从复制

复制缓冲区内里会生涯着一部门最撒播的写呼吁和每个字节响应的复制偏移量。

因为复制缓冲区的巨细是有限定的,以是生涯的数据也是有限定的。假如从处事器与主处事器的复制偏移量相差的数据大于复制缓冲去存储的数据时,同样不会执行部门重同步。

举个例子,主处事器的复制偏移量为20000、缓冲区能生涯的数据只有5000,从处事器的复制偏移量为10000。这时从处事器与主处事器复制偏移量10000,而缓冲区只有5000,那么照旧会执行全量重同步。假如相差的复制偏移量小于5000,才会执行部门重同步。

4.2.3 运行ID

每个Redis处事器启动时,城市有自动生本钱身的运行ID。  
当从处事器对主处事器举办首次复制时,主处事器会发送本身的运行ID给从处事器。  
当从处事器断线重连时,会将之前主处事器的运行ID发送给当前毗连的主处事器。这时辰会呈现下面两种环境

  1. 运行ID和主处事器同等,主处事器可以实行执行部门重同步操纵。

  2. 运行ID和主处事器纷歧致,声名之前毗连的主处事器与这次毗连差异,开始执行全量重同步操纵。

5 相干设置
################################# REPLICATION ################################## slaveof <主处事器ip> <主处事器端口># slaveof <masterip> <masterport># masterauth <主处事器Redis暗码># masterauth <master-password># 当slave丢失master可能同步正在举办时,假如产生对slave的处事哀求# yes则slave依然正常提供处事# no则slave返回client错误:"SYNC with master in progress"slave-serve-stale-data yes# 指定slave是否只读slave-read-only yes# 无硬盘复制成果repl-diskless-sync no# 无硬盘复制成果隔断时刻repl-diskless-sync-delay 5# 从处事器发送PING呼吁给主处事器的周期# repl-ping-slave-period 10# 超时时刻# repl-timeout 60# 是否禁用socket的NO_DELAY选项repl-disable-tcp-nodelay no# 配置主从复制容量巨细,这个backlog 是一个用来在 slaves 被断开毗连时存放 slave 数据的 buffer# repl-backlog-size 1mb# master 不再毗连 slave时backlog的存活时刻。# repl-backlog-ttl 3600# slave的优先级slave-priority 100# 未到达下面两个前提时,写操纵就不会被执行# 起码包括的从处事器# min-slaves-to-write 3# 耽误值# min-slaves-max-lag 10
结语

主从的设置文件:[ https://github.com/rainbowda/learnWay/tree/master/learnRedis/replication ,有必要可以下载。

Redis的主从复制成果就先容到这里了。固然说主从办理了读写疏散,读数据的负载平衡,可是一旦某个节点呈现妨碍,不能自动回覆,主从切换等成果。以是就有了哨兵的成果。

(编辑:河北网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    热点阅读