Redis на сервере: частые ошибки и решения

MAATRIX

Ошибки Redis на сервере обычно короткие и понятные, если знать, что за ними стоит. Ниже — разбор частых проблем: NOAUTH и WRONGPASS при авторизации, connection refused, отказ записи из-за нехватки памяти (OOM), ошибка MISCONF при сбое сохранения на диск и потеря данных после перезапуска. Для каждой сначала решение, потом причина — чтобы починить быстро и понять, как не повторять.

NOAUTH Authentication required

Ошибка NOAUTH Authentication required означает, что на Redis задан пароль (requirepass), а клиент его не передал. Это не поломка, а правильная защита. Решение — авторизоваться. В redis-cli это делается флагом или командой:

redis-cli -a ваш_пароль

Либо уже внутри сессии: AUTH ваш_пароль. В приложении пароль указывается в строке подключения или отдельным параметром конфигурации клиента. Если видите WRONGPASS invalid username-password pair — пароль неверный или вы используете Redis 6+ с ACL, где помимо пароля есть имя пользователя. По умолчанию имя default, и авторизация идёт формой AUTH default ваш_пароль. Проверьте, совпадает ли пароль в конфиге приложения с тем, что стоит в redis.conf в параметре requirepass.

Не убирайте пароль, чтобы «решить» эту ошибку — это открывает Redis для атак. Правильно синхронизировать пароль между сервером и клиентом, а не отключать защиту.

Could not connect: Connection refused

Could not connect to Redis at 127.0.0.1:6379: Connection refused — по адресу и порту никто не слушает. Сначала проверьте, запущена ли служба и на каком адресе она принимает подключения:

sudo systemctl status redis-server
sudo ss -ltnp | grep 6379

Если процесса нет — Redis не запущен, смотрите журнал sudo journalctl -u redis-server -n 50. Если Redis слушает только 127.0.0.1, а вы подключаетесь с другого сервера по внешнему адресу, дело в параметре bind. Добавьте нужный внутренний адрес в bind и перезапустите службу, но помните: открывать Redis наружу без фаервола и пароля нельзя.

Частая ловушка в контейнерах: приложение обращается к 127.0.0.1, подразумевая свой контейнер, а не хост или сервис Redis. В Docker используйте имя сервиса или адрес хоста, а не localhost. И проверьте, что порт не закрыт фаерволом между машинами — правило ufw должно явно разрешать доступ с адреса приложения.

OOM command not allowed

Ошибка OOM command not allowed when used memory > 'maxmemory' означает, что Redis достиг лимита памяти и при текущей политике не может освободить место под новые данные. Это происходит, когда maxmemory-policy установлена в noeviction, а память кончилась. Посмотрите текущее состояние:

redis-cli -a пароль INFO memory
redis-cli -a пароль CONFIG GET maxmemory-policy

Если Redis работает как кэш, переключите политику на вытеснение старых ключей: CONFIG SET maxmemory-policy allkeys-lru. Тогда при заполнении Redis будет удалять наименее используемые данные вместо возврата ошибки. Если же Redis хранит важные данные (очереди), которые нельзя терять, noeviction оставляют осознанно, и ошибка OOM — это сигнал, что памяти реально не хватает: нужно либо чистить данные, либо увеличить maxmemory, либо взять сервер с большим объёмом RAM.

Иногда лимит просто выставлен слишком низко относительно реальной нагрузки. Проверьте used_memory в INFO: если он близок к maxmemory постоянно, потолок пора поднимать вместе с памятью сервера.

MISCONF Redis is configured to save RDB snapshots

Длинная ошибка MISCONF Redis is configured to save RDB snapshots, but it's currently unable to persist to disk появляется, когда Redis не может сохранить снимок на диск и по умолчанию отказывается принимать записи, чтобы вы заметили проблему. Причина почти всегда — закончилось место на диске или нет прав на запись в каталог данных. Проверьте:

df -h
sudo ls -la /var/lib/redis

Освободите место на диске или исправьте права: каталог /var/lib/redis должен принадлежать пользователю redis. После устранения причины Redis снова начнёт сохранять снимки и принимать записи. Как временная мера можно отключить остановку записи параметром stop-writes-on-bgsave-error no, но это лечит симптом, а не причину — если сохранение падает, ваши данные не защищены от перезапуска, и настоящую проблему всё равно надо решать.

Данные пропадают после перезапуска

Redis перезапустился, и все данные исчезли — частый шок для тех, кто не настроил персистентность. По своей природе Redis держит данные в памяти, и если сохранение на диск отключено, при рестарте база пуста. Для кэша это нормально и даже ожидаемо. Но если вы хранили в Redis что-то ценное, нужно включить сохранение.

Откройте конфиг и убедитесь, что включён хотя бы один механизм персистентности — снимки RDB или журнал AOF:

appendonly yes
appendfsync everysec

Режим AOF с everysec записывает изменения в журнал раз в секунду, поэтому при перезапуске теряется максимум секунда данных. RDB делает периодические снимки по расписанию из директив save. Для важных данных включают оба механизма. Проверьте, что каталог данных доступен на запись и на диске есть место, иначе сохранение молча не сработает и вы снова потеряете данные при рестарте.

Redis тормозит или отваливается под нагрузкой

Redis очень быстр, и если он тормозит, причина обычно внешняя. Первое — нехватка памяти и активный swap: когда данные Redis вытесняются в swap на диск, скорость падает в десятки раз. Проверьте used_memory и swap на сервере. Второе — тяжёлые блокирующие команды вроде KEYS * на больших наборах: они однопоточно занимают сервер и подвешивают всех клиентов. В продакшене используйте SCAN вместо KEYS.

Третья частая причина замедлений — persistence, настроенная слишком агрессивно. Если appendfsync стоит в always, Redis сбрасывает на диск каждую запись и ждёт подтверждения, что резко режет скорость на медленном диске. Для подавляющего большинства задач правильный режим — everysec: он даёт почти ту же надёжность при в разы большей производительности. А сохранение снимка RDB на очень большой базе кратковременно нагружает сервер в момент форка процесса — если снимки совпадают с пиками трафика, разнесите их по времени или переходите на AOF.

Если Redis стабильно упирается в память или конкурирует за неё с другими службами, это честный сигнал, что серверу мало ресурсов. В MAATRIX можно быстро арендовать VPS в России, США или Великобритании с нужным объёмом RAM под Redis и перенести данные без спешки. Оплата — картой РФ, по СБП, криптой или токеном MAAT, иностранная карта не требуется.

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