redis引发的小事故

项目内部环境的数据库采用的是Redis + Mysql模式,由于其他原因,测试环境的服务器宕机,重启后惊喜发现redis中的数据全不见了!!直接导致测试环境的崩溃。之前虽知道redis数据存在内存中,但仍然是有办法可以备份和恢复数据的。

Redis一种有两种方式存储数据,分别是:

AOF (append-only file)和 RDB(Redis DataBase)

搜索一番之后决定先用AOF模式进行数据恢复。 先说一下为什么不用RDB模式进行存储:RDB是在某个时间点将数据写入一个临时文件,持久化结束后,用这个临时文件替换上次持久化的文件,达到数据恢复。

优点:使用单独子进程来进行持久化,主进程不会进行任何IO操作。可以保证Redis的高性能。

缺点:RDB是隔一段时间进行持久化,如果持久化之间redis发生故障,则数据可能会丢失。所以这种模式更适合对数据要求不严谨的时候。

AOF将“操作”和“数据”以格式化指令的方式追见到操作日志文件的尾部,在append操作返回后(已经写入文件或者即将写入),才进行实际的数据变更,“日志文件”保存了历史所有的操作过程,当server需要数据恢复时,可以直接replay此日志文件,即可还原所有的操作过程,它和mysql中的bin.log、apache.log功能类似。

优点:可以保持更高的数据完整性,如果设置追加file的时间是1s,如果redis发生故障,最多会丢失1s的数据;且如果日志写入不完整支持redis-check-aof来进行日志修复;AOF文件没被rewrite之前(文件过大时会对命令进行合并重写),可以删除其中的某些命令(比如误操作的flushall)。

缺点:AOF文件比RDB文件大,而且恢复速度慢。

我们可以简单粗暴地认为AOF就是一个日志文件,此文件只记录数据的“变更操作”比如set/del等等,如果server中持续的大量变更操作,将会导致AOF文件非常的庞大,意味着恢复数据的时间会很长;事实上,如果对一条数据 进行多次更新,我们只需要恢复最后一次操作数据的操作即可。

AOF的特性决定了它相对比较安全,如果你期望数据丢失更少,那么AOF无意是最佳选择,如果AOF文件正在写入的过程中server突然挂掉,有可能导致最后一次记录不完整,我们可以功过手工,或者程序的方法去检测并修正不完整的记录,以便通过AOF文件恢复能够正常。

在Linux服务器中设置aof模式只需配置三行。找到redis的配置文件rediso.conf

# 开启

appendonly yes

# 指定aof文件名

appendfilename appendonly.aof

# 指定同步策略

appendfsync everysec

只需三行配置,配齐后重启redis就齐活了。妈妈再也不用担心你的数据会丢失啦。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180708G1GNQN00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券