redis:主从复制

redis:主从复制redis:主从复制

主机数据更新后根据配置和策略,自动同步到备机的master/slaver机制,masters以写为主,

slave以读为主

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qIZ3YNIG-1651919097704)(C:\Users\lcarus,\Documents\笔记\picture\屏幕截图 2022-04-27 140811.png)]

优势:

1、读写分离,分担服务器压力,一个写,另外的其他读

  • 读操作:主库、从库都可以接收;

  • 写操作:首先到主库执行,然后,主库将写操作同步给从库。

    那么,为什么要采用读写分离的方式呢?

    你可以设想一下,如果在上图中,不管是主库还是从库,都能接收客户端的写操作,那么,一个直接的问题就是:如果客户端对同一个数据(例如k1)前后修改了三次,每一次的修改请求都发送到不同的实例上,在不同的实例上执行,那么,这个数据在这三个实例上的副本就不一致了(分别是v1、v2和v3)。在读取这个数据的时候,就可能读取到旧的值。

    如果我们非要保持这个数据在三个实例上一致,就要涉及到加锁、实例间协商是否完成修改等一系列操作,但这会带来巨额的开销,当然是不太能接受的。

2、容灾的快速恢复,一台从宕机,其他能继续,一主多从

配置:

1、mkdir myredis

2、在myredis中复制一个redis.conf

3、创建其他三个配置文件:一主三从

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-T2xVIjas-1651919097706)(C:\Users\lcarus,\Documents\笔记\picture\12314214.png)]

如果redis配置了密码需要在从库的conf里添加
masterauth 密码 不然配置从库的时候从库显示有主库 主库却看不见从库

4、启动三个redis服务

redis-server redis1.conf redis-server redis2.conf redis-server redis3.conf

ps -ef | grep redis 查看情况

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JrA36L1m-1651919097707)(C:\Users\lcarus,\Documents\笔记\picture\主从3.png)]

启动成功

连接redis-cli -p 6379 redis-cli -p 6380 redis-cli -p 6381

info replication 查看主从情况

配从不配主:

Linux本机ip:192.168.198.129

slaveof 【主机的ip】【主机的port】

数据同步:

主从库间数据第一次同步的三个阶段

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DUdiEv6L-1651919097707)(C:\Users\lcarus,\Documents\笔记\picture\主从数据同步.webp)]

第一阶段是主从库间建立连接、协商同步的过程,主要是为全量复制做准备。

  • runID,是每个Redis实例启动时都会自动生成的一个随机ID,用来唯一标记这个实例。当从库和主库第一次复制时,因为不知道主库的runID,所以将runID设为“?”。
  • offset,此时设为-1,表示第一次复制。
  • 这里有个地方需要注意,FULLRESYNC响应表示第一次复制采用的全量复制,也就是说,主库会把当前所有的数据都复制给从库。

第二阶段,主库将所有数据同步给从库。从库收到数据后,在本地完成数据加载。这个过程依赖于内存快照生成的RDB文件。为了避免之前数据的影响,从库需要先把当前数据库清空。

在主库将数据同步给从库的过程中,主库不会被阻塞,仍然可以正常接收请求。否则,Redis的服务就被中断了。但是,这些请求中的写操作并没有记录到刚刚生成的RDB文件中。为了保证主从库的数据一致性,主库会在内存中用专门的replication buffer,记录RDB文件生成后收到的所有写操作。

最后,也就是第三个阶段,主库会把第二阶段执行过程中新收到的写命令,再发送给从库。具体的操作是,当主库完成RDB文件发送后,就会把此时replication buffer中的修改操作发给从库,从库再重新执行这些操作。这样一来,主从库就实现同步了。

一主多仆:

1:主机上可写可读,从机上只能读

2:主机挂掉,重启就行,从机(不会变成主机) 并且显示主机状态为down 等主机恢复之后 主机就还是主机 从机也还是从机

3:从机重启需重设:slaveof 127.0.0.1 6179,不然从机就会变回主机

4:挂掉之后重新配置回从机时 会把主机数据从头到尾复制连接

当从连接上主服务器之后,从服务器向主服务发送进行数据同步消息

主服务器接到从服务器发送过来的同步消息,把主服务器数据进行持久化,

rdb文件,把rdb文件发送给从服务器,从服务器拿到rdb进行读取

主从库间网络断了怎么办?

在Redis 2.8之前,如果主从库在命令传播时出现了网络闪断,那么,从库就会和主库重新进行一次全量复制,开销非常大。

从Redis 2.8开始,网络断了之后,主从库会采用增量复制的方式继续同步。听名字大概就可以猜到它和全量复制的不同:全量复制是同步所有数据,而增量复制只会把主从库网络断连期间主库收到的命令,同步给从库。

当主从库断连后,主库会把断连期间收到的写操作命令,写入replication buffer,同时也会把这些操作命令也写入repl_backlog_buffer这个缓冲区。

repl_backlog_buffer是一个环形缓冲区,主库会记录自己写到的位置,从库则会记录自己已经读到的位置。

对主库来说,对应的偏移量就是master_repl_offset。主库接收的新写操作越多,这个值就会越大。

同样,从库在复制完写操作命令后,它在缓冲区中的读位置也开始逐步偏移刚才的起始位置,此时,从库已复制的偏移量slave_repl_offset也在不断增加。正常情况下,这两个偏移量基本相等。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SNcTSJiR-1651919097708)(C:\Users\lcarus,\Documents\笔记\picture\offset.webp)]

主从库的连接恢复之后,从库首先会给主库发送psync命令,并把自己当前的slave_repl_offset发给主库,主库会判断自己的master_repl_offset和slave_repl_offset之间的差距。

在网络断连阶段,主库可能会收到新的写操作命令,所以,一般来说,master_repl_offset会大于slave_repl_offset。此时,主库只用把master_repl_offset和slave_repl_offset之间的命令操作同步给从库就行。

不过,有一个地方我要强调一下,因为repl_backlog_buffer是一个环形缓冲区,所以在缓冲区写满后,主库会继续写入,此时,就会覆盖掉之前写入的操作。如果从库的读取速度比较慢,就有可能导致从库还未读取的操作被主库新写的操作覆盖了,这会导致主从库间的数据不一致。

如果它配置得过小,在增量复制阶段,可能会导致从库的复制进度赶不上主库,进而导致从库重新进行全量复制。所以,通过调大这个参数,可以减少从库在网络断连时全量复制的风险。

薪火相传:

通过分析主从库间第一次数据同步的过程,你可以看到,一次全量复制中,对于主库来说,需要完成两个耗时的操作:生成RDB文件和传输RDB文件。

如果从库数量很多,而且都要和主库进行全量复制的话,就会导致主库忙于fork子进程生成RDB文件,进行数据全量同步。fork这个操作会阻塞主线程处理正常请求,从而导致主库响应应用程序的请求速度变慢。此外,传输RDB文件也会占用主库的网络带宽,同样会给主库的资源使用带来压力。那么,有没有好的解决方法可以分担主库压力呢?

其实是有的,这就是“主-从-从”模式。

比如6380是6379的从机 slaveof 127.0.0.1 6379
6381是6380的从机 slaveof 127.0.0.1 6380

特点:上一个Slave可以是下一个slave的Master,Slave同样可以接收其他 slaves的连接和同步请求,那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力,去中心化降低风险

优点:减少压力
缺点:其中一个挂了,后面的都没了

反客为主:

这是当主机挂了之后,在从机设计slaveof no one 这个从机 会变成主机

但是变成的只是普通主机 如果是薪火相传的话他的从机还是他的从机

其他和他并列的从机不会变成他的从机

哨兵模式:

哨兵主要负责的就是三个任务:监控、选主(选择主库)和通知。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Kk4N0tjg-1651919097709)(C:\Users\lcarus,\Documents\笔记\picture\哨兵.webp)]

监控是指哨兵进程在运行时,周期性地给所有的主从库发送PING命令,检测它们是否仍然在线运行。如果从库或主库没有在规定时间内响应哨兵的PING命令,哨兵就会把它标记为“下线状态”;

主机的监控:

一旦哨兵判断主库下线了,就会开始选择新主库,并让从库和新主库进行数据同步,这个过程本身就会有开销,例如,哨兵要花时间选出新主库,从库也需要花时间和新主库同步。而在误判的情况下,主库本身根本就不需要进行切换的,所以这个过程的开销是没有价值的。正因为这样,我们需要判断是否有误判,以及减少误判。

那怎么减少误判呢?在日常生活中,当我们要对一些重要的事情做判断的时候,经常会和家人或朋友一起商量一下,然后再做决定。

哨兵机制也是类似的,它通常会采用多实例组成的集群模式进行部署,这也被称为哨兵集群。引入多个哨兵实例一起来判断,就可以避免单个哨兵因为自身网络状况不好,而误判主库下线的情况。同时,多个哨兵的网络同时不稳定的概率较小,由它们一起做决策,误判率也能降低。

监控主机是否down,如果是,就将从机选择一个, 选主:

检查从库的当前在线状态,还要判断它之前的网络连接状态,筛出连接不稳定的,过滤掉了不适合做主库的从库,接下来就要给剩余的从库打分了。

第一轮:优先级最高的从库得分高。

用户可以通过slave-priority配置项,给不同的从库设置不同优先级。

第二轮:和旧主库同步程度最接近的从库得分高。

第三轮:ID号小的从库得分高。

以前“并列的从机”以及“以前的主机”变成它的从机。

首先前提是一主二从,二从是并列的而不是薪火相传
下面开始实战测试

  1. 在myredis下再建一个配置文件 sentinel.conf

  2. 打开 sentinel.conf配置,在里面添加 sentinel monitor mymaster 127.0.0.1 6379 1

    其中mymaster为监控对象起的服务器名称,1 为至少有多少个哨兵同意迁移(只要有一个哨兵同意即可迁移)。

  3. 再添加sentinel auth-pass mymaster 1226136238

  4. redis-sentinel sentinel.conf 启动哨兵模式

  5. 关掉6379端口的主机

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DMv8Wv21-1651919097709)(C:\Users\lcarus,\Documents\笔记\picture\哨兵.png)]

哨兵模式总结

当主服务器down机时,新服务器选举是有策略的
选择条件从上到下依次
1.选择优先级靠前的
优先级在redis.conf中默认:replica-priority 100,值越小优先级越高
2.选择偏移量最大的
偏移量是指获得原主机数据最全的
3.选择runid最小的从服务
每个redis实例启动后都会随机生成一个40位的runid
19097709)]

哨兵模式总结

当主服务器down机时,新服务器选举是有策略的
选择条件从上到下依次
1.选择优先级靠前的
优先级在redis.conf中默认:replica-priority 100,值越小优先级越高
2.选择偏移量最大的
偏移量是指获得原主机数据最全的
3.选择runid最小的从服务
每个redis实例启动后都会随机生成一个40位的runid

欢迎分享,转载请注明来源:内存溢出

原文地址:http://outofmemory.cn/langs/893875.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2022-05-14
下一篇2022-05-14

随机推荐

发表评论

登录后才能评论

评论列表(0条)

    保存