Loading

redis 主从复制

版权声明:本文为转载文章,博客原文地址:http://blog.csdn.net/a67474506?viewmode=contents

修改pidfile 为下面做准备

 

关闭RDB持久化修改持久化文件的保存位置

 

启动Redis

  1. redis-server /etc/redis.conf  

使用客户端连接Redis

  1. redis-cli  

 

连接成功,接下来就可以愉快的玩耍啦~~~

主从复制(读写分离)

redis的主从复制功能非常强大,一个master可以拥有多个slave,而一个slave又可以拥有多个slave,如此下去,形成了强大的多级服务器集群架构. 可以避免Redis单点故障,构建读写分离架构,满足读多写少的应用场景.

Redis复制功能的几个重要方面

1. 一个Master可以有多个Slave;
2. Redis使用异步复制。从2.8开始,Slave会周期性(每秒一次)发起一个Ack确认复制流(replication stream)被处理进度;
3. 不仅主服务器可以有从服务器,从服务器也可以有自己的从服务器,多个从服务器之间可以构成一个图状结构;
4. 复制在Master端是非阻塞模式的,这意味着即便是多个Slave执行首次同步时,Master依然可以提供查询服务;
5. 复制在Slave端也是非阻塞模式的:如果你在redis.conf做了设置,Slave在执行首次同步的时候仍可以使用旧数据集提供查询;你也可以配置为当Master与Slave失去联系时,让Slave返回客户端一个错误提示;
6. 当Slave要删掉旧的数据集,并重新加载新版数据时,Slave会阻塞连接请求(一般发生在与Master断开重连后的恢复阶段);
7. 复制功能可以单纯地用于数据冗余(dataredundancy),也可以通过让多个从服务器处理只读命令请求来提升扩展性(scalability):比如说,繁重的 SORT 命令可以交给附属节点去运行。
8. 可以通过修改Master端的redis.config来避免在Master端执行持久化操作(Save),由Slave端来执行持久化。

主从架构

 

准备3个配置文件端口分别为

6379 (Master)

6380 (Slave)

6381 (Slave)

  

修改原来的redis.conf文件 ,拷贝出2个redis.conf文件

[plain] view plain copy
 
  1. mv /etc/redis.conf /etc/redis.6379.conf  
  2. cp /etc/redis.6379.conf /etc/redis.6380.conf  
  3. cp /etc/redis.6379.conf /etc/redis.6381.conf  

通过vi修改6380 和 6381 配置文件

  1. vi /etc/redis.6380.conf  

通过命令替换 6379 为 6380

  1. :%s/6379/6380/g  

最底下出现 表示修改成功, wq退出并保存

 

用一样的方式修改6381 的配置文件

 

注意: 配置文件在前面已经修改pidfile 参数,如果没有修改一定要修改该参数为不同的值

 

通过配置文件启动3个Redis实例

通过ps 命令查看Redis进程

 

主从的配置有2种方法:

在redis.conf中设置 slaveof

 

使用redis-cli客户端连接到Redis服务中,执行slaveof命令

这种方式在重启之后就会失去主从复制关系

 

修改6381的配置文件 ,然后重启6381 .

通过redis-cli进入6379这个服务

 

查看主从信息:INFO replication

 

从库显示的信息

 

测试主从关系

在主库写入数据 ,然后在从库读取数据

主从从结构

 

主从从架构就是

Master下面有个 Slave , 而Slave下面还有一个Slave

我们吧 6381 重启一下

 

此时的主从信息

 

只剩下一主一从了

 

然后使用redis-cli客户端连接到Redis服务,执行slaveof命令

 

查看此时的主从信息

 

6379:

 

6379只有一个从库 6380

6380:

 

6380有一个主库 6379 还有一个从库 6381

6381:

 

6381只有一个主库 6380

 

这样主从从架构就搭建好了

 

测试 , 先清空key

 

在主库中设置数据

 

在从库中获取数据

 

6380 和 6381都已经获取到数据了

 

好了,主从从架构搭建完成!

从库只读

 

默认情况下redis数据库充当slave角色时是只读的不能进行写操作。

如果进行写操作就会报错

 

我们可以修改Redis的配置文件的配置参数slave-read-only, 修改为no

 

数据同步的过程

 

①  当从库和主库建立MS关系后,会向主数据库发送SYNC命令(同步命令);

 

②  主库接收到SYNC命令后会开始在后台保存快照(RDB持久化过程),并将期间接收到的写命令缓存起来;所以就算关掉了RDB持久化方式,在他们同步的时候也会产生RDB文件

 

以上主库只做了2件事情

           将接收的命令进行RDB持久化

           在RDB持久化中,将接收的命令缓存起来

①  当快照完成后,主Redis会将快照文件和所有缓存的写命令发送给从Redis;

 

②  从Redis接收到后,会载入快照文件并且执行收到的缓存的命令;

 

③  之后,主Redis每当接收到写命令时就会将命令发送从Redis,从而保证数据的一致;

 

在这个过程中主从同步是通过RDB来同步数据, 即使禁用了RDB也没有用,那么就会产生IO问题,在这个复制过程可能就会出现瓶颈. Redis在2.8.18版本开始实现了无磁盘复制功能

 

Redis在与从库进行复制初始化时将不会吧快照储存到磁盘,而是直接通过网络发送给从库,避免了IO性能问题.

 

修改repl-diskless-sync 为 yes

宕机处理

 

在主从架构中出现了宕机的情况

 

①  Slave 宕机

在Redis中,从库重新启动会自动加入到主从架构中,自动完成同步数据

Redis 2.8之后,在从库有做持久化的前提下,如果从库在断开的期间,主库的变化不大,从库再次启动后,主库不会将或有的数据进行RDB操作,而是进行增量复制

②  Master 宕机

一 : 在Slave中执行SLAVEOF NO ONE 命令,断开主从关系并且提升为主库继续服务;

二 : 将主库重新启动后,执行 SLAVEOF命令,将其设置为其他Redis的从库,这个时候数据就同步回来了;

 

 

这样通过人工的方式来处理Redis的宕机情况步骤虽然少,但是还是容易出现异常的,下面我们通过Redis的哨兵(sentinel)功能来实现高可用的架构

posted @ 2017-07-23 16:18  xwlmdd  阅读(210)  评论(0编辑  收藏  举报