redis的备份

redis的备份功能使用非常简单。配置一个主从式备份机制使得redis的从服务器与主服务器完全一样。以下是对redis备份非常重要的描述。
redis使用异步备份。从2.8版本开始，从站会周期性地从备份流中接收一定量的数据。

• 主站可以有多个从站。
• 从站能够接收来自其它从站的连接请求。除了连接多个从站到同一个主站，从站还可以连接到其它从站，形成一个图状结构。
• redis备份在主站端是非阻塞的。这就意味着当有从站在执行初始同步时，主站仍可以继续处理请求。
• 在从站端也是非阻塞的。当从站在执行初始同步时，它仍然可以使用旧版本的数据集处理请求，只要你在redis.conf中这样配置过。相反，你也可以这样配置从站，在备份流停止时向客户端返回一个错误。然而，初始同步之后，旧的数据集必须被删除，新的数据集必须被加载。在这段时间，从站会阻塞接下来的连接请求。
• 备份既可以用于扩展，使多个从站都可以处理只读类型的请求（例如，耗时的SORT操作可以离线地分给多个从站），也可用于数据冗余。
• 可以通过备份来避免因为主站把所有数据写到硬盘带来的开销：只需要配置主站的redis.conf文件去掉保存操作（把所有的SAVE指令注释掉），然后连上一个配置成定时保存的从站。要使用这种配置，必须保证主站不会自动重启（请阅读下一节获取更多信息）

主站关闭持久化时备份的安全性

在使用redis备份的配置中，强烈建议在主站上开启持久化。如果因为类似于潜在顾虑等原因不允许开启持久化，那么主站应该配置成避免自动重启。
想要更好地理解为什么不开启持久化的主站配置成自动重启是危险的，请阅读以下失败的模型。在这些模型中，主站和它所有的从站上 的数据都被清除了：

1. 我们配置一个节点A作为主站，关闭它的持久化，而节点B和C是节点A的备份。
2. A崩溃了。因为A配置成了自动重启的系统，A的进程重启了。然而由于持久化是关闭的，所有的节点重启时数据集是空的。
3. 节点B和C会从A备份，但A是空的，所以它们会删除它们的数据副本。

即使Redis的 Sentinel具有高可用性，关闭主站上的持久化，并允许进程的自动重启，也是危险的。例如如果主站重启太快，以至于Sentinel还来不及检测到错误，那么上面错误模型描述的情形也会发生了。
数据安全永远是重要的，在备份情况下，要禁止把主站配置成没有持久化且允许实例重启的配置。

redis的备份是怎样工作的？

当你配置了一个从站，它会基于连接发送一个SYNC命令。它并不关心这是它第一次连接或是一次重连。
然后主站开始保存环境，并将所有新收到的会改变数据集的命令放入缓冲区。背景保存完成后，主站将数据库文件迁移到从站，然后加载到内存。从站则把数据库文件保存到硬盘。主站会把所有缓冲区的命令发送给从站。这通过一个命令流来完成，格式与redis本身的协议相同。
你可以通过telnet实验。将telnet连接到redis的端口，同时让服务器做一些工作，然后执行SYNC命令。你会看到一个大块数据的传输，所有主站收到的命令都会在telnet会话上重新执行。
当主站与从站之间的链接由于某种原因挂掉时，从站会自动重连。如果主站收到多条当前从站的同步请求，它会执行一个背景保存来处理所有的请求。
连接挂掉后主站与从站重连时，通常会执行一个全部的同步。然而从redis2.8版本开始，部分同步也是可以的。

部分同步

从2.8版本开始，当备份挂掉时，主站和从站通常能够继续备份而不需要一个完整同步。
通过在主站中创建一个用于存储备份流的内存块就可以实现这一点。主站和所有从站在备份偏移和主站的运行ID上达成共识。因此当链接挂掉，从站会重连并请求主站继续备份。如果主站的运行ID保持不变，且偏移在备份内存块上仍然可用，那么备份会从挂掉的那个点恢复。如果其中任意一个条件不满足，就会执行完整的同步（这是2.8版本以前是正常行为）。由于所连接的主站的运行ID并不存储在实例的硬盘上，从站重启时需要完整同步。
部分同步这个新特性在内部使用PSYNC命令，而旧的实现使用SYNC命令。需要注意的是，2.8版本的从站能够检测它所连接的服务器是否支持PSYNC，如果不支持，则使用SYNC。

无硬盘的备份

通常情况下，一个完整的备份需要在硬盘上创建一个RDB文件，然后从硬盘加载这个RDB文件用于给从站发数据。
由于硬盘低速，这对于主站来说是一个很有压力的操作。2.8.18版本是第一个尝试支持无硬盘备份的版本。在这种配置中子进程直接通过网线把RDB文件发给从站，而不需要硬盘作为中间存储。
这个特性目录还是试验性的。

配置

要配置备份很简单，只需要增加以下这一行到从站的配置文件中
slaveof 192.168.1.1 6379
当然你要把192.168.1.1 6379替换成你的主站IP地址（或主机名）和端口。同样，你也可以调用SLAVEOF命令，主站就会开始与这个从站同步。
还有一些参数用于协调主站从内存中获取的备份内存块来执行部分同步。请查阅redis版本中自带的redis.fonf中的例子获取更多的信息。
无硬盘备份可以通过repl-diskless-sync参数开启。延迟开始转移数据是为了等待更多的从站到达，延迟功能通过repl-diskless-sync-delay参数开启。请查阅redis版本中自带的redis.conf中的例子获取更多的信息。

只读的从站

从redis的2.6版本开始，从站支持设置为只读功能，而且是默认开启的。这个行为由redis.conf文件中的slave-read-only选项控制，也能够通过CONFIG SET命令在运行时间开启或关闭。
只读从站会拒绝所有写命令，所以不可能向一个从站写入，因为这样会返回一个错误。这并不是说这个特性是为了让一个从站实例暴露到网络中或者在一个不受信任的网络中给客户端使用，因为像DEBUG或CONFIG这样的管理命令仍然可用。然而，只读实例的安全性可能通过禁用这些命令来实现，需要在redis.conf文件中使用rename-command指令。
你可能会奇怪，为什么可以还原只读设置，使从站实例能够成为写操作的目标。但是如果从站和主站同步或者从站重启，这些写入会被丢弃。只是允许一些合理的向可写从站存储临时数据的用例。以后这个特性可能会被去除。

配置一个可向主站认证的从站

如果你的主站需要密码来处理请求，就要配置从站在所有的同步操作中使用这个密码。
要在一个运行中的实例上实现这一点，在redis客户端上输入：

config set masterauth <password>

想要永久地设置，把它加入到你的配置文件

masterauth <password>

有N个连接的备份时才允许写入

从redis的2.8版本开始可以这样配置，只有在至少N个从站连接到主站时才允许redis主站接受写请求。
然后由于redis使用异步备份，不可能保证从站真正地接收一个给定的写操作，因此常常会有一个窗口的数据丢失。
这个特性是这样工作的：

• redis从站每秒ping一次主站，以告知主站备份流的处理进度。
• reids主站会记录每个从站上一次发来的ping命令。
• 用户可以配置从站的最小数量值，以及从站ping命令时间间隙不可以超过最大秒数。

如果至少有N个从站，且时间间隙少于M秒，就可以接受写操作。
你可以把它看作CAP理论的一个“C”的松弛版本，对于一个给定的写入，一致性不可能保证，但至少可以保证数据丢失的数量严格控制在给定的数秒内。
如果条件不满足，主站就会回复一个错误而写入则不接受。
有两个配置参数可以用于这个特性：

min-slaves-to-write < number of slaves> min-slaves-max-lag < number of seconds>

要获取更多的信息，请查阅redis版本中自带的redis.fonf中的例子。