Redis主从复制

最新推荐文章于 2024-09-09 09:47:53 发布

风城烟雨丶

最新推荐文章于 2024-09-09 09:47:53 发布

阅读量397

点赞数 1

分类专栏： Redis 文章标签：数据库

本文链接：https://blog.csdn.net/weixin_44552039/article/details/108714411

版权

Redis 专栏收录该内容

8 篇文章 0 订阅

订阅专栏

Redis复制 — Master/Slave

介绍

Redis复制也就是我们所说的主从复制，主机数据更新后根据配置和策略，自动同步到备机的 master/slaver 机制，Master 以写为主，Slave 以读为主。

能干嘛

读写分离
容灾恢复

…

如何使用

口诀：配从不配主！
从库配置：slaceof 主库 IP 主库端口。
每次与master 断开之后，都需要重新连接，除非你在 redis.conf 文件中进行相关配置！
```
Info replication
```

修改配置文件细节操作

拷贝多个 redis.conf 文件

-- 复制命令
cp 原文件名 新文件名

-- 例
cp redis.conf redis6379.conf

在这里插入图片描述

我们重新使用三个新的redis.conf文件

开启 daemonize yes

把三个配置文件中的daemonize都设置为yes
pid 文件名字

为了更加明显，我们把里面的名称进行修改，到时候好查看
指定端口

因为有三个redis，所以需要一个端口对应一个redis，还有两个redis的端口一个为6380一个为6381，这里就不给大家演示了
log 文件名字

这个默认是一个空字符串，我们将它设置一下
dump.rdb 名字

备份文件的名称，默认为dump，我们在它后面加上对应的端口号，查看的时候更加清晰易懂！

其实都是很简单的设置，虽然我这里只演示了一个，但是相信大家应该都会举一反三！！冲冲冲！！！

常用三招

一主二仆

至少要三台机器，三个redis，一个主redis，两个从redis（在刚才我们已经配置好了）

启动三台redis 在这里插入图片描述

因为都是新的，所以里面都没有任何数据，我们还可以在启动后查看是否生成了日志文件

三个日志文件都成功创建了！而且里面都成功记录了！

状态

分配角色

我们可以先看一下当前的redis角色

在这里插入图片描述

可以很明显的发现，他们都是master，表示他们在同一级上，接下来我们就将其中两台机器进行修改，将他们改为从redis

在这里插入图片描述

这里简单说明一下：我们先在6379中插入k1和k2，然后让6380和6381跟6379进行绑定，绑定之后我们在插入一条数据k3，然后去另外两个redis中进行读操作，这个时候按照逻辑来说可能大家会认为，在绑定之前写入的数据是无法读取出来的，但是上面却可以读出来，其实这是因为一旦进行了绑定，那么从服务器就会读取主服务器的所有内容！

绑定后我们再次查看角色

在这里插入图片描述

除了6379还是原来的以外，其它两个都变成了slave，并且在6379下面还可以看到我们所绑定的redis

尝试写入数据

在这里插入图片描述

上图可以明显的看到，我们在6379中可以成功写入数据，但是在其他两个里面却无法正常写入！在最开始的时候我们也说过了，“Master 以写为主，Slave 以读为主”，所以一旦绑定之后，只有主redis可以进行写操作，从redis只能进行读操作。

这里也就考虑出了一个问题，如果主redis突然崩了，这个时候从redis会发生什么呢？

在这里插入图片描述

我们关闭6379之后，从redis并不会自动的就变为主redis，而是继续为“从redis”。我们在想一下，如果这个时候6379突然又好了，那它的角色会是什么呢？我们来看一下效果

哦吼~它还是主redis，那也就表示我们在里面进行写入操作后，从redis依然可以读取到！

刚才说完了主redis突然崩了的情况，接下来再给大家说一下某一台从redis崩了会发生什么

在这里插入图片描述

在6380崩了的时候我们写入了k5，再次启动6380的时候会自动变回master（除非自己配置了），所以在崩坏的期间主机写入的数据，恢复后的从redis是读取不到的！

如果想要继续跟上主redis，那么就需要重新进行连接！
slaveof 127.0.0.1 6379

薪火相传

上一个 Slave 可以是下一个 slave 的 Master，Slave 同样可以接收其他 slaves 的连接和同步请求，那么该 slave 作为了链条中下一个的 master，可以有效减轻master 的写压力！

中途变更转向：会清除之前的数据，重新建立拷贝最新的

slaveof 新主库 IP 新主库端口

在这里插入图片描述

我们首先将6381换绑至6380下，然后我们再次查看6379的时候就会发现只剩下一个（6380），然后我们在6379中写入一行数据，之后再6380和6381中进行读取，这样的效果和之前一主二仆的效果差不多。只要主redis写入了新的数据，那么从redis也依旧可以获得。

反客为主

我们先把刚才换绑的redis6381重新绑定到6379中

在这里插入图片描述

案例

-- 转成主数据库
slaveof no one

在这里插入图片描述

① 关闭 redis6379

② 关闭6379后，其他两个就没有了主redis，所以我们将6380转成主数据库，让它变回master角色

③ 变回master角色

④ 6381没有解除绑定，所以它还会继续等待6379

接下来我们就要做到让6380变为主redis

在这里插入图片描述

① 将6381换绑至6380

② 在6380中新写入一行数据

③ 在6381中读取刚才在6380中写入的数据，可以正常读取到

④ 重新启动6379进行读取，可以明显得发现无法读取到刚才再6380中写入的数据

复制原理

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

哨兵机制

Redis-Sentinel 是 Redis 官方推荐的高可用（HA）方案，当用 Reids 做master-slave高可用方案时，假如 master 宕机了，redis 本身（包括它的很多客服端）都没有实现自动的主备切换，而 Redis-Sentinel 本身也是一个独立运行的进程，它能监控多个 master-slave 集群，发现 master 宕机后能自动切换。

简单来说就是反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

在公司中，有人上班的时候使用反客为主可能还可以，但是如果在大家都下班了的环境下，主服务器突然崩了，这个时候又没人管，那这个时候就会造成很大的损失，所以我们可以使用它的自动版–哨兵机制！在没人的时候它也可以从剩下的机器中选取一台主机继续使用。

使用步骤

第一步：

调整结构，将我们修改过的 redis 主从关系调整一下，换回之前的 6379 为主 6380 和 6381 为从。

第二步：

自定义的 /myredis 目录下新建 sentinel.conf文件，名字绝不能错！

-- 创建文件
touch sentinel.conf

在这里插入图片描述

第三步：

配置哨兵，填写内容

-- 打开 sentinel.conf 文件
vim sentinel.conf

-- 添加内容
sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379 1

在这里插入图片描述

上面最后一个数字 1，表示主机挂掉后 salve 投票看让谁接替成为主机，得票数多少后成为主机！

第四步：

启动哨兵

redis-sentinel /myredis/sentinel.conf

在这里插入图片描述

注：上述目录依照各自的实际情况配置，可能目录不同

接下来我们来看一下在哨兵模式下主机崩掉的效果

正常的状态

在这里插入图片描述

我们把6379redis给关掉，制造出服务器崩坏的效果

在这里插入图片描述

在来看刚才的sentinel.conf文件

在这里插入图片描述

因为主redis突然崩了，所以大家投票决定由6381作为新的主redis进行使用

在这里插入图片描述

我们使用 info replication 查看会更加的明显，这里可以直接看到，6381已经变成了master，而6380成为了6381的从redis。

接下来我们在来看一下如果后面6379有恢复了会是什么效果！

在这里插入图片描述

我们可以看到6379自动绑定到了6381，这是类似于一个老领导退休后又回来看看，但是现在已经有新领导了，所以老领导来了也得听新领导的！

PS：一组sentinel能同时监控多个Master

复制的缺点

复制延迟：

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

如果大家在测试的时候没有效果，那么可以暂时等一下，因为可能是因为延迟的原因!

扩展

Redis的发布订阅

介绍

进程间的一种消息通信模式：发送者（pub）发送消息，订阅者（sub）接收消息。

订阅/发布消息图

在这里插入图片描述

例：我们使用微信的时候会关注一些公众号，在我们关注之后公众号就会给我们推送一些相关信息，而我们没有关注的时候它是不会给我们发的！

命令

在这里插入图片描述

案例

先订阅后发布后才能收到消息

可以一次性订阅多个，SUBSCRIBE c1 c2 c3
消息发布，PUBLISH c2 hello-redis

在订阅对应的频道之后，只要该频道发布新的信息，订阅的机器就可以获取到发布的信息，但是没有订阅的机器就接收不到发布的信息。
订阅多个，通配符， PSUBSCRIBE new

这里的 new 并不是固定的，大家也可以改成其他的，比如a、b、c之类的，但是一定要加上后面的 * 号！
收取消息， PUBLISH new1 redis2020

在发布的时候需要根据刚才订阅的格式进行发布，否则就不会获取到信息！

风城烟雨丶

关注

1
点赞
踩
1

收藏

觉得还不错? 一键收藏
1
评论
Redis主从复制

Redis复制 — Master/Slave介绍能干嘛如何使用修改配置文件细节操作常用三招一主二仆薪火相传反客为主复制原理哨兵机制使用步骤复制的缺点扩展Redis的发布订阅介绍命令案例介绍       Redis复制也就是我们所说的主从复制，主机数据更新后根据配置和策略，自动同步到备机的 master/slaver 机制，Master 以写为主，Slave 以读为主。能干嘛读写分离容灾恢复…如何使用口诀：配
复制链接

扫一扫

专栏目录