当前位置:网站首页>Redis 主从复制

Redis 主从复制

2022-07-07 23:21:00 beginnerDZ

Redis 主从复制

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

一主多从 写服务器只有一个

请添加图片描述

作用:

  • 读写分离

  • 容灾的快速恢复

    一个从服务器G了,应该继续使用另一个从服务器

如果担心主G了 可以使用集群

请添加图片描述

实践:

info replication 查看当前的状态

请添加图片描述

在从机上执行 slaveof <ip> <port> 成为某个实例的从服务器

slaveof 127.0.0.1 6379

如果 master 和 slave 都设置了密码,并且密码相同(必须),则验证成功。

最终效果:

  • 在主机上写,在从机上可以读取数据 ,在从机上写数据报错
  • 主机挂掉,重启就行,一切如初
  • 从机重启需重设:slaveof 127.0.0.1 6379(可以将配置增加到文件中。永久生效。)

问题1:一个从服务器 挂了一段时间,然后又重新活了。期间主已经写过数据了,从服务器中重新启动后,也有挂期间写的数据,会自动复制过来

主从复制的原理

请添加图片描述

详细:

1.主从服务器间的第一次同步的过程可分为三个阶段:

  • 第一阶段是建立链接、协商同步;
  • 第二阶段是主服务器同步数据给从服务器;
  • 第三阶段是主服务器发送新写操作命令给从服务器。

psync 命令包含两个参数,分别是主服务器的 runID 和复制进度 offset。

runID,每个 Redis 服务器在启动时都会自动生产一个随机的 ID 来唯一标识自己。当从服务器和主服务器第一次同步时,因为不知道主服务器的 run ID,所以将其设置为 “?”。
offset,表示复制的进度,第一次同步时,其值为 -1。

从服务器收到 RDB 文件后,会先清空当前的数据,然后载入 RDB 文件。

但是这期间的写操作命令并没有记录到刚刚生成的 RDB 文件中,这时主从服务器间的数据就不一致了。

那么为了保证主从服务器的数据一致性,主服务器会将在 RDB 文件生成后收到的写操作命令,写入到 replication buffer 缓冲区里。

第三阶段:主服务器发送新写操作命令给从服务器

在主服务器生成的 RDB 文件发送后,然后将 replication buffer 缓冲区里所记录的写操作命令发送给从服务器,然后从服务器重新执行这些操作。

至此,主从服务器的第一次同步的工作就完成了。

2.主从服务器在完成第一次同步后,双方之间就会维护一个 TCP 连接

基于长连接的命令传播,通过这种方式来保证第一次同步后的主从服务器的数据一致性。

问题:

主从服务器在完成第一次同步后,就会基于长连接进行命令传播。

可是,网络总是不按套路出牌的嘛,说延迟就延迟,说断开就断开。

如果主从服务器间的网络连接断开了,那么就无法进行命令传播了,这时从服务器的数据就没办法和主服务器保持一致了,客户端就可能从「从服务器」读到旧的数据。
请添加图片描述

在 Redis 2.8 之前,如果主从服务器在命令同步时出现了网络断开又恢复的情况,从服务器就会和主服务器重新进行一次全量复制,很明显这样的开销太大了,必须要改进一波。

从 Redis 2.8 开始,网络断开又恢复后,从主从服务器会采用增量复制的方式继续同步,也就是只会把网络断开期间主服务器接收到的写操作命令,同步给从服务器。

主要有三个步骤:

从服务器在恢复网络后,会发送 psync 命令给主服务器,此时的 psync 命令里的 offset 参数不是 -1;
主服务器收到该命令后,然后用 CONTINUE 响应命令告诉从服务器接下来采用增量复制的方式同步数据;
然后主服务将主从服务器断线期间,所执行的写命令发送给从服务器,然后从服务器执行这些命令。

主从复制共有三种模式:全量复制、基于长连接的命令传播、增量复制

薪火相传

可以知道主从服务器在第一次数据同步的过程中,主服务器会做两件耗时的操作:生成 RDB 文件和传输 RDB 文件。

我们在「从服务器」上执行 replicaof <目标服务器的IP> 6379,使其作为目标服务器的从服务器。从服务器又挂了一个从服务器

请添加图片描述

缺点就是从服务器挂了 另一个从也无法同步了(我的从的从 不是我的从 hhhhhh)

哨兵模式-反客为主

手动:

当一个master宕机后,后面的slave可以立刻升为master,其后面的slave不用做任何修改。用 slaveof no one 将从机变为主机。

哨兵模式:能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库

配置

例:在一主二从的基础上 操作

目录下新建sentinel.conf文件,名字绝不能错。

内容:

sentinel monitor mymaster 127.0.0.1 6379 1

其中mymaster为监控对象起的服务器名称, 1 为至少有多少个哨兵同意迁移的数量。

第三个参数:哨兵名字,可自行修改。(若修改了,那后面涉及到的都得同步)
第四个参数:master主机ip地址
第五个参数:redis端口号
第六个参数:哨兵的数量。比如2表示,当至少有2个哨兵发现master的redis挂了,那么就将此master标记为宕机节点。
这个时候就会进行故障的转移,将其中的一个从节点变为master

redis-sentinel /myredis/sentinel.conf 启动哨兵模式

主机挂掉后 哨兵的输出: 红线下

请添加图片描述

+switch-master mymaster 127.0.0.1 6379 127.0.0.1 6381

选择了6381这台作为主机,原来的6379重新启动后成为了从机(如果3679没有配置密码 要配置一致的密码)

哪个从机会被选举为主机呢?

请添加图片描述

根据优先级别:slave-priority

偏移量是指获得原主机数据最全的

每个redis实例启动后都会随机生成一个40位的runid

优先级在redis.conf中默认:slave-priority 100,(有的版本是replica-priority)值越小优先级越高

请添加图片描述

参考

参考

原网站

版权声明
本文为[beginnerDZ]所创,转载请带上原文链接,感谢
https://blog.csdn.net/beginnerdzz/article/details/125647619