Redis: ошибка MISCONF — причины и решение

MAATRIX

Приложение внезапно перестаёт писать в базу, а Redis отвечает длинной ошибкой: MISCONF Redis is configured to save RDB snapshots, but it is currently not able to persist on disk. Redis ошибка MISCONF — это не про подключение, а про сохранение: Redis не смог записать снимок на диск и в целях безопасности заблокировал все записи. Разберём, почему сохранение падает и как вернуть базе возможность принимать данные, устранив корень проблемы, а не заглушив симптом.

Что означает MISCONF и почему блокируются записи

MISCONF появляется, когда у Redis включены RDB-снимки, но фоновое сохранение (BGSAVE) завершилось ошибкой. Логика такая: если Redis не может сохранить данные на диск, то при следующем перезапуске всё, что накопилось в памяти, пропадёт. Чтобы вы не потеряли данные незаметно, Redis намеренно блокирует новые записи и громко сообщает о проблеме — это защитный механизм, а не поломка самого Redis.

Отсюда вывод: MISCONF — это всегда симптом того, что запись снимка на диск не удалась. Причина почти всегда в одном из трёх: нет места на диске, нет прав на каталог сохранения, или каталог/путь недоступен. Реже — проблемы с самим диском или SELinux. Задача не в том, чтобы «убрать сообщение», а в том, чтобы Redis снова смог сохранять. Как только сохранение пройдёт, блокировка записей снимется автоматически.

Смотрим статус сохранения

Начните с диагностики: Redis прямо говорит, что последнее сохранение провалилось. Загляните в статус персистентности и в лог.

redis-cli INFO persistence | grep -E 'rdb_last_bgsave_status|rdb_last_save_time|aof_last_write_status'
tail -30 /var/log/redis/redis-server.log

Значение rdb_last_bgsave_status:err подтверждает, что снимок не сохранился. В логе Redis обычно есть более конкретная строка: Failed opening the RDB file, No space left on device, Permission denied. Именно она называет настоящую причину. Не спешите менять настройки — сначала прочитайте, что не так с диском или правами, потому что MISCONF лишь следствие, а лечить надо источник.

Причина первая: закончилось место на диске

Самая частая причина — раздел, куда Redis пишет снимок, заполнен. BGSAVE не может создать файл, сохранение падает, и включается блокировка. Проверьте свободное место на разделе с каталогом dir.

redis-cli CONFIG GET dir
df -h /var/lib/redis
du -sh /var/lib/redis/*

Если диск заполнен под завязку — освободите место. Виновником часто оказывается сам Redis: разросшийся AOF-файл, старые снимки, а иногда посторонние логи и мусор на том же разделе. Удалите ненужное, при необходимости выполните перезапись AOF для его компактизации:

redis-cli BGREWRITEAOF

Помните и о специфике BGSAVE: он форкает процесс, и в пик сохранения может потребоваться заметный объём и памяти, и места под временный файл снимка. Оставляйте на разделе запас, кратно превышающий размер базы, иначе сохранение будет падать именно на пике. После освобождения места форсируйте снимок вручную (см. ниже) — MISCONF снимется.

Причина вторая: права на каталог

Если места достаточно, а в логе Permission denied — Redis (процесс от пользователя redis) не может писать в каталог dir. Так бывает после ручного вмешательства в файлы, восстановления из бэкапа под root или смены каталога сохранения.

ls -ld /var/lib/redis
ls -l /var/lib/redis/dump.rdb
id redis

Каталог и файлы снимка должны принадлежать пользователю, под которым работает Redis. Исправьте владельца и права:

chown -R redis:redis /var/lib/redis
chmod 750 /var/lib/redis

На системах с SELinux (CentOS/RHEL) даже при верных Unix-правах запись может блокироваться политикой — тогда в audit-логе будет отказ. Восстановите контекст: restorecon -Rv /var/lib/redis. Не отключайте SELinux целиком ради этого — правильный контекст решает проблему точечно. После исправления прав Redis снова сможет сохранять.

Снимаем блокировку и проверяем

Устранив истинную причину (место или права), заставьте Redis сохранить снимок и убедитесь, что статус стал ok. Успешное сохранение автоматически разблокирует записи.

redis-cli BGSAVE
redis-cli INFO persistence | grep rdb_last_bgsave_status
# должно стать rdb_last_bgsave_status:ok
redis-cli SET test 1     # запись снова проходит

Если BGSAVE прошёл и статус ok — проблема решена, MISCONF больше не появится. Если снова err — вернитесь к логу, причина не устранена: возможно, место кончилось опять или права слетели не на тот файл. Не переходите к следующему шагу, пока сохранение реально не проходит; иначе вы лишь замаскируете проблему, а данные останутся под угрозой при рестарте.

Временный обход и когда он оправдан

Есть параметр, который отключает саму блокировку записей при неудачном сохранении. Использовать его как «решение» опасно, но в редких случаях он оправдан.

redis-cli CONFIG SET stop-writes-on-bgsave-error no

Это говорит Redis: продолжай принимать записи, даже если снимок не сохраняется. Оправдано лишь в одном сценарии — когда Redis у вас чистый кэш, данные которого не жалко, и персистентность вам вообще не нужна; тогда логичнее и вовсе отключить RDB (save ""). Во всех остальных случаях этот параметр — не решение, а глушилка: вы снимаете предупреждение, но данные по-прежнему не сохраняются и пропадут при перезапуске. Честный путь — устранить причину (место, права), а не отключать защиту. Если отключили ради экстренного восстановления работы, обязательно вернитесь и почините сохранение, иначе однажды потеряете всё содержимое базы.

Профилактика

Чтобы MISCONF не повторялся, следите за тремя вещами. Мониторьте свободное место на разделе с данными Redis и заведите алерт при заполнении выше 80% — это ловит проблему до блокировки. Держите права на каталог dir за пользователем redis и не трогайте файлы снимков под root. Контролируйте размер AOF и базы, чтобы диск не переполнялся ростом самих данных.

# в мониторинг: место и статус последнего сохранения
df -h /var/lib/redis | tail -1
redis-cli INFO persistence | grep rdb_last_bgsave_status

Заложите на разделе с данными запас с учётом форка при сохранении. На сервере с достаточным диском, корректными правами и мониторингом места ошибка MISCONF просто не возникает — она почти всегда сигнал о том, что за ресурсами не следили. Для растущей базы выбирайте конфигурацию с запасом по диску заранее.

Частые вопросы