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 persistence、bgsave_in_progressすでにある0とrdb_last_bgsave_statusされますok。その後、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の失敗の正確な理由はログ（通常は/var/log/redis/redis-server.logLinuxマシン上）から確認できますが、フォークがメモリを割り当てることができないため、BGAVEが失敗することがよくあります。OSによる競合する最適化のため、フォークはメモリの割り当てに失敗することがよくあります（ただし、マシンには十分なRAMがあります）。

Redis FAQから読むことができるように：

Redisバックグラウンド保存スキーマは、最新のオペレーティングシステムにおけるフォークのコピーオンライトセマンティクスに依存しています。親の正確なコピーであるRedisフォーク（子プロセスを作成）。子プロセスはDBをディスクにダンプし、最後に終了します。理論的には、子はコピーである親と同じ量のメモリを使用する必要がありますが、実際には、ほとんどの最新のオペレーティングシステムに実装されているコピーオンライトセマンティクスのおかげで、親と子のプロセスは共通のメモリページを共有します。子または親で変更された場合にのみ、ページが複製されます。理論的には、子プロセスの保存中にすべてのページが変更される可能性があるため、Linuxは子が使用するメモリの量を事前に通知できないため、overcommit_memory設定がゼロに設定されている場合、forkができるだけ多くの空きRAMがない限り失敗しますすべての親メモリページを実際に複製する必要があります。

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サーバーを再起動します。

• MacOSの（BREW） ：brew services restart redis。
• Linux： sudo service redis restart /sudo systemctl restart redis
• Windows： Windows + R->タイプservices.msc、Enter->検索してRedisをクリックしrestartます。

私は個人的に、Brew（brew upgrade）でredisをアップグレードした後にこの問題が発生しました。ラップトップを再起動した後、すぐに動作しました。

Linuxマシンで作業している場合は、データベースのファイルとフォルダの権限も再確認してください。

dbとそのパスは、次の方法で取得できます。

でredis-cli：

CONFIG GET dir

CONFIG GET dbfilename

コマンドラインでls -l。ディレクトリの権限は755で、ファイルの権限は644である必要があります。また、通常、redis-serverはuserとして実行されるため、を実行してユーザーredisにredisフォルダーの所有権を付与することもできますsudo chown -R redis:redis /path/to/rdb/folder。これについては、こちらの回答で詳しく説明しています。

問題を確認してくださった皆さんに感謝しますbgsave。どうやらエラーは中に発生したようです。

私にとって、config set stop-writes-on-bgsave-error noシェルを入力してRedisを再起動することで問題は解決しました。

Redisに書き込み権限があるディレクトリでRedisサーバーを起動します。

上記の答えは間違いなくあなたの問題を解決しますが、実際に起こっていることはここにあります：

rdb.dumpファイルを保存するデフォルトの場所は./（現在のディレクトリを示します）です。これはredis.confファイルで確認できます。したがって、redisサーバーを起動するディレクトリは、dump.rdbファイルが作成および更新される場所です。

dump.rdbファイルを作成するための適切な権限がredisにないディレクトリでredisサーバーの実行を開始したようです。

さらに悪いことに、redisは、データを適切に保存するためのrdbファイルを作成できるようになるまで、サーバーをシャットダウンすることもおそらく許可しません。

この問題を解決redis-cliするには、dirキーを使用してアクティブなredisクライアント環境に移動し、キーを更新して、その値をプロジェクトフォルダーまたは非ルートに保存する権限があるフォルダーに設定する必要があります。次に、実行BGSAVEしてdump.rdbファイルの作成を呼び出します。

CONFIG SET dir "/hardcoded/path/to/your/project/folder"
BGSAVE

（ここで、サーバーを起動したディレクトリにdump.rdbファイルを保存する必要がある場合は、redisが書き込みできるように、ディレクトリのアクセス許可を変更する必要があります。その方法については、stackoverflowを検索できます。 ）。

これで、redisサーバーをシャットダウンできるはずです。パスをハードコーディングしたことに注意してください。ハードコーディングはめったに良い習慣ではないので、プロジェクトディレクトリからredisサーバーを起動し、dir key back to。/ ` を変更することを強くお勧めします。

CONFIG SET dir "./"
BGSAVE

そうすれば、別のプロジェクトでredisが必要になったときに、ハードコーディングされたパスのプロジェクトディレクトリではなく、現在のプロジェクトのディレクトリにダンプファイルが作成されます。

MacOSを実行していて、最近Catalinaにアップグレードした場合brew services restart redisは、この問題で提案されているように実行する必要がある場合があります。

このエラーが発生し、ディスクの空き容量が不足しているためにエラーが発生したことがログからわかりました。私の場合に挿入されたすべてのデータはもはや必要ありませんでした。だから私はFLUSHALLを試してみました。redis-rdb-bgsaveプロセスが実行されていたため、データをFLUSHすることもできませんでした。以下の手順に従って、続行することができました。

1. Redisクライアントにログイン
2. config set stop-writes-on-bgsave-error noを実行します
3. FLUSHALLを実行します（保存されたデータは必要ありませんでした）
4. 実行はいコンフィグ設定ストップ書き込みオンbgsaveエラーを

上記の手順の後、プロセスredis-rdb-bgsaveは実行されなくなりました。

私は同様の問題に直面しましたが、その背後にある主な理由は、redisによるメモリ（RAM）の消費でした。私のEC2マシンには8 GBのRAMが搭載されていました（arounf 7.4は使用可能）

私のプログラムが実行されていたとき、RAM使用量は7.2 GBになり、RAMにほとんど100MBを残さなかった場合、これは一般に MISCONF Redis error ...

htopコマンドを使用して、RAM消費量を確認できます。htopコマンドを実行した後、Mem属性を探します。消費量が多い場合（私の場合は7.2GB / 7.4GB）、インスタンスのメモリを大きくしてアップグレードすることをお勧めします。このシナリオでは、を使用config set stop-writes-on-bgsave-error noするとサーバーに障害が発生し、サーバーで実行されている他のサービス（存在する場合）が中断される可能性があります。したがって、configコマンドを避けてREDIS MACHINEをアップグレードすることをお勧めします。

参考：これを機能させるには、htopのインストールが必要になる場合があります。sudo apt-get install htop

これに対するもう1つの解決策は、システムで実行されている他のRAM負荷の高いサービスである可能性があります。サーバー/マシン/インスタンスで実行されている他のサービスを確認し、必要でない場合は停止します。マシンで実行されているすべてのサービスを確認するにはservice --status-all

また、configコマンドを直接貼り付ける人への提案として、このようなコマンドを使用する前に、少し再調査を行い、少なくともユーザーに警告してください。@Rodrigoがコメントで述べたように、「エラーを無視するのはクールに見えません。」

- -更新 - -

また、メモリの特定の制限に達したときのRedisの動作を構成maxmemoryおよびmaxmemory-policy定義することもできます。たとえば、6GBのメモリ制限を維持し、DBから最も最近使用されていないキーを削除して、redis memの使用量が6GBを超えないようにする場合、これら2つのパラメーターを設定できます（redis.confまたはCONFIG SETで）コマンド）：

maxmemory 6gb
maxmemory-policy allkeys-lru

これらの2つのパラメーターに設定できる他の多くの値があります。これについては、https：//redis.io/topics/lru-cacheから読み取ることができます。

より恒久的な修正は、行200から250の周りの/etc/redis/redis.confを調べることである可能性があります。rdb機能の設定があり、2.x日のredisの一部ではありませんでした。

特に

dir ./

に変更することができます

dir /home/someuser/redislogfiledirectory

または、すべての保存行をコメント化して、永続性について心配する必要はありません。（/etc/redis/redis.confのコメントを参照）

また、忘れないでください

service redis-server stop
service redis-server start

これらすべての回答は、rdb saveが失敗した理由を説明していません。

私の場合として、私は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 kernel：[28152358.208108] Killed process 28416（redis-server）total-vm：7660204kB、anon-rss：2285492kB、 file-rss：0kB

それだ！このプロセス（redis save rdb）はOOMキラーによって強制終了されます

参照：

https://github.com/antirez/redis/issues/1886

Linux OOMキラーによって強制終了されたプロセスを見つける

FWIW、私はこれに遭遇し、解決策は単にスワップファイルをボックスに追加することでした。私はこの方法を使用しました：https : //www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04

私も同じ問題に直面していました。両方の答え（最も賛成されたものと受け入れられたもの）は、同じことを一時的に修正するだけです。

さらに、config set stop-writes-on-bgsave-error noこのオプションは、redisが書き込みが停止したことを通知し、スナップショットにデータを書き込まずに処理を続行するため、このエラーを見落とすための恐ろしい方法です。これは単にこのエラーを無視しているだけです。 これを参照

設定用としてdirではconfigあなたはRedisのサービスを再起動した後のRedis-CLIで、これはあまりにもクリアされなければならず、同じエラーが再びポップアップするものとします。デフォルト値dirではredis.confある./し、rootユーザーとしてのRedisを開始した場合、その後./である/ので、エラーの書き込み権限が付与されていないためにどのと。

最良の方法はdir、redis.confファイルでパラメーターを設定し、そのディレクトリに適切な権限を設定することです。ほとんどのdebianディストリビューションでは、/etc/redis/redis.conf

最近では、Redisの書き込みアクセスの問題が原因で、このエラーメッセージが公式のredisDockerコンテナーに再び現れたクライアントに表示されます。

公式redisイメージの Redisは、 .rdbファイルをコンテナー/dataフォルダーに書き込もうとしますが、これはルート所有フォルダーであり、非永続的な場所でもあるため、残念です（コンテナー/ポッドの場合、そこに書き込まれたデータは消えます）クラッシュ）。

したがって、非アクティブな状態が1時間続いた後、redisコンテナーを非rootユーザーとして（たとえばdocker run -u 1007、デフォルトではなくdocker run -u 0）実行した場合、サーバーログに詳細なエラーメッセージが表示されます（を参照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フォルダを外部の場所にマップする必要があります（ここでは、非rootユーザー、ここでは1007、/tmpホストマシンなどに書き込みアクセス権があります）。

docker run --rm -d --name redis -p 6379:6379 -u 1007 -v /tmp:/data redis

したがって、この「時限爆弾」を生成するのは、公式のDockerイメージの設定ミスです（書いて/tmpはいけません/data）。本番環境でのみ発生する可能性が高いのは、特に静かな休日の週末に一晩：/

私のために

config set stop-writes-on-bgsave-error no

Macをリロードすると動作します

私の認証トークンの有効期限が切れたため、AFSディスク領域のあるサーバーで作業しているときにこの問題が発生しPermission Denied、redis-serverが保存しようとしたときに応答が返されました。私は私のトークンを更新することでこれを解決しました：

kinit USERNAME_HERE -l 30d && aklog

ケースでは、使用しているドッキングウィンドウ/ドッキングウィンドウ-コンをし、ファイルへの書き込みからRedisのを防ぐためにしたい、あなたはRedisのコンフィグを作成し、容器にマウントすることができます

docker.compose.override.yml

  redis:¬
      volumes:¬
        - ./redis.conf:/usr/local/etc/redis/redis.conf¬
      ports:¬
        - 6379:6379¬

ここからデフォルトの設定をダウンロードできます

redis.confファイルで、これらの3行をコメント化してください。

save 900 1
save 300 10
save 60 10000

永続的なデータを削除するためのその他のソリューションをここに表示できます

私の場合redisは、簡単な方法でインストールしたために発生しました。したがって、redisはrootとして実行されていません。クイックスタートガイドのInstalling Redis more properlyセクションにある手順に従って、この問題を解決することができました。そうした後、問題は解決され、現在rootとして実行されています。見てみな。redis

ようやく多くのSOの質問に頭を悩ませた後、私にとって@Axel Adventoの答えは機能しましたが、いくつかの追加の手順を実行しただけで、私はまだ権限の問題に直面していました。
ユーザーをに切り替えredis、ホームディレクトリに新しいディレクトリを作成して、redisのディレクトリとして設定する必要がありました。

sudo su - redis -s /bin/bash
mkdir redis_dir
redis-cli CONFIG SET dir $(realpath redis_dir)
exit # to logout from redis user (optional)

私の場合、それはディスクの空き容量に関係していました。（df -hbashコマンドで確認できます）スペースを解放すると、このエラーは消えました。

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フォルダー全体を、適切なアクセス許可があることがわかっているフォルダーに移動することもできます。

私にとっては、永続的なredisデータフォルダーに対する権限の問題でした。私はそれを与えました：

chmod 777 -Rf data/

そしてそれはうまくいきました！問題を解決したと言うのは早いかもしれません。また、redisがrootとして実行されていないのではないかと思うので、詳細を調べるにはdockerFileを調べる必要があります。

アクションを実行する前に、Redisログを確認してください。このスレッドのソリューションの一部はRedisデータを消去する可能性があるため、何をしているかに注意してください。

私の場合、マシンのRAMが不足していました。これは、ホストに空きディスク領域がない場合にも発生する可能性があります。

このエラーは、サーバーが攻撃を受けているときに表示されることに注意してください。redisが '/etc/cron.d/web'への書き込みに失敗したことがわかりました。許可を修正した後、いくつかの非表示オプションを備えたマイニングアルゴリズムで構成される新しいファイルが追加されました。

# on redis 6.0.4 
# if show error 'MISCONF Redis is configured to save RDB snapshots'
# Because redis doesn't have permissions to create dump.rdb file
sudo redis/bin/redis-server 
sudo redis/bin/redis-cli

@Chrisが指摘したように、問題はメモリ不足になる可能性があります。MySQLに割り当てたRAMが多すぎると、この問題が発生し始めました（innodb_buffer_pool_size）。

Redisおよびその他のサービス用に十分なRAMがあることを確認するために削減しました innodb_buffer_pool_sizeMySQLでした。

私の場合、理由はディスクの空き容量が非常に少ない（35 MBしかない）ためです。私は次のことをしました-

1. すべてのRedis関連プロセスを停止しました
2. ディスク内のいくつかのファイルを削除して、十分な空き領域を作ります

3. redisダンプファイルを削除する（既存のデータが不要な場合）

   sudo rm /var/lib/redis/*

4. 既存のすべてのデータベースのすべてのキーを削除します

   sudo redis-cli flushall

5. すべてのセロリタスクを再起動し、対応するログで問題を確認します

新しいフォルダをchmodしてchownする必要があります

chown -R redisおよびchmod ...