Redis数据持久化、数据备份、数据的故障恢复

时间:2019-07-20 来源:www.ican-cintest.com

1.Redis持久性的意义---- redis故障恢复

在实际的生产环境中,redis很可能突然挂起。例如,redis过程死亡,电缆由施工团队挖掘(支付宝示例)等。简而言之,它将遇到各种奇妙的现象。导致redis死机,这次放在redis内存中的所有数据都会丢失,这个数据可能会服务很多系统或服务,当然我们可以重启redis,重启后,如果redis不是持久的,redis中的数据呢将全部丢失。

如果通过持久性将数据持久保存到磁盘,然后定期同步并备份到云存储服务,则可以保证数据不会丢失或者您可以恢复某些数据。

2.持久性的两个主要机制(RDB和AOF)

RDB:对redis数据执行定期持久性

AOF:将每个命令写入日志,并以仅追加模式将其写入日志文件。重新启动redis时,可以通过回放AOF写入命令重建整个数据集。

它是否对持久性有用取决于具体的业务场景:

如果您只想让redis充当纯内存缓存,则可以禁用RDB和AOF。

失败恢复的一般想法:

通过RDB或AOF,redis内存中的数据可以持久保存到磁盘,然后数据可以备份到阿里云。如果redis挂起,服务器中的内存和磁盘数据将丢失。这时,阿里可以使用。将云中的备份文件复制到指定目录,然后重新启动redis。 Redis将根据持久数据文件自动恢复内存中的数据并继续提供服务。如果室友同时具有RDB和AOF持久性机制,建议在重启时使用AOF重建数据,因为AOF中的数据更完整。

3. RDB和AOF的剖析

RDB:早上7点,redis中有500个数据。此时,redis将在一定时间内生成RDB快照文件。当它达到9:00时,redis中有8000个数据。这时,它是在一定时期内。生成另一个RDB快照文件,即RDB持久性机制。

AOF:每次用redis写入指令时,它都会更新为磁盘上的文件。但是,在现代操作系统中,写入文件并不是直接写入磁盘,而是首先将其写入os缓存,然后在一定时间内从os缓存刷入磁盘文件。对于AOF,它每秒调用一次(可配置)。系统饥饿的fsync操作强制将os缓存中的数据刷新到磁盘文件中。但是,redis内存中的数据并没有无限增长。它是根据LRU算法定期清理一些不可用的数据,以确保AOF不会无限增长,但是如果LRU的清洁速度不如AOF的膨胀速度快。此时,当AOF足够大时,将执行AOF重写操作。 AOF重写操作根据当时redis内存中的数据重建较小的AOF文件,然后删除旧的AOF文件。

简而言之,假设redis只能存储10G数据。此时,数据以redis连续写入。当数据量为10G时,根据LRU,这次清除了一些不可用的数据,并清理了5G。这时,我写了5G。此时,AOF文件记录15G数据相关的写命令。如果AOF此时已经扩展,则redis执行AOF重写操作并重新生成新的10G数据命令。 AOF文件,此时会继续写新的AOF文件,删除旧的AOF文件。

4. RDB和AOF的优缺点

RDB优势

(1)。 RDB将生成多个数据文件,每个文件在某个时刻代表redis数据。这种多数据文件的方式非常适合冷备用,可以使用这个完整的数据文件。将其发送到某些远程安全存储,例如阿里云的ODPS分布式存储,并使用预定的备份策略定期备份redis中的数据。

RDB执行冷备用并生成多个文件,每个文件代表特定时间的完整数据快照。

AOF也可以用作冷备用,只能用作一个文件,但您可以定期复制此文件的副本

但是,RDB更适合冷备用。它的优点是redis更方便控制生成快照文件的固定时间。 AOF,你需要编写一些脚本来自己做,你需要编写自己的时序脚本,并完成RDB数据。冷备用,在最坏的情况下,当提供数据恢复时,速度快于AOF

(2)。 RDB对Redis的外部读写服务的影响非常小,这可以使redis保持高性能,因为redis主进程只需要派生子进程,让子进程执行RDB持久性的磁盘IO操作。

RDB,每次写入,直接写入redis内存,只是在某个时间将数据写入磁盘

AOF,每次你想写一个文件,虽然你可以快速写入os缓存,但是仍然有一定的时间开销,速度肯定比RDB慢一点

(3)相对于AOF持久化机制,直接基于RDB数据文件重启和恢复redis进程更快

RDB缺点

(1)。如果你想在redis失败期间尽可能少地丢失数据,那么RDB没有AOF。通常,RDB数据快照文件每5分钟或更长时间生成一次。此时,一旦redis进程关闭,最后5分钟的数据将丢失。这是rdb的最大缺点。它不适合第一优先级恢复解决方案。如果您依赖RDB作为第一优先级恢复解决方案,则会导致更多数据丢失。

(2)。每次RDB在fork子进程中执行RDB快照数据文件时,如果数据文件特别大,可能会导致客户端提供的服务暂停几毫秒甚至几秒钟,所以一般不会让RDB间隔太长,否则生成的RDB文件太大,这可能会影响redis本身的性能。

AOF优势

(1)。 AOF可以更好地保护数据免受损失。通常,AOF将每1秒通过后台线程执行fsync操作,并丢失最多1秒的数据。每1秒执行一次fsync操作。确保os缓存中的数据写入磁盘。 redis进程挂起并丢弃最多1秒的数据。

(2)。 AOF日志文件是以append-only模式编写的,因此没有磁盘寻址的开销,写入性能非常高,并且文件不容易被破坏,即使文件的尾部坏了,也很容易修理。

(3)。如果AOF日志文件太大,则后台重写操作不会影响客户端的读写操作。由于将重写压缩重写日志的内容,因此请创建需要还原的最小日志。创建新日志文件时,仍会像往常一样编写旧日志文件。当新的合并日志文件准备就绪时,交换旧的和新的日志文件。

(4)。 AOF日志文件的命令以可读的方式记录。此功能非常适用于灾难性意外删除的紧急恢复。例如,某人使用flushall命令意外清空所有数据。只要此时没有发生后台重写,您可以立即复制AOF文件,删除最后一个flushall命令,然后重新放回AOF文件。通过恢复机制自动恢复所有数据

AOF缺点

(1)。对于相同的数据,AOF日志文件通常大于RDB数据快照文件

(2)。打开AOF后,支持的写入QPS将低于RDB支持的写入QPS,因为AOF通常配置为每秒fsync一个日志文件。当然,fsync每秒一次,性能还是很高的,如果要确保一块数据不丢失,也有可能,AOF的fsync被设置为不写一段数据,fsync一次,那么它是完成后,redis QPS下降了。

(3)。在AOF出现错误之前,这是AOF记录的日志。恢复数据后,未恢复相同的数据。因此,像AOF这样更复杂的基于命令/合并/回放的方法每次都比基于RDB的完整数据快照文件持久性更容易受到攻击和漏洞。但是,AOF是为了避免重写过程造成的错误。因此,每次重写都不是基于旧的指令日志,它是基于当时内存中的数据,因此鲁棒性会好得多。

(4)。唯一的大缺点是,当涉及到数据恢复时,它会更慢,并且它将是冷备用,定期备份,不是很方便。您可能必须编写一个复杂的脚本来自己完成。不适合

AOF和RDB数据恢复机制

AOF,存储的命令日志,在进行数据恢复时,它实际上是回放并执行所有命令日志来恢复内存中的所有数据

RDB是一个数据文件,可以在恢复时直接加载到内存中。

AOF和RDB都作为redis中的文件存在!

5.如何选择RDB和AOF

(1)。不要只使用RDB,因为这会导致您丢失大量数据

(2)。不要只使用AOF,因为有两个问题。首先,你通过AOF做冷待机。如果您没有RDB进行冷备用,则恢复速度会更快。其次,RDB以简单粗暴的方式生成数据。快照更强大,可以避免AOF的错误,这是一种复杂的备份和恢复机制

(3)。综合运用AOF和RDB两种持久化机制,利用AOF保证数据不丢失,成为数据恢复的首选;使用RDB执行不同级别的冷备用,AOF文件丢失或损坏不可用您还可以使用RDB进行快速数据恢复

6.如何配置RDB持久性

(1).redis.conf文件,即/etc/redis/6379.conf,用于配置持久性

例如:保存60 1000

(每隔60秒,如果更改了1000多个密钥,则会生成一个新的dump.rdb文件,这是当前redis内存中的完整数据快照。此操作也称为快照,快照

您也可以手动调用save或bgsave命令同步或异步执行rdb快照生成。

(2).save可以设置为多个,即多个快照检查点。每次到达检查点时,它都会检查指定的键数是否有变化。如果是,则生成新的dump.rdb。文件

7. RDB持久性机制的工作流程

(1)。 Redis尝试根据配置生成rdb快照文件。 fork一个子进程出来了。子进程尝试将数据转储到临时rdb快照文件。生成rdb快照文件后,将替换旧快照。每次生成新快照时,文件dump.rdb都将覆盖旧快照。

8.基于RDB持久化机制的数据恢复实验

(1)。在redis中保存一些数据,立即停止redis进程,然后重新启动redis,查看刚插入的数据是否仍在那里

(2)。在redis中保存一些新数据,用kill -9杀死redis进程,模拟redis故障异常退出,导致内存数据丢失情况

注意:Redis-cli SHUTDOWN停止redis实际上是一种安全的退出模式。 Redis将在退出时立即生成完整的rdb快照。

9.如何配置AOF持久性

(1).AOF持久化,默认为关闭,默认是打开RDB持久性

(2).dpendonly是的,你可以打开AOF持久化机制,在生产环境中,一般AOF都是打开的,除非你说只扔几分钟的数据没关系,打开AOF持久化机制,redis每次一个收到write命令后,它将被写入日志文件。当然,它首先写入os缓存,然后定期写入fsync,即使启用了AOF和RDB,重启时也首选redis。通过AOF恢复数据,因为数据相对完整

(3)。您可以配置AOF的fsync策略。有三种策略可供选择。一种是每次写一个数据时执行fsync;另一种是每秒执行fsync;一种是不主动执行fsync

总是:每次写一段数据,立即将这个数据的相应日志写入磁盘,性能很差,吞吐量很低;为了确保redis中的数据不会丢失,它只能像这样

Everysec:每秒将os缓存中的数据转换为磁盘。这是最常见的生产环境,而且性能非常高。 QPS仍然可以达到数万。

否:只有redis负责将数据写入操作系统缓存,因此我将其留在后面,然后我将有自己的策略将数据不时刷新到磁盘中,这是不可控制的

10.AOF持续数据恢复实验

(1)。首先打开RDB,写一些数据,然后kill -9来杀死redis进程,然后重启redis,发现数据已经消失,因为还没有生成RDB快照

(2)。打开AOF开关以启用AOF持久性

(3)。写一些数据并观察AOF文件中的日志内容

(4).kill -9 kill redis进程,重启redis进程,发现数据被恢复回来,从AOF文件中恢复(当redis进程启动时,它将直接从appendonly.aof加载所有日志,恢复数据在记忆中回来)

注意:在appendonly.aof文件中,你可以看到刚刚写入的日志,它们实际上是先写入os缓存,然后是1秒后fsync到磁盘,只有fsync到磁盘,这是安全的,否则,它是在os缓存中,机器刚刚重启,没有任何东西消失

11.AOF重写

AOF如何运作

(1).redis fork一个子进程

(2)子进程基于当前的内存数据构建日志并开始写入新的临时AOF文件

(3)redis的主要过程。在接收到客户端的新写入操作后,内存中的数据继续写入到AOF文件的新日志中,新数据继续写入旧的AOF文件。

(4)redis的主要进程再次将新写入的内存日志添加到新的AOF文件中

(5)。用新的日志文件替换旧的日志文件

redis中的数据实际上是有限的。许多数据可能会自动失效。它可能会被用户删除。它可以通过redis清除缓存清除算法。 redis中的数据将从旧数据中删除。一些常用数据将被删除。它会自动保存在redis内存中,因此可能会有大量数据在之前被清除,并且相应的写入日志仍然保留在AOF中。 AOF日志文件是一个,它会继续扩展,它非常大,所以AOF会在后台定期自动进行重写操作,比如日志已存储为100w数据写入日志; redis内存仅剩10万;根据当前内存中的100,000个数据构建一组最新的日志,到AOF Medium;之前覆盖旧日志;确保AOF日志文件不会太大,保留与redis内存相同数量的数据

在redis 2.4之前,你需要手动开发一些脚本,crontab,并通过BGREWRITEAOF命令执行AOF重写,但是在redis 2.4之后,它会自动重写操作

注意:

在redis.conf中,您可以配置重写策略

自动重写百分比100

Auto-aof-rewrite-min-size 64mb

例如,在最后一次AOF重写之后,它是128mb,然后它将继续在128mb之后写入AOF日志。如果发现增长的比例,它超过了之前的100%,即256mb,它可能会触发重写,但这次也是最小尺寸,64mb比较,256mb> 64mb,将触发重写

12.修复AOF损坏的文件

如果附加数据到达AOF文件时redis已关闭,则AOF文件可能已损坏。使用redis-check-aof --fix命令修复损坏的AOF文件。

13.AOF和RDB同时工作

(1)。如果RDB正在执行快照操作,则redis不会执行AOF重写;如果redis执行AOF重写,则不会执行RDB快照

(2)。如果RDB正在执行快照,并且用户执行BGREWRITEAOF命令,则在生成RDB快照后将执行AOF重写。

(3)。有RDB快照文件和AOF日志文件。重新启动redis时,AOF将用于数据恢复,因为日志更完整

14.企业级持久性配置策略

在企业中,RDB生成策略几乎与默认

相同

保存60 10000:如果要确保RDB丢失最多1分钟的数据,请尝试每1分钟生成一次快照。高峰期,数据量很小,没有必要

AOF必须是开放的,fsync,everysec

自动重写百分比100:是当前AOF大小膨胀超过最后100%,最后两次

Auto-aof-rewrite-min-size 64mb:根据你拥有的数据量,16mb,32mb

15.企业级数据备份解决方案

(1)。编写crontab计时调度脚本来做数据备份

(2)。每小时复制一份rdb,转到一个目录,只保留最后48小时的备份

(3)。每天保留当天rdb的备份,转到目录,只保留上个月的备份

(4)。每次复制备份时,都要删除太旧的备份

(5)。每晚备份当前服务器上的所有数据,并将副本发送到远程云服务

按小时和按日备份

每小时复制一次,48小时前删除数据

Crontab -e

0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh

Redis_rdb_copy_hourly.sh

#!/bin/sh的

Cur_date=`date +%Y%m%d%k`

Rm -rf/usr/local/redis/snapshotting/$ cur_date

Mkdir/usr/local/redis/snapshotting/$ cur_date

Cp /var/redis/6379/dump.rdb/usr/local/redis/snapshotting/$ cur_date

Del_date=`date -d -48hour +%Y%m%d%k`

Rm -rf/usr/local/redis/snapshotting/$ del_date

每天复制一次备份

Crontab -e

0 0 * * * sh /usr/local/redis/copy/redis_rdb_copy_daily.sh

Redis_rdb_copy_daily.sh

#!/bin/sh的

Cur_date=`date +%Y%m%d`

Rm -rf/usr/local/redis/snapshotting/$ cur_date

Mkdir/usr/local/redis/snapshotting/$ cur_date

Cp /var/redis/6379/dump.rdb/usr/local/redis/snapshotting/$ cur_date

Del_date=`date -d -1month +%Y%m%d`

Rm -rf/usr/local/redis/snapshotting/$ del_date

每天将所有数据上传到远程云服务器

16.企业数据恢复解决方案

(1)。如果redis进程挂起,请重新启动Redis进程并根据AOF日志文件直接还原数据

(2)。如果redis进程所在的计算机挂起,请重新启动计算机,尝试重新启动redis进程,尝试直接根据AOF日志文件恢复数据,前提是AOF没有损坏,AOF仅附加,顺序写入,如果AOF文件坏了,那么用redis-check-aof修复它。

(3)。如果Redis的最新AOF和RDB文件丢失/损坏,您可以尝试根据计算机上最新RDB数据的当前副本恢复数据。缺少最新的AOF和RDB文件。 /损坏无法恢复,一般不是机器故障,而是人为的。

17.灾难恢复演习

Appendonly.aof + dump.rdb,使用appendonly.aof首先恢复数据。

(1)。如果关闭AOF持久性机制,并且dump.rdb有数据,则此时重新启动Redis,很明显内存中没有恢复数据。

原因:当redis启动时,它会自动重新基于内存的数据,并直接使用空数据生成一个新的rdb快照,覆盖dump.rdb我们有数据

(2)。如果打开AOF,在停止redis之后,删除appendonly.aof,然后复制我们的dump.rdb,然后重新启动redis,并发现仍然没有数据恢复

原因:虽然你删除了appendonly.aof,但由于aof持久性,redis肯定会基于aof恢复,即使文件不是,也要创建一个新的空aof文件

(3)。停止redis,暂时关闭配置中的aof,然后复制rdb,然后重启redis,这次内存中的数据恢复成功;如果你不小心,那么关闭redis,手动修改配置文件,打开aof然后重启Redis,数据消失了,因为它是一个空的aof文件,所以所有数据都消失了。

在数据安全丢失的情况下,基于rdb冷备,如何完美恢复数据,同时仍保持aof和rdb的双重打开?

(4)。停止redis,关闭aof,复制rdb备份,重启redis,确认数据恢复,直接修改命令行上的redis配置,打开aof,这个redis会在内存中写入相应的数据日志,写一个aof文件在这种情况下, aof和rdb的两个数据文件的数据是同步的。

注意:redis config设置热修改配置参数,配置文件中的实际参数可能不会被持久修改,再次停止redis,手动修改配置文件,打开aof命令,再次重启redis

(5)。如果当前计算机上的所有RDB文件都已损坏,则从远程云服务中提取最新的RDB快照以恢复数据

(6)。如果发现存在重大数据错误,例如一次性污染数据并且数据完全错误的每小时程序,则可以选择较早的时间点来恢复数据。 p>

例如,12行代码,发现代码有一个bug,导致代码生成的所有缓存数据,写redis,都错了,找到一个11点的rdb冷备用,然后按照上面的说法步骤,去恢复到11点数据。