何が起きたのか?
Redisへの書き込み中にアプリがこのエラーに遭遇しました:
MISCONF Redis is configured to save RDB snapshots, but it's currently not able to persist to disk. Commands that may modify the data set are disabled. Please check Redis logs for details about the error.
直前のバックグラウンド保存(BGSAVE)が失敗したため、Redisはすべての書き込みコマンド(SET、HSET、LPUSHなど)をブロックしています。デフォルトでは、データを永続化できない場合にRedisは書き込みの受け付けを停止します。これは意図的な安全機構です——警告なしにデータを失うよりも、明確にエラーを出す方が良いという考えです。
主な原因は3つです:ディスクがいっぱい、データディレクトリへの書き込み権限がRedisプロセスにない、またはRDBディレクトリが存在しない場合です。
ステップ1:まずRedisのログを確認する
ここから始めましょう——ログにはほぼ必ず何が失敗したか正確に記録されています:
# Redisのログファイルを確認する
tail -n 50 /var/log/redis/redis-server.log
# systemdで実行している場合
journalctl -u redis -n 50 --no-pager
# Docker内の場合
docker logs <container_name> --tail 50
以下のメッセージを探します:
Can't save in background: fork: Cannot allocate memoryFailed opening the RDB file dump.rdb for saving: Permission deniedFailed opening the RDB file: No space left on device
ステップ2:根本原因を特定する
ディスク容量を確認する
df -h
# Redisがデータを保存するパーティションに注目する
# デフォルト:/var/lib/redis または /etc/redis
df -h /var/lib/redis
パーティションが100%になっていますか?それが原因です。まずスペースを確保しましょう。
Redisデータディレクトリのパーミッションを確認する
# Redisがデータを保存している場所を確認する
redis-cli CONFIG GET dir
# そのディレクトリの所有権とパーミッションを確認する
ls -la /var/lib/redis/
# 期待される出力:redisユーザーが所有するディレクトリ
# drwxr-x--- 2 redis redis 4096 Mar 18 10:00 /var/lib/redis
ディレクトリがroot所有だがRedisがredisユーザーとして実行されている場合、すべての保存試行が静かに失敗します。
ディレクトリが存在するか確認する
redis-cli CONFIG GET dir | tail -1 | xargs ls -la
パスが存在しませんか?これはボリュームの再マウントやDockerの再起動後によく発生します。存在しない場所にはRedisは書き込めません。
ステップ3:クイックフィックス——書き込みを即座にアンブロックする
本当の問題を調査している間にアプリをアンブロックする必要がありますか?これを実行してください:
redis-cli CONFIG SET stop-writes-on-bgsave-error no
即座に効果があります。再起動不要。 RDB保存が失敗しても、Redisは再び書き込みコマンドを受け付けます。
これは時間稼ぎです——恒久的な解決策として扱わないでください。これをオフにすると、Redisはデータの永続化に静かに失敗し、再起動でデータセットが消えるまで気づかない可能性があります。
ステップ4:実際の問題を修正する
ディスクがいっぱいの場合
# ディスク容量を消費している大きなファイルを探す
du -sh /var/log/* | sort -hr | head -20
du -sh /var/lib/* | sort -hr | head -20
# 古いシステムログをクリーンアップする(例:最新の200MBだけ保持)
journalctl --vacuum-size=200M
# 残ったRDBバックアップファイルを確認する
ls -lh /var/lib/redis/*.rdb
パーミッションの問題の場合
# Redisデータディレクトリの所有権を修正する
sudo chown -R redis:redis /var/lib/redis
# パーミッションを修正する
sudo chmod 750 /var/lib/redis
# dump.rdbファイル自体の所有権が間違っている場合
sudo chown redis:redis /var/lib/redis/dump.rdb
ディレクトリが存在しない場合
# ディレクトリを作成して正しい所有権を設定する
sudo mkdir -p /var/lib/redis
sudo chown redis:redis /var/lib/redis
sudo chmod 750 /var/lib/redis
ボリュームマウントでDockerで実行している場合
ボリュームマウントの所有権の問題は、DockerのRedis障害の大きな原因です。ホストディレクトリをバインドマウントすると、root所有になることが多く、Redisはそこに書き込めません:
# docker-compose.yml
services:
redis:
image: redis:7-alpine
volumes:
- ./redis-data:/data
user: "999:999" # 公式イメージのredisユーザーID
command: redis-server --save 60 1 --loglevel warning
# ホスト側の所有権を修正する
sudo chown -R 999:999 ./redis-data
ステップ5:永続化を再有効化して修正を確認する
根本原因が解決しましたか?安全設定を元に戻しましょう:
redis-cli CONFIG SET stop-writes-on-bgsave-error yes
手動でバックグラウンド保存をトリガーして、機能することを確認します:
# バックグラウンドRDB保存をトリガーする
redis-cli BGSAVE
# 少し待ってからタイムスタンプを確認する
redis-cli LASTSAVE
# Unixタイムスタンプを読みやすい日付に変換する
date -d @<timestamp>
ダンプファイルが実際にディスクに保存されたことを確認します:
ls -lh $(redis-cli CONFIG GET dir | tail -1)/dump.rdb
すべてがエンドツーエンドで機能していることを確認するために、簡単な書き込みテストを実行します:
redis-cli SET testkey "hello"
redis-cli GET testkey
# 返るべき値:"hello"
ステップ6:redis.confに修正を永続化する
CONFIG SETの変更はランタイム限定です——再起動すると消えます。再起動後も維持するためにredis.confに設定を固定しましょう:
# redis.confを探す
redis-cli CONFIG GET save
ls /etc/redis/redis.conf
# redis.confで確認すべき重要な設定:
# RDBファイルの保存場所——このパスが存在し、書き込み可能であることを確認する
dir /var/lib/redis
# RDB保存スケジュール(デフォルトは3つの条件で保存)
save 3600 1 # 少なくとも1つのキーが変更された場合、1時間後に保存
save 300 100 # 少なくとも100個のキーが変更された場合、5分後に保存
save 60 10000 # 少なくとも10000個のキーが変更された場合、1分後に保存
# 障害が見逃されないようにyesのままにしておく
stop-writes-on-bgsave-error yes
編集後にリロード——完全な再起動は不要です:
redis-cli CONFIG REWRITE # 現在のランタイム設定をファイルに書き戻す
sudo systemctl reload redis # または:redis-cli DEBUG RELOAD
RDBの永続化がまったく不要な場合
Redisを純粋にキャッシュとして使用していますか?永続化を完全に無効にすると、このエラーは発生しなくなります:
# すべてのRDBスナップショットを無効にする
redis-cli CONFIG SET save ""
# redis.confで、すべてのsaveの行をコメントアウトまたは削除する:
# save 3600 1
# save 300 100
# save 60 10000
保存スケジュールが設定されていなければ、Redisはバックグラウンド保存を試みません。この設定を変更する前に、再起動時のデータ損失がユースケースで許容できることを確認してください。
まとめ
- MISCONFエラーは
BGSAVEが失敗し、安全対策としてRedisが書き込みをブロックしたことを意味します。 CONFIG SET stop-writes-on-bgsave-error noを使って即座にアンブロックします。- 実際の問題を修正します:ディスクがいっぱい、データディレクトリのパーミッションが間違っている、またはディレクトリが存在しない。
BGSAVEの後にLASTSAVEで確認——タイムスタンプが更新されたことを確認します。- 設定変更を
redis.confに永続化して、再起動後も維持できるようにします。

