MISCONF RedisはRDBスナップショットを保存するように設定されています
Redisへの書き込み中（SET foo bar）、次のようなエラーが表示されます。
MISCONF RedisはRDBスナップショットを保存するように設定されていますが、現在ディスク上に保存することはできません。データセットを変更する可能性のあるコマンドは無効になります。エラーの詳細についてはRedisログを確認してください。
基本的に私は問題はredisがディスクにデータを保存することができないということですが、どのように問題を取り除くのかわからないということです。
また、 次の質問 も同じ問題を抱えています。答えは何もなく、おそらく問題を解決しようとする試みもなく、放棄されています。
エラーが発生し、実行中のredisインスタンスで重要なデータを破棄できない場合（rdbファイルまたはそのディレクトリへのアクセス権の問題、またはディスク領域の不足）、いつでもrdbファイルをリダイレクトすることができますそうでなければ。
redis-cliを使用すると、次のようなことができます。
CONFIG SET dir /tmp/some/directory/other/than/var
CONFIG SET dbfilename temp.rdb
その後、BGSAVEコマンドを実行して、データがrdbファイルに書き込まれるようにします。 INFOを実行するとき、bgsave_in_progressがすでに0であることを確認してください（操作は成功したか、エラーが発生しました）。その後、生成されたrdbファイルをどこか安全な場所にバックアップし始めることができます。
redis-cliを使うと、スナップショットを保存しようとするのをやめることができます。
config set stop-writes-on-bgsave-error no
これは簡単な回避策ですが、それを使用しているデータに関心がある場合は、最初にbgsaveが失敗した理由を確認する必要があります。
メモリ不足のため、bgsaveプロセス中にエラーが発生する可能性があります。これを試してください（redis background save FAQから）
echo 'vm.overcommit_memory = 1' >> /etc/sysctl.conf
sysctl vm.overcommit_memory=1
このエラーは、BGSAVEが失敗したために発生します。 BGSAVE中に、Redisは子プロセスをフォークしてデータをディスクに保存します。 BGSAVEの失敗の正確な理由はログ（通常はLinuxマシンの/var/log/redis/redis-server.logで）から確認できますが、フォークがメモリを割り当てられないためにBGAVEが失敗することがよくあります。 OSによる最適化の競合が原因で、フォークはメモリの割り当てに失敗します（マシンには十分なRAMがありますが）。
Redis FAQ から読むことができます：
Redisバックグラウンド保存スキーマは、最新のオペレーティングシステムのフォークのコピーオンライトセマンティックに依存しています。Redisは、親の正確なコピーであるフォーク（子プロセスを作成）をフォークします。子プロセスはディスク上のDBをダンプし、最終的に終了します。理論上、子は親であるコピーと同じだけのメモリを使用する必要がありますが、実際には最新のオペレーティングシステムで実装されているコピーオンライトセマンティックのおかげで、親と子プロセスは共通のメモリページを共有します。ページは、子または親で変更された場合にのみ複製されます。理論上、子プロセスの保存中にすべてのページが変更される可能性があるため、Linuxは子が使用するメモリ量を事前に判断できないため、overcommit_memory設定がゼロに設定されている場合、空きRAM必要に応じて、すべての親メモリページを実際に複製します。その結果、3 GBのRedisデータセットと2 GBの空きメモリしかない場合、失敗します。
Overcommit_memoryを1に設定すると、Linuxはより楽観的な割り当て方式でリラックスしてフォークを実行するようになります。これがRedisに必要なことです。
Redisは、OSがディスクへの書き込みに必要と考えるほど多くのメモリを必要としないため、フォークを先制的に失敗させる可能性があります。
これを解決するには、次のことができます。
/etc/sysctl.confを変更して追加します：
vm.overcommit_memory=1
次に、次を使用してsysctlを再起動します。
FreeBSDの場合：
Sudo /etc/rc.d/sysctl reload
Linuxの場合：
Sudo sysctl -p /etc/sysctl.conf
答えについては短すぎます。ターミナルを開き、次のコマンドを入力します。
redis-cli
そして今タイプ
config set stop-writes-on-bgsave-error no
linuxマシンで作業している場合は、データベースのファイルとフォルダのアクセス権も確認してください。
Dbとそのパスは、次の方法で取得できます。
redis-cli内：
CONFIG GETディレクトリ
CONFIG GET dbfilename
コマンドラインではls -lです。ディレクトリに対するパーミッションは 755 、ファイルに対するパーミッションは 644 であるべきです。また、通常redis-serverはユーザーredisとして実行されるので、Sudo chown -R redis:redis /path/to/rdb/folderを実行してユーザーredisにフォルダーの所有権を与えるのもいいでしょう。これは答えで詳しく述べられている ここ 。
問題をチェックしてくれてありがとう、エラーは明らかにbgsaveの間に生成されました。
私にとっては、シェルでconfig set stop-writes-on-bgsave-error noと入力してRedisを再起動すると問題は解決しました。
Redisが書き込み権限を持っているディレクトリでRedis Serverを起動します。
上記の答えは間違いなくあなたの問題を解決するでしょう、しかしここに実際に起こっていることがあります：
rdb.dumpファイルを格納するためのデフォルトの場所は./です（現在のディレクトリを示します）。これはredis.confファイルで確認できます。したがって、redisサーバーを起動したディレクトリはdump.rdbファイルが作成および更新される場所です。
Redisがdump.rdbファイルを作成するための正しい権限を持っていないディレクトリでredisサーバーを実行し始めたようです。
さらに悪いことに、redisはおそらく、適切なデータの保存を保証するためにrdbファイルを作成することができるまで、サーバーをシャットダウンすることを許可しないでしょう。
この問題を解決するには、redis-cliを使用してアクティブなredisクライアント環境に入り、dirキーを更新し、その値をプロジェクトフォルダ、またはroot以外が保存する権限を持つフォルダに設定する必要があります。次にBGSAVEを実行してdump.rdbファイルの作成を呼び出します。
CONFIG SET dir "/hardcoded/path/to/your/project/folder"
BGSAVE
（あなたが need でサーバを起動したディレクトリにdump.rdbファイルを保存する場合は、redisが書き込めるようにディレクトリのパーミッションを変更する必要があります。stackoverflowを検索することができます。どうやってするか）。
これでredisサーバーをシャットダウンできるはずです。パスをハードコードしたことに注意してください。ハードコーディングはめったに良い習慣ではありませんし、プロジェクトディレクトリからredisサーバーを起動してdir key back to./ `を変更することを強くお勧めします。
CONFIG SET dir "./"
BGSAVE
そうすれば、別のプロジェクトにredisが必要になったときに、ダンプファイルはハードコードされたパスのプロジェクトディレクトリではなく、現在のプロジェクトのディレクトリに作成されます。
もっと恒久的な修正は/etc/redis/redis.confの200行目から250行目付近にrdb機能の設定があることでしょう。
特に
dir ./
に変更することができます
dir /home/someuser/redislogfiledirectory
あるいは、すべての保存行をコメントアウトして、永続性を心配する必要はありません。 （/etc/redis/redis.confのコメントを見てください）
また、忘れないで
service redis-server stop
service redis-server start
このエラーが発生し、ログからエラーの原因がディスク容量が不足していることであることがわかりました。私のケースに挿入されたすべてのデータはもう必要ではありませんでした。それで私はFLUSHALLを試みました。 redis-rdb-bgsaveプロセスが実行されていたので、データもフラッシュすることを許可していませんでした。私は以下のステップに従って、続行することができました。
- Redisクライアントにログイン
- config setを実行して、bgsave-errorを停止します。
- _ flushall _ を実行します（保存されたデータは不要です）
- config setを実行して、bgsave-errorを停止します。yes
上記の手順の後、プロセスredis-rdb-bgsaveは実行されなくなりました。
これらすべての回答は、rdb保存が失敗した理由を説明していません。
私の場合として、私はredisログをチェックして、そして見つけました：
14975：M 18 Jun 13：23：07.354＃背景の保存がシグナル9で終了しました
端末で次のコマンドを実行します。
Sudo egrep -i -r 'killed process' /var/log/
それは表示されます：
/var/log/kern.log.1:Jun 18 13:23:07 10-10-88-16カーネル：[28152358.208108]強制終了プロセス28416（redis-server）合計vm：7660204kB、anon-rss：2285492kBファイルRSS：0 KB
それだ！このプロセス（redis save rdb）は OOM killer によって強制終了されました - /
参照してください：
確かに、私はこれに遭遇し、解決策は単にボックスにスワップファイルを追加することでした。私はこの方法を使用しました： https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04
最近、このエラーメッセージをクライアントに再発行するRedisの書き込みアクセスの問題は、公式のredisドッカーコンテナーに再出現しました。
公式のredisイメージ からのRedisは、コンテナ/dataフォルダーに.rdbファイルを書き込もうとします。これは、ルート所有フォルダーであり、非永続的な場所（コンテナ/ポッドがクラッシュすると、そこに書き込まれたデータは消えます）。
非アクティブな状態が1時間続いた後、redisコンテナーを非ルートユーザーとして実行した場合（たとえば、デフォルトのdocker run -u 1007ではなくdocker run -u 0）、詳細なエラーメッセージが表示されます。あなたのserverログ（docker logs redisを参照）：
1:M 29 Jun 2019 21:11:22.014 * 1 changes in 3600 seconds. Saving...
1:M 29 Jun 2019 21:11:22.015 * Background saving started by pid 499
499:C 29 Jun 2019 21:11:22.015 # Failed opening the RDB file dump.rdb (in server root dir /data) for saving: Permission denied
1:M 29 Jun 2019 21:11:22.115 # Background saving error
したがって、必要なことは、コンテナの/dataフォルダを外部の場所（ここでは非ルートユーザー、ここでは1007、ホストマシン上の/tmpなどの書き込みアクセス権）にマッピングすることです。 ：
docker run --rm -d --name redis -p 6379:6379 -u 1007 -v /tmp:/data redis
そのため、この「時限爆弾」を生成するのは、公式ドッカーイメージ（/tmpではなく/dataに書き込む必要があります）の構成の誤りです。静かな休日の週末：/
私は同様の問題に直面しました、これの背後にある主な理由はredisによるメモリ（RAM）消費でした。私のEC2マシンは8GBのRAMを持っていました（消費のために利用可能なおよそ7.4）
私のプログラムがRAMの使用量を7.2 GBまで上回ったとき、RAMに〜100MBを残すことはほとんどありませんでした、これは一般にMISCONF Redis error ...を引き起こします
htopコマンドを使用してRAMの消費量を判断できます。 htopコマンドを実行した後に Mem 属性を探します。それが高い消費を示すなら（私の場合のようにそれは7.2GB/7.4GBでした）それはより大きいMemoryでインスタンスをアップグレードするのが良いです。このシナリオでは、config set stop-writes-on-bgsave-error noを使用するとサーバーに障害が発生し、サーバー上で実行されている他のサービスが中断される可能性があります。それで、configコマンドを避け、 あなたのREDIS MACHINEをアップグレードしてください 。
参考：この作業を行うには、 htop をインストールする必要があります。Sudo apt-get install htop
もう1つの解決策 これを解決するには、システム上で他のRAM重いサービスが実行されている可能性があります。あなたのマシンで走っているすべてのサービスをチェックするためにはservice --status-allを使います。
そして、configコマンドを直接貼り付ける人のための提案です。ちょっと再検索して、そのようなコマンドを使う前に少なくともユーザーに警告してください。そして@Rodrigoが彼のコメントで述べたように、「エラーを無視することは格好良くない」
私も同じ問題に直面していました。両方の答え（最も支持されたものと受け入れられたもの）は同じものに対する一時的な修正を与えるだけです。
さらに、config set stop-writes-on-bgsave-error noは、このエラーを見過ごすための恐ろしい方法です。なぜなら、このオプションがすることは、書き込みが停止されたことを通知から止めてスナップショットにデータを書き込まずに進むことであるからです。これは単にこのエラーを無視しています。 これを参照
Redis-cliのdirにconfigを設定すると、redisサービスを再起動すると、これもクリアされ、同じエラーが再び表示されます。 redis.confのdirのデフォルト値は./であり、rootユーザーとしてredisを起動した場合、./は書き込み権限が与えられていない/なのでエラーになります。
最善の方法は、redis.confファイルでdirパラメータを設定し、そのディレクトリに適切な権限を設定することです。ほとんどのdebianディストリビューションはそれを/etc/redis/redis.confに含まなければなりません
認証トークンが期限切れになったため、AFSディスク・スペースを持つサーバーで作業しているときにこの問題に遭遇しました。これは、redisサーバーが保存しようとしたときにPermission Denied応答が返されたためです。トークンを更新することでこれを解決しました。
kinit USERNAME_HERE -l 30d && aklog
新しいフォルダをchmodしてchownする必要があります
chown -R redisおよびchmod ...
WindowsマシンでRedisをローカルで実行している場合は、「管理者として実行」してそれが機能するかどうかを確認してください。私と一緒に、問題はRedisがデフォルトで許可を制限する "Program Files"フォルダにあるということでした。そうあるべきです。
しかし、 自動的にRedisを管理者として実行しないでください あなたが持っているはずの権限をそれ以上付与したくない場合。あなたは本でこれを解決したいのです。
そのため、問題を管理者として実行することで問題を迅速に識別することができましたが、これでは解決できません。考えられるシナリオは、書き込み権限を持たないフォルダにRedisを配置したため、DBファイルが同じ場所に格納されていることです。
これを解決するには、redis.windows.confを開き、次の設定を検索します。
# The working directory. # # The DB will be written inside this directory, with the filename specified # above using the 'dbfilename' configuration directive. # # The Append Only File will also be created inside this directory. # # Note that you must specify a directory here, not a file name. dir ./
dir ./を通常の読み取り/書き込み権限を持つパスに変更します
また、Redisフォルダ全体を、適切な権限を持っていることがわかっているフォルダに移動することもできます。
私の場合、その理由はディスクの空き容量が非常に少なかったためです（わずか35 Mb）。私は以下をしました -
- すべてのRedis関連プロセスを停止しました
- ディスクのいくつかのファイルを削除して十分な空き容量を作ります
Redisダンプファイルを削除します（既存のデータが不要な場合）。
Sudo rm /var/lib/redis/*すべての既存のデータベースのすべてのキーを削除します
Sudo redis-cli flushall- すべてのセロリタスクを再起動し、問題がないか対応するログを確認してください
docker/docker-composeを使用しており、Redisがファイルに書き込まないようにする場合は、Redis構成を作成してコンテナーにマウントできます。
docker.compose.override.yml
redis:¬
volumes:¬
- ./redis.conf:/usr/local/etc/redis/redis.conf¬
ports:¬
- 6379:6379¬
デフォルトの設定は here からダウンロードできます
redis.confファイルで、これらの3行をコメント化してください。
save 900 1
save 300 10
save 60 10000
永続データを削除するためのより多くのソリューションを表示できます here
私の場合、それはディスクの空き容量に関連していました。 （df -h bashコマンドで確認できます）スペースを解放すると、このエラーは消えました。
私のために
config set stop-writes-on-bgsave-error no
macをリロードすると動作します
@Chrisが指摘したように、問題はメモリ不足になる可能性があります。 MySQL（_ innodb_buffer_pool_size）にRAMを割り当てすぎたときに経験し始めました。
Redisや他のサービスに十分なRAMがあることを確認するために、MySQLではinnodb_buffer_pool_sizeを減らしました。