Redis宕机或者出现意外删库导致数据丢失--解决方案( 二 ) _Redis宕机

使用flushall模拟数据丢失该操作有一定的风险性，如果是演示练习按照操作来基本不会出现问题，但是生产上慎重操作。我们做该操作之前，一定要注意先备份RDB对应的持久化问题dump.rdb
# 先备份dump.rdbcp dump.rdb dump.rdb.bak# 备份完成之后我们确定备份成功在进行下一步操作---清空库flushall# 清空之后我们停止服务器shutdown# 再次启动服务器，查看之前存储的kyekeys * 再次启动查看的时候，我们发现我们的数据丢失了

文章插图

恢复丢失的数据# 停服务器shutdown# 删除我们现有dump.rdbrm -rf ./dump.rdb# 删除成功之后，将我们的备份的dump.rdb.bak重新命名成为dump.rdbmv dump.rdb.bak dump.rdb# 确定之后我们再次启动redis服务redis-server redis.conf# 检查我们之前丢失的数据是否存在keys * 完成之后我们查看的数据就出现啦！

文章插图

AOF [Append Only File]AOF：Redis 默认不开启。AOF采用日志的形式来记录每个写操作，并追加到文件中。开启后，执行更改 Redis 数据的命令时，就会把命令写入到AOF文件中。Redis重启时会根据日志文件的内容把写指令从前到后执行一次以完成数据的恢复工作。
该方式默认关闭，需要使用我们需要修改如下配置
数据都是实时持久化到磁盘吗？由于操作系统的缓存机制， AOF数据并没有真正地写入硬盘，而是进入了系统的硬盘缓存。什么时候把缓冲区的内容写入到 AOF 文件？
AOF的保存规则有三种

文章插图
【Redis宕机或者出现意外删库导致数据丢失--解决方案】
AOF 持久化策略（硬盘缓存到磁盘），默认 everysec

no 表示不执行 fsync ，由操作系统保证数据同步到磁盘，速度最快，但是不太安全；
always 表示每次写入都执行 fsync ，以保证数据同步到磁盘，效率很低；
everysec 表示每秒执行一次 fsync ，可能会导致丢失这 1s 数据。通常选择 everysec ，
兼顾安全性和效率。

文件越来越大，怎么办？由于 AOF 持久化是 Redis 不断将写命令记录到 AOF 文件中，随着 Redis 不断的进行， AOF 的文件会越来越大，文件越大，占用服务器内存越大以及 AOF恢复要求时间越长。
可以使用命令 bgrewriteaof来重写。AOF文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的 AOF 文件。
AOF指定大小开始重写

文章插图

auto-aof-rewrite-percentage:默认值为100 。aof自动重写配置，当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写，即当aof文件增长到一定大小的时候， Redis能够调用bgrewriteaof对日志文件进行重写。当前AOF文件大小是上次日志重写得到AOF文件大小的二倍（设置为100）时，自动启动新的日志重写过程。
auto-aof-rewrite-min-size:默认64M 。设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写。
AOF方式的优点
AOF 持久化的方法提供了多种的同步频率，即使使用默认的同步频率每秒同步一次， Redis最多也就丢失 1 秒的数据而已。
AOF方式的缺点
对于具有相同数据的的Redis ， AOF文件通常会比RDF文件体积更大（RDB存的是数据快照）。
虽然 AOF 提供了多种同步的频率，默认情况下，每秒同步一次的频率也具有较高的性能。在高并发的情况下， RDB 比 AOF 具好更好的性能保证。

两种方案比较那么对于AOF和RDB两种持久化方式，我们应该如何选择呢？
如果可以忍受一小段时间内数据的丢失，毫无疑问使用 RDB 是最好的，定时生成RDB 快照（snapshot）非常便于进行数据库备份，并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快。否则就使用AOF重写。但是一般情况下建议不要单独使用某一种持久化机制，而是应该两种一起用，在这种情况下,当 redis 重启的时候会优先载入 AOF文件来恢复原始