红色系 网站,淄博网站制作服务优化,建筑培训,百度推广课程redis的持久化指将数据写入可靠内存中#xff0c;如ssd。Redis提供了4种持久化策略
RDB#xff1a;Redis Database#xff0c;周期性的将某个时间点的数据集快照持久化AOF#xff1a;Append Only File#xff0c;每次redis服务接收到写操作(修改内存的操作)#xff0c;都…redis的持久化指将数据写入可靠内存中如ssd。Redis提供了4种持久化策略
RDBRedis Database周期性的将某个时间点的数据集快照持久化AOFAppend Only File每次redis服务接收到写操作(修改内存的操作)都会将命令写入文件这些操作可以在redis重启后被重新执行来重建数据集。这些指令的存储格式和redis本身的协议相同。No persistence不进行持久化在某些缓存情况下使用。RDBAOF两种持久化策略可以组合使用。
RDB优点
RDB文件是一个紧凑的单个文件十分适合做备份。比如可以在24小时内每个小时都归档rdb文件并且在30天内每天都保存rdb快照这样在恢复的时候可以选择不同版本的数据。RDB适合做灾备恢复一个单个紧凑的文件很容易转储到其他数据中心或者存储在云平台上。RDB最大限度提升redis性能在持久化过程种redis主进程只需要fork一个子进程剩余的持久化工作都由子进程来完成主进程永远不会执行磁盘I/O等操作。相比于AOFRDB的重启恢复更快在主备模式下RDB支持重启和故障切换后的部分重新同步。
RDB的缺点
如果你想在redis故障的时候最小化数据丢失RDB不适合。你可以设置不同的保存点例如至少5分钟和100次写操作之后保存。但是通常我们的保存间隔不会太短所以redis宕机之后可能会丢失几分钟的数据。RDB会经常使用fork来创建子进程。如果数据集过大的话fork可能会占用较多时间。如果数据集较大且cpu性能不好的话可能会造成redis的短暂不可用。AOF也需要fork但是频率较低。
AOF优点
AOF更加可靠aof可以设置不同的fsync(刷盘)策略1.不刷盘缓冲区满自动刷盘2.每秒刷盘3.每次请求都刷盘。默认策略是每秒刷盘写入性能依旧很高。fsync是由后台线程进行的在未执行fsync的时候主线程会持续的执行写入因此最多丢失1秒的数据。AOF是追加日志文件因此不需要磁盘寻址断电等情况下也不会造成数据错乱。即使日志中最后保存的指令只写入了一半redis-check-aof也能修复。当AOF文件过大的时候redis会在后台自动重写AOF文件。AOF重写是完全安全的因为在创建新aof文件(根据当前数据集)的同时redis还会持续写入到旧文件一旦写入完成redis就会切换两个文件并开始在新文件上追加日志。AOF文件包含一条接一条的指令这些指令非常容易理解和解析也很容易导出。如果你不小心flushall了所有数据只要还没发生重写你就可以停掉redis并删除aof文件最后的flushall指令然后重启redis就可以恢复所有数据。
AOF缺点
AOF通常比RDB更大根据刷盘策略的不同AOF可能比RDB更慢。通常设置每秒刷盘的情况下性能依旧很高如果设置不刷盘则理论上和RDB一样快即使是在高负载下。但是RDB可以保证最大延迟。
如果redis版本7.0
AOF可能占用很多内存在重写时新的写入指令会保存在内存缓存中并在新文件创建完成后追加到末尾。重写期间所有的写入指令都会在磁盘上写入两次。redis可能会停止写入并将这些写入指令刷到新的aof文件中。
应该使用哪种
一般情况下如果你希望有PostgreSql一样的数据安全性的话你应该两种都使用。
如果你很关心你的数据但是可以忍受几分钟的数据丢失的话可以单独使用RDB。
很多用户单独使用AOF但是我们不建议这样做。因为用RDB做数据备份、快速启动恢复很好也可以防止AOF引擎出现错误。
快照
默认情况下RDB将数据集快照存储在磁盘上的dump.rdb文件中。你可以设置rdb在至少有M个key发生变化时每N秒保存一次或者可以使用save或bgsave命令手动调用保存。
例如这个命令表示如果至少有1000个key发生变化每60秒保存一次
save 60 1000实现原理
fork一个子进程子进程开始将数据写入到临时文件中当子进程完成新的rdb文件的写入后用新文件替换旧文件
这种方法可以让redis使用写时复制技术。 写时复制指的是对于一个文件对象不同的进程映射到虚拟地址空间的都是同一个物理内存只有某个进程试图修改数据时才会在物理内存中拷贝一份数据。 追加文件
快照并不是很可靠。如果你的redis服务停止了或者断电了或者你不小心杀掉了进程那么最近的数据就会丢失。虽然对某些应用来说问题不大但是有些应用缺不能接收所以单独使用RDB不得行。
AOF是一个完全可靠的持久化方案在1.1版本中推出。
你可以在配置文件中打开AOF
appendonly yes现在开始每次redis接收到一个写指令的时候都会追加到aof文件中。当你重启redis的时候就会重新执行aof文件来恢复到之前的状态。
从7.0开始redis使用多个aof文件机制。原来的一个aof文件会分割为一个base文件(最多一个)和incremental文件(增量文件可能有多个)。base文件代表重写时的最初的数据集快照增量文件保存了base文件创建之后追加的指令。这些文件分布在不同的目录下并且被manifest文件追踪。
日志重写
随着写操作的增加aof文件会越来越大。比如我们执行了100次的自增操作那么redis中只有一个key但是aof中有100条指令。其中99条都是无用的。
重写过程是绝对安全的。在重写时redis会持续写入旧文件并根据当前数据集创建一个最小指令的新文件。一旦新文件准备就绪redis就会切换两个文件并在开始在新文件后追加指令。
所以redis提供一个有趣的特性它能够在后台重写AOF而不中断对客户端的服务。当你执行bgrewriteaof命令时redis会根据当前数据集创建一个最小化的aof文件。如果你使用的是2.2版本那么你需要时不时的调用bgrewriteaof。从2.4开始redis会自动重写aof。
从7.0版本开始当AOF重写被调度的时候父进程会开启一个增量文件并将接下来的指令写入进去子进程会执行重写逻辑并生成一个新的base文件。redis会用临时的manifest文件来追踪新创建的base和增量文件。当这些文件准备好的时候redis会执行一个原子性的替换操作来让临时manifest文件生效。为了避免在AOF重写重复失败和重试时创建许多增量文件的问题Redis引入了AOF重写限制机制以确保以越来越慢的速度重试失败的AOF重写。
AOF的持久性
你可以设置fsync的策略有3种模式
always每次新指令追加到aof文件时都执行fsync。这种模式很慢也很安全。在从多个客户端或pipeline接收到一系列指令之后这写指令会追加到aof种这意味着只有一次写入和同步(在同步给副本之前)everysecond每秒同步一次。足够快在2.4版本之后可以与快照一样快你可能最多会丢失1秒的数据no从不fsync数据都交给操作系统处理。最快且最不安全的模式。正常情况下linux会30秒同步一次取决于内核
推荐的和默认的模式是每秒同步。速度和安全性都有保障。always策略在实践表现很慢但是支持分组提交redis会执行单次fsync。
如果AOF被truncate怎么办
这可能发生在重写时redis崩溃或者重写时aof文件所在的磁盘满了。当这种情况发生时AOF仍然包含表示数据集的给定时间点版本的一致数据使用默认AOF fsync策略该数据集可能早到一秒但AOF中的最后一个命令可能会被截断。Redis的最新主要版本无论如何都可以加载AOF只需丢弃文件中最后一个格式不正确的命令即可。在这种情况下服务器将发出如下日志
* Reading RDB preamble from AOF file...
* Reading the remaining AOF tail...
# !!! Warning: short read while loading the AOF file !!!
# !!! Truncating the AOF at offset 439 !!!
# AOF loaded anyway because aof-load-truncated is enabled如果AOF文件被破坏了怎么办
如果aof文件的字节序列在中间发生错误情况会比truncate更复杂。redis会在启动时报出
* Reading the remaining AOF tail...
# Bad file format reading the append only file: make a backup of your AOF file, then use ./redis-check-aof --fix filename最好的办法是运行redis-check-aof不使用–fix选项。然后分析问题找到给出的文件offset处并查看是否可以手动修复aof文件aof文件使用和redis一样的协议很容易理解和修复。否则可以让工具为我们修复但是这可能丢失从错误开始到文件结尾的部分如果错误发生在很靠前的位置可能丢失大量的数据。
实现原理
aof重写和快照一样使用了写时复制技术
7.0版本后
fork创建子进程子进程开始写入新的base文件到一个临时文件中父进程打开一个新的增量文件并将接下来的指令写入。如果重写失败则旧base旧增量新增量文件代表全部的数据因此是安全的。如果子进程重写完成父进程会接收到一个信号使用新打开的增量文件和子进程创建的base文件来构建一个临时的manifest文件并持久化。redis对manifest文件做一个原子性的替换操作新的aof文件生效。redis也会清理旧的base文件和用不到的增量文件。
7.0版本前
fork子进程子进程开始重写新的aof文件到临时文件父进程将接收到的指令写入内存缓冲区和旧的aof文件中如果重写失败的话数据也是安全的。当子进程重写完成父进程收到一个信号将缓冲区中的数据同步到新创建的aof文件中。redis原子性的将新文件重命名为旧文件并开始向新文件中追加指令。
如果我正在使用RDB快照如何切换到AOF
这个问题在2.2之前和之后的版本不一样可以理解为2.2版本之后更简单且完全不需要重启。
2.2版本后
创建一个dump.rdb文件的备份把这个备份保存到安全的地方执行下面的命令redis-cli config set appendonly yesredis-cli config set save “”确保数据库中的key数量和aof中的key数量相同确保新的指令正确的追加到aof文件中
第一条命令打开aof 第二条命令关闭快照持久化这个命令的是可选的如果你希望使用两种策略的话。 PS:不要忘记修改配置文件否则重启之后上面的配置会失效并依然使用旧的配置文件中的配置。
2.0版本
创建一个dump.rdb文件的备份把这个备份保存到安全的地方停止服务的所有写入指令执行redis-cli BGREWRITEAOF这回创建aof文件生成完aof文件后停止redis服务编辑redis.conf文件开启aof重启服务确保包含的key和修改前的一致确保新的指令正确的追加到aof文件中
RDB和APOF的影响
redis以后的版本会避免rdb执行期间触发aof重写或者在aof重写时使用bgsave保存rdb。这可以避免redis的后台进程执行过重的磁盘I/O。
当后台正在执行rbd快照保存用户明确使用bgrewriteaof指令时服务会返回ok告诉用户重写操作已加入调度一旦rdb完成就会立刻执行aof。
如果AOF和RDB都打开了redis重启时会使用aof来重新构建数据因为aof能保证数据更完整。
备份redis数据
redis的备份功能很友好因为redis运行时可以复制rdb文件:rdb一旦创建就不会再更改新的rdb会保存再临时文件里新的文件准备就绪时就会原子性的重命名为旧的文件名。
这意味这redis运行时复制rdb文件是安全的我们建议
创建一个定时任务每小时都保存一个rdb快照到一个目录下然后每天保存一个rdb快照到另一个目录下。每次定时脚本运行时确保调用find命令来保证过旧的rdb文件被删除例如你可以48小时内每小时都保存快照且1-2个月内每天都保存快照。确保用日期和时间来命名快照。每天至少将RDB快照转移一次至少不能在redis运行的物理机中。
备份aof
如果你的redis只使用了aof也可以备份。7.0开始aof分为多个文件这些文件保存在appenddirname配置的目录下。通常情况下你需要做的就是复制或者打包这些文件作为备份。使用这种方式备份要确保备份时关闭aof重写
关闭aof重写命令 CONFIG SET auto-aof-rewrite-percentage 0 确保不会手动调用aof重写(bgrewriteaof)检查是否正在重写 INFO persistence 并且确定aof_rewrite_in_progress为0如果为1意味着正在重写需要等一会现在可以安全的复制目录下的文件重新打开aof CONFIG SET auto-aof-rewrite-percentage prev-value
原文档redis持久化
