概述

Redis主从复制使用和配置Master-Slave主从都非常简单,它可让Redis Slave成为Master的准确的副本。下面是关于Redis主从复制的一些重要事实。

  • Redis 使用异步复制。从2.8开始,不管怎样,Slave会周期性的从Master复制流确认处理的数据量。
  • 一个master可以有多个salve。
  • slave能够接受来自其他slave的连接。除了连接若干个slave到相同的master,slave还可以连接其他的slave。
  • Redis主从复制在master端是非阻塞的,这意味着当一个或多个slave在执行初始化同步时,master会继续处理请求。
  • 主从复制在slave端也是非阻塞的。当slave正在初始化同步的时候,它可以使用旧版本的数据集处理查询,假如你在redis.conf配置文件里做了这样的配置。  另外,你可以配置如果主从复制流停掉,返回一个error的客户端。然而,初始化同步之后,必须删除旧数据集并加载新的数据集。slave会在这个短暂的期间拒绝进来的连接。
  • 主从复制可以用它的扩展性,以便多个slave用于只读查询,或者简单的数据冗余或备份。
  • 也有可能避免master将完整的数据集写入到磁盘的成本:仅仅配置你的master redis.conf避免保存,然后连接到slave不时地进行保存。不管怎样在这一步确保master不会自动重启。

当master关闭时主从复制的安全性

在使用主从复制设置那里,强烈建议在master里开启持久化,或者当由于例如延迟问题不能这样设置的时候,实例应该配置成避免自动重启。

为了更好的理解为什么关闭持久化自动重启非常危险,检查下面的故障模式数据从master和它所有的slave中被抹去。

  1. 我们有一个设置节点A为master,关闭持久化,节点B和C从A复制。
  2. 一个事故,然而它有一些自动重启系统,重启进程。然而因为持久化是关闭的,节点重启时数据集是空的。
  3. 节点B和C从A同步数据,而它是空的,所以他们会摧毁数据的副本。

当Redis哨兵为了高可用,关闭master的持久化,并自动重启进程,是非常危险的。例如master启动的足够快,快于哨兵的检测故障的速度,所以上面描述的故障就会发生。

Redis 主从复制是怎样工作的

如果你建立了一个slave,通过连接发送一个SYNC命令。如果是第一次连接或重新连接都无所谓。

然后master开始后台的存储,并开始缓存所有接受到的改变数据集的新命令。当后台存储完成时,master传输数据文件到slave,保存数据文件到硬盘,然后加载到内存中。master将所有缓存的命令发送到slave。这是作为一连串命令完成的并且是Redis协议自己一样的格式。

你可以通过telnet自己试试。当服务器正在做一些工作时连接到Redis端口并发出SYNC命令。你将会看到一个批量传输然后每个通过master接收到的命令将会在telnet会话里重新发出。

当master-slave连接损坏时,Slave可以自动重新连接。如果master接收到多个并发的slave同步请求,它执行一个单独的后台存储以便为所有的slave提供服务。

当连接断开之后master和slave重新连接时,总是会执行一个全量的同步。然而从Redis2.8开始,局部的同步也是可能的。

局部再同步

从Redis2.8开始,master和slave在断开复制连接之后通常能够继续复制进程而不需要一个全量的同步。

这个工作通过在master端创建一个复制流的内存日志。master和所有的slave商定replication offset和一个master runid,所以当连接断开,slave重新连接并请求master继续同步。假如master run id一直相同,并且在复制日志里指定的offset可用,复制将从它离开的位置重新开始。如果这个两个条件有一个不满足,就会执行一个全量的再同步。由于连接到的master的run id没有持久化到硬盘,当slave重启时就需要一个全量的再同步。

新的局部再同步功能在内部使用PSYNC命令,因为老的实现使用SYNC命令。注意Redis2.8 salve可以检测它通讯的server是否支持PSYNC,并替换使用SYNC。

无磁盘复制

通常,一个全量再同步会请求在磁盘上创建一个RDB文件,然后从磁盘加载RDB文件以便于供给slave数据。

对于master来说如果是慢硬盘这可能是一个非常加压的操作。Redis版本2.8.18是对无磁盘复制实验支持的第一个版本。在这个步骤子任务直接向slave发送RDB文件,不使用硬盘作为中间存储器。

这个功能当前还是实验性的。

配置

配置主从复制非常简单:仅仅添加下面的一行配置到slave配置文件:

slaveof 192.168.1.1 6379

当然你需用用你的master ip地址和端口替换192.168.1.1 6379。或者,你可以调用SLAVE命令,master将会开启一个slave的同步。

还有一些参数优化内存中的复制日志通过master执行局部再同步。查看Redis发布包里附带的redis.conf示例了解更多信息。

可以使用 repl-diskless-sync配置参数开启无磁盘复制。延迟传输以便于等待更多的slave在第一个之后到达,通过repl-diskless-sync-delay参数控制。请参考Redis发布包里的redis.conf示例文件了解更详细内容。

只读的slave

从Redis2.6开始,slaves支持只读模式并在默认状态下启用。这个特性通过redis.conf文件的slave-read-only选项控制。并可以在运行时使用CONFIG SET命令启用和禁用。

只读的slave将拒绝所有的写入命令,以至于不能写到slave。这并不意味着这个功能打算为不信任的客户端暴露slave实例到internet或network,因为管理命令像DEBUG或CONFIG一直可用。然而,只读实例的安全性可以通过在redis.conf文件里使用rename-command指令禁用命令提高。

你可能会感到困惑为什么可以恢复只读设置且有slave实例可以作为写入操作的目标。而那些操作会被丢弃如果slave和master再同步或如果slave重启,有些合法的用例用于在可写入的slave里存储临时数据。然而在将来有可能会删掉这个功能。

设置slave到master的身份验证

如果你的master通过requirepass设置了密码。配置slave在所有的同步操作里使用密码非常简单。

在运行的实例上使用redis-cli并输入:

config set masterauth [密码]

为了永久的设置它,在你的配置文件里添加:

masterauth [密码]

只在有N个连接的副本时允许写入

从Redis2.8开始,可以配置Redis master只在至少N个slave连接到master的时候接受写入请求。

然而,由于Redis使用异步复制不可能确保slave真实的收到指定的写入,所以总有数据丢失的窗口。

这是这个功能如何工作的:

  1. Redis slave每隔一秒ping一次master,确认复制流处理的数量。
  2. Redis master记住从每个slave接收到的最后ping的时间。
  3. 用户可以配置一个最小数量的slave有一个滞后的不大于最大的秒数。

如果有至少N个slave,滞后小于M秒,然后写入将被接收。

你可以想象他为在分布式数据系统中的Cap原理的C的放松版本,对于一个指定的写入并不确保一致性。但是至少数据丢失是受指定秒数限制的。

如果条件不满足,master将返回一个错误并将拒绝写入。

对于这个功能有两个配置参数:

min-slaves-to-write [slave数量]
min-slaves-max-lag [秒数]

了解更多信息,请参考Redis源码发布包里附带的redis.conf示例。


原创文章,转载请注明出处:转载自Redis中文网 - Redis主从复制



最新文章

Redis最新文章

Redis最热文章