Redis主从复制(下)

@toc
上篇链接：https://blog.csdn.net/qq_43753724/article/details/117423529?spm=1001.2014.3001.5501

5.2 薪火相传：

• 上一个Slave可以是下一个slave的Master，Slave同样可以接收其他slaves的连接和同步请求，那么该slave作为了链条中下一个的master,可以有效减轻master的写压力
• 中途变更转向：会清除之前的数据，重新简历拷贝最新的
• 命令：slaveof 新主库IP 新主库端口
  我们现在将6379作为主机，将6380作为6379的从机，将6381作为6380的从机

5.2.1 配置之前先查看主机的主从配置信息：

info replication

6379:

5.2.2 配置6381端口的主机位6380端口：

SLAVEOF 127.0.0.1 6380

5.2.3 查看6381端口的主从配置信息：

info replication

5.2.4 查看6380端口的主从配置信息：

可以看到6380端口的role还是slave，且从机为6381

5.2.5 查看主机6379端口：

可以看到6379端口的从机是6380

5.2.6 主机(6379端口)设置值：set k9 v9

5.2.7 从机获取值：

5.3 反客为主

假设配置之前，6379端口的机器为主机，6380和6381都是6379的从机。

5.3.1 假设主机挂掉：

5.3.2 配置6380反客为主

 SLAVEOF no one

再设置个值

5.3.3 让6381的主机变为6380

 SLAVEOF 127.0.0.1 6380

获取k10

5.3.4 6379重新启动：

可以看到，这个没有从机。获取k10也获取不到。

5.4 复制原理

• Slave启动成功连接到master后会发送一个sync命令
• Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步
• 全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
• 增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步，但是只要是重新连接master,一次完全同步（全量复制）将被自动执行

5.5 哨兵模式

5.5.1 什么是哨兵模式：

反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库
配置哨兵：假设现在的主机是6379端口，6380和6381端口的都是从机。

5.5.2 创建sentinel.conf文件

在自定义的目录下面创建sentinel.conf文件
我的目录是 /myredis/

touch sentinel.conf
vi sentinel.conf

在文件内添加：

sentinel monitor host6379 127.0.0.1 6379 1

意思让哨兵监听6379端口，上面最后一个数字1，表示主机挂掉后salve投票看让谁接替成为主机，得票数多少后成为主机

5.5.3 启动哨兵

cd /usr/local/bin
ll

启动:redis-sentinel /myredis/sentinel.conf

5.5.4 挂掉6379端口(原来的主机)，测试哨兵的监控

查看哨兵的监控情况：
如下图，可以看到，投票选出新的master为端口为6381端口的机器。

5.5.5 查看6381(新的master)和6380端口的主从配置

info replication

6380端口：

6381端口：

可以看到，现在的情况是6381端口的机器为主机，6380端口的机器为从机。

5.5.6 如果之前的master重启回来，会不会冲突？

让6379端口的机器重启：

 redis-server /myredis/redis6379.conf
 redis-cli -p 6379

我们查看下改机器的主从配置：

info replication

可以看到，6379已经变成了6381的从机
再查看下6381的主从配置：

可以看到主机6381下面有两个从机6379和6380

查看哨兵的监控情况：

可以看到，哨兵监控到原来的6379主机复活之后，将其作为了新挑选出的主机6381的从机。

5.6、复制的缺点：复制延时

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