数据持久化

1.redis持久化的意义 redis持久化的意义，在于 故障恢复 。 如果没有对数据进行持久化，那么如果redis遇到灾难性的故障，就会丢失所有的数据。 如果通过redis的持久化机制将数据持久化到硬盘上面去，然后在定期将磁盘上的文件备份到一起其他的服务器上面(比如:云服务器),这样就可以保证即使redis遇到了灾难事故，也可以使用提前备份的文件对数据进行回复，之后丢失最近的一部分数据，而不会全部丢失数据。 2.redis的两种持久化方式 redis的持久化是跟高可用相关的。redis有两种持久化的方式，分别是RDB和AOF。 (1)RDB和AOF两种持久化机制介绍 RDB持久化机制，对redis中的数据执行周期性的持久化。 AOF机制对每条写入命令作为日志，以append-only的模式写入一个日志文件中，在redis重启的时候，可以通过回复AOF日志中的写入指令来重新构建整个数据集。 如果我们想要redis仅仅作为纯内存的缓存来用，那么可以禁止RDB和AOF所有持久化机制。 通过RDB或AOF，都可以将redis内存中的数据给持久化到磁盘上面去，然后可以将这些数据备份到别的地方去。 如果redis挂了，服务器上的内存和磁盘上的数据都丢了，可以从云服务上拷贝回来之前的数据，放到指定的目录中，然后重新启动redis，redis就会自动根据持久化数据文件中的数据，去恢复内存中的数据

Redis持久化的意义 　　在于故障恢复 　　比如你部署了一个redis，作为cache缓存，当然也可以保存一些较为重要的数据 　　如果没有持久化的话，redis遇到灾难性故障的时候(断电、宕机)，就会丢失所有的数据 　　如果通过持久化将数据搞一份儿在磁盘上去，然后定期比如说同步和备份到一些云存储服务上去，那么就可以保证数据不丢失全部，还是可以恢复一部分数据回来的 通常Redis 将数据存储在内存中或虚拟内存中，它是通过以下两种方式实现对数据的持久化（如果我们想要redis仅仅作为纯内存的缓存来用，那么可以禁止RDB和AOF所有的持久化机制） 1、RDB 快照方式：（默认持久化方式） 　　这种方式就是将内存中数据以快照的方式写入到二进制文件中，默认的文件名为 dump.rdb。客户端也可以使用 save 或者 bgsave 命令通知 redis做一次快照持久化。save 操作是在 主线程中保存快照的，由于 redis 是用一个主线程来处理所有客户端的请求，这种方式会阻塞所有客户端请求。所以不推荐使用。另一点需要注意的是，每次快照持久化都是将内存数 据完整写入到磁盘一次，并不是增量的只同步增量数据。如果数据量大的话，写操作会比较多，必然会引起大量的磁盘 IO 操作，可能会严重影响性能。 　　 注意：由于快照方式是在一定间隔时间做一次的，所以如果 redis 意外当机的话，就会

1、介绍： 　RDB持久化机制，是对redis中的数据执行周期性的持久化； 　AOF机制是对每条写入的命令作为日志，以append-only的模式写入到一个日志文件中，在redis重启的时候，将AOF日志中的数据重新加载到redis内存中去； 2、两种持久化方式的优缺点： RDB模式优点： RDB会生成多个数据文件，每个文件代表了某一时刻中redis中的数据，适合做冷备，可以将数据文件放到远程的安全存储上，如阿里云，以保证数据的安全； RDB对redis对外提供的读写服务影响小，可以让redis保持高性能，主要是因为redis主进程只需要fork一个子进程，让子进程执行磁盘的IO操作来进行持久化即可； 相比较AOF的持久化机制来说，基于RDB数据文件来重启或者回复redis进程，更加的快速，因为AOF做数据恢复的时候，要执行保存的所有的指令日志，而RDB恢复的时候，直接加载到内存中即可； RDB模式的缺点： 如果想在redis故障的时候，尽可能少的丢失数据，那么RDB没有AOF好，一般RDB快照文件都是隔5分钟或者更长的时间生成一次，在这段时间出现故障，会丢失5分钟或者更长时间的数据（最大的缺点）； RDB每次在fork子进程来执行RDB快照数据文件的时候，如果数据文件特别大，可能会导致redis客户端提供的服务暂停数毫秒或者几秒，对redis的性能可能会有影响； AOF模式的优点

原文: redis的两种持久化方案 前言 人生在于折腾系列，网络，多线程等系列博客楼主还在继续折腾也不会放弃。这是全新的系列，缓存的知识其实并不仅仅在于简单的增删改查，我觉得有必要全面深入的学习一波。记录学习的过程与体悟。 RDB 什么是RDB 对redis中的数据执行周期性的持久化，通过配置文件中设置检查间隔时间与备份触发条件来对数据进行周期性的持久化 RDB持久化的优点 RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中redis的数据，这种多个数据文件的方式，非常适合做冷备份。 RDB对redis对外提供的读写服务，影响非常小，可以让redis保持高性能，因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可 相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复redis进程，更加快速 RDB持久化的缺点 如果想要在redis故障时，尽可能少的丢失数据，那么RDB没有AOF好。一般来说，RDB数据快照文件，都是每隔5分钟，或者更长时间生成一次，这个时候就得接受一旦redis进程宕机，那么会丢失最近5分钟的数据。这个问题，也是rdb最大的缺点，就是不适合做第一优先的恢复方案，如果你依赖RDB做第一优先恢复方案，会导致数据丢失的比较多 RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大

一、Redis提供了哪些持久化机制： 1). RDB持久化： 该机制是指在指定的时间间隔内将内存中的数据集快照写入磁盘。 2). AOF持久化: 该机制将以日志的形式记录服务器所处理的每一个写操作，在Redis服务器启动之初会读取该文件来重新构建数据库，以保证启动后数据库中的数据是完整的。 3). 无持久化： 我们可以通过配置的方式禁用Redis服务器的持久化功能，这样我们就可以将Redis视为一个功能加强版的memcached 了。 4). 同时应用AOF和RDB。 二、RDB机制的优势和劣势： RDB存在哪些优势呢？ 1). 一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。 2). 对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。 3). 性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。 4). 相比于AOF机制，如果数据集很大，RDB的启动效率会更高。 RDB又存在哪些劣势呢？ 1).

一、Redis提供了哪些持久化机制： 1). RDB持久化： 该机制是指在指定的时间间隔内将内存中的数据集快照写入磁盘。 2). AOF持久化: 该机制将以日志的形式记录服务器所处理的每一个写操作，在Redis服务器启动之初会读取该文件来重新构建数据库，以保证启动后数据库中的数据是完整的。 3). 无持久化： 我们可以通过配置的方式禁用Redis服务器的持久化功能，这样我们就可以将Redis视为一个功能加强版的memcached了。 4). 同时应用AOF和RDB。 二、RDB机制的优势和劣势： RDB存在哪些优势呢？ 1). 一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数 据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。 2). 对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。 3). 性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。 4). 相比于AOF机制，如果数据集很大，RDB的启动效率会更高。 RDB又存在哪些劣势呢？ 1).

RDB 持久化 　　RDB 快照命令 　　RDB 创建原理 　　RDB 的优点 　　RDB 的缺点 AOF 持久化 　　AOF 的配置 　　AOF 创建原理 　　AOF 的优点 　　AOF 的缺点 RDB 和 AOF 二者的区别 RDB 和 AOF 我应该用哪一个 AOF BGREWRITEAOF 重写 备份 Redis 数据 Redis 提供了 RDB 和 AOF 两种持久化方案 ： RDB：生成指定时间间隔内的 Redis 内存中数据快照，是一个二进制文件 dumpr.rdb AOF：记录 Redis 除了查询以外的所有写命令，并在Redis 服务启动时，通过重新执行这些命令来还原数据。 RDB 持久化 默认 Redis 会以 RDB 快照的形式将一段时间内的数据持久化到硬盘，保存成一个 dumpr.rdb 二进制 文件。 工作原理简单介绍一下 ： 当 Redis 需要做持久化时，Redis 会 fork 一个子进程，子进程将数据写到磁盘上一个临时 RDB 文件中。当子进程完成写临时文件后，将原来的 RDB 替换掉，这样的好处就是可以 copy-on-write 。 当然我们也可以手动执行 save 或者 bgsave （异步）生成 RDB 文件。 900秒之内，如果超过1个key被修改，则发起快照保存； 300秒之内，如果超过10个key被修改，则发起快照保存； 60秒之内

RDB(Redis DataBase) AOF(Append Only File) 周阳语录：能撑过面试经理头一分钟最重要。头一分钟，决定人家还是否想跟你继续聊下去。 RDB RDB就是在指定的时间内，将内存中的数据集写入磁盘。恢复时，将快照文件直接读到内存。 周阳语录：一定要跟上老员工的脚步，跟上了，人家才带你玩。想进步，就要有人带，就要跟对人。 save命令会强制备份，flushall也会强制备份！生成dump.rdb文件！ 正常情况下，备份的机器和生产的机器不是同一个机器！ 正常情况下，备份和恢复工作，或升级系统都在凌晨去处理！ rdb适合大规模的文件恢复，但是对于数据的完整性和一致性要求不高。 意外down掉的话，就会丢失最后一次快照。 新技术的出现，一定会借鉴老技术，并弥补老技术的不足。新技术是老技术的子集。AOF就这样诞生了！ AOF，记录所有的写操作语句。 df -h 查看磁盘空间。 AOF AOF是以日志的形式记录每个写操作。将Redis执行过的所有写操作指令记录下来，只允许追加文件。redis启动之初会读取该文件重新构建数据，以完成数据恢复工作。 AOF保存的是appendonly.aof文件。 主从复制，读写分离比AOF更牛逼。 AOF和RDB是否可以同时存在？可以同时共同，但是如果开启AOF，优先查找AOF恢复数据，如果AOF出现数据错误

RDB持久化 AOF持久化 全量备份,一次保存整个数据库 增量备份,一次保存一个修改数据库的命令 保存的间隔较长 保存的间隔默认一秒 数据还原速度快 数据还原速度一般 save会阻塞,但bgsave或者自动不会阻塞 无论是平时还是AOF重写,都不会阻塞 更适合数据备份,默认开启 更适合用来保存数据,和一般SQL持久化方式一样,默认关闭 启动优先级 : 低 启动优先级 : 高 体积 : 小 体积 : 大 恢复速度 : 快 恢复速度 : 慢 数据安全性 : 丢数据 数据安全性 : 根据策略决定 轻重 : 重 轻重: 轻 1.在dump rdb过程中,aof如果停止同步,会不会丢失? 不会,所有的操作缓存在内存队列里,dump完后后,统一操作 2.aof重写是什么? aof重写就是把内存中的数据逆化成命令,写入到aof文件,以解决aof日志过大的问题 3.如果rdb和aof文件都存在,优先使用谁恢复数据? 在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件完整 4.rdb和aof是否可以同时用? 可以,推荐同时使用 5.恢复时,rdb和aof哪个更快? rdb快,因为rdb是数据的内存映射,直接载入到内存,而aof是命令,需要逐条执行 6.如何在不用【config set】命令的情况下

一、为什么namenode持久化 　　namenode通过内存存储hdfs集群的元数据（目录结构 文件信息 块对应关系），如果内存出现问题，那么会数据丢失，需要通过持久化，把内存中的数据定期的存储在硬盘中，进而保证namenode的数据安全。 二、持久化的原理 1、FSImage (某一时刻 namenode镜像数据) 　　　　默认存储位置 　　　　/opt/install/hadoop-2.5.2/data/tmp/dfs/name 　　2、EditsLog （某一时刻后的，写日志操作） 　　　　FSImage 会在集群格式化时，生成空的FSImage ，后续用户的操作都会写入到EditsLog中 　　　　每一次重启namenode时，把EditsLog和FSImage的数据在内存中合并，并生成一哥新的EditsLog， 　　　　时间没到制定时间点或没有到事务数 FSImage时不会和EditsLog合并 　　　　时间到制定时间点或到事务数 FSImage时会和EditsLog合并，生成新的FSImage（有数据）和新的EditsLog 　　　 　　相关配置可以打开 http://hadoop.apache.org/docs/r2.5.2/ 　　　　 　　　　 　　　　　　　　配置这些文件要在 　　　　　　　　　　cd /opt/install/hadoop-2.5.2/etc