解决 MISCONF Redis is configured to save RDB snapshots 异常详解
java抛出异常内容
- Caused by: io.lettuce.core.RedisCommandExecutionException: MISCONF Redis is configured to save RDB snapshots, but it is currently not able to persist on disk. Commands that may modify the data set are disabled, because this instance is configured to report errors during writes if RDB snapshotting fails (stop-writes-on-bgsave-error option). Please check the Redis logs for details about the RDB error.
- at io.lettuce.core.ExceptionFactory.createExecutionException(ExceptionFactory.java:135)
- at io.lettuce.core.ExceptionFactory.createExecutionException(ExceptionFactory.java:108)
- at io.lettuce.core.protocol.AsyncCommand.completeResult(AsyncCommand.java:120)
- at io.lettuce.core.protocol.AsyncCommand.complete(AsyncCommand.java:111)
- at io.lettuce.core.protocol.CommandHandler.complete(CommandHandler.java:646)
- at io.lettuce.core.protocol.CommandHandler.decode(CommandHandler.java:604)
- at io.lettuce.core.protocol.CommandHandler.channelRead(CommandHandler.java:556)
- at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
- at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
- at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
- at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
- at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
- at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
- at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
- at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:163)
- at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:714)
- at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:650)
- at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:576)
- at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
- at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
- at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
- at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
- ... 1 common frames omitted
最近遇到应用程序客户端在往redis中写入数据的时候发生了一个这样一个错误:
MISCONF Redis is configured to save RDB snapshots, but is currently not able to persist on disk. Commands that may modify the data set are disabled.
第一次遇到这种错误还是蛮好奇的,主要是它无法重现(或必现),只是会偶尔出现,客户端抛出该异常后redis服务状态也是正常的,特意查了一下相关的资料,结合当时自己的操作场景,还算是解释的通的。
该问题的大概原因在于:开启了snapshot的持久化模式,且在大量写入的时候bgsave持久化异常,导致客户端写入数据失败,原因译文中有提及。
当然解决办法也很简单,设置参数stop-writes-on-bgsave-error为no,也即bgsave异常的时候不要阻止继续写入数据。
我的环境是:
centos 7+ Redis 5.0.1;
操作场景是:
并发线程以pipline的方式往redis中写入数据,这样会频繁促使发生后台持久化线程pgsave的工作(操作系统远大于redis中的数据占用内存);
异常现象:
客户端会偶发上述错误,但是redis服务本身没有异常,事后可以正常访问。
经检查redis的日志和系统日志,均没有记录到异常信息,应该是redis设置了stop-writes-on-bgsave-error=yes的情况下,服务端bgsave失败之后一种正常的阻止继续写入行为。
同时,尽管在操作系统的内存充足的情况下,redis的bgsave为什么会失败,这也是一个需要思考的问题。
这个问题一直没有查到日志(不管是redis的日志还是系统的日志),一直怀疑是不是自己整错什么东西了。
发现原因:
redis的bgsave是一个独立于redis服务的进程,对于在大批量写入的情况下,经常可以看到一个redis实例下的这个bgsave独立进程(进程之间是无法共享内存的)
有时候Redis会抛出如下的错误:
- MISCONF Redis is configured to save RDB snapshots, but is currently not able to persist on disk. Commands that may modify the data set are disabled.
- Please check Redis logs for details about the error.
发生此错误是因为BGSAVE失败。很多时候BGSAVE失败是因为fork无法分配内存。很多时候fork无法分配内存(尽管机器有足够的可用RAM),因为操作系统的优化冲突。
Redis后台保存模式依赖于现代操作系统中fork的copy-on-write语义:Redis forks(创建一个子进程)是父进程的完全副本。子进程将数据库转储到磁盘上,最后退出。
Redis在保存数据到硬盘时为了避免主进程假死,需要Fork一份主进程,然后在Fork进程内完成数据保存到硬盘的操作,如果主进程使用了4GB的内存,Fork子进程的时候需要额外的4GB,此时内存就不够了,因此,当redis使用的内存超过操作系统一半的内存的时候,For就失败了,进而数据保存硬盘也失败了。
修改redis.conf文件:vi打开redis-server配置的redis.conf文件,然后使用快捷匹配模式:/stop-writes-on-bgsave-error定位到stop-writes-on-bgsave-error字符串所在位置,接着把后面的yes设置为no即可。
stop-writes-on-bgsave-error no
这就暂时解决了这个问题。但是,这个选项的作用是阻止redis通知写操作已经停止,并且在不将数据写入快照的情况下继续操作。这只是忽略了这个异常,使得程序能够继续往下运行,但实际上数据还是会存储到硬盘失败!
linux系统可以通过修改内存分配策略解决
- # echo 'vm.overcommit_memory = 1' >> /etc/sysctl.conf
- # sysctl vm.overcommit_memory=1
优化redis写入的代码,避免高频写入,减少非必要持久化的数据。