MISCONF Redis настроен на сохранение снимков RDB

Во время записи в Redis (SET foo bar) я получаю следующую ошибку:

MISCONF Redis настроен на сохранение снимков RDB, но в настоящее время не может сохраняться на диске. Команды, которые могут изменять набор данных, отключен. Чтобы узнать подробности об ошибке, просмотрите журналы Redis.

В основном я понимаю, что проблема в том, что redis не может сохранять данные на диске, но не имеет понятия, как избавиться от проблемы.

Также следующий вопрос имеет ту же проблему, он оставлен давным-давно без ответов и, скорее всего, не пытается решить проблему.

Ответ 1

Если вы столкнулись с ошибкой, и некоторые важные данные не могут быть отброшены на запущенном экземпляре 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 где-нибудь в безопасности.

Ответ 2

Используя redis-cli, вы можете остановить его, пытаясь сохранить снимок:

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

Это быстрый обходной путь, но если вы заботитесь о данных, для которых вы его используете, вам следует проверить, почему bgsave потерпел неудачу в первую очередь.

Ответ 3

В процессе bgsave могут возникнуть ошибки из-за низкой памяти. Попробуйте (из redis background save FAQ)

echo 'vm.overcommit_memory = 1' >> /etc/sysctl.conf
sysctl vm.overcommit_memory=1

Ответ 4

Слишком короткий ответ. открыть терминал и ввести следующие команды

redis-cli

и теперь введите

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

Ответ 5

Эта ошибка возникает из-за сбоя BGSAVE. Во время BGSAVE Redis разветвляет дочерний процесс для сохранения данных на диске. Хотя точную причину сбоя BGSAVE можно проверить из журналов (обычно в /var/log/redis/redis-server.log на компьютерах с Linux), но во многих случаях BGAVE дает сбой, потому что вилка не может выделить память. Много раз форк не может выделить память (хотя на машине достаточно ОЗУ) из-за противоречивой оптимизации ОС.

Как можно прочитать из Redis FAQ:

Схема фонового сохранения Redis опирается на семантику "копировать при записи" в современных операционных системах: Redis разветвляется (создает дочерний процесс), который является точной копией родительского. Дочерний процесс выгружает БД на диск и, наконец, завершает работу. Теоретически ребенок должен использовать столько же памяти, сколько родительский объект, являющийся копией, но фактически благодаря семантике "копирование при записи", реализованной большинством современных операционных систем, родительский и дочерний процессы будут совместно использовать страницы общей памяти. Страница будет продублирована только тогда, когда она изменяется в дочернем или родительском элементе. Поскольку теоретически все страницы могут изменяться во время сохранения дочернего процесса, Linux не может заранее определить, сколько памяти займет дочерний процесс, поэтому, если для параметра overcommit_memory задано нулевое значение, ветвь не будет работать, если не будет столько свободной оперативной памяти, сколько требуется действительно продублировать все родительские страницы памяти, в результате чего, если у вас есть набор данных Redis 3 ГБ и всего 2 ГБ свободной памяти, он потерпит неудачу.

Установка для overcommit_memory значения 1 говорит о том, что Linux расслабляется и выполняет разветвление более оптимистично, и это действительно то, что вам нужно для Redis.

Redis не требуется столько памяти, сколько операционная система думает, что она делает запись на диск, поэтому может превратиться в неудачу.

Чтобы решить это, вы можете:

Измените /etc/sysctl.conf и добавьте:

vm.overcommit_memory=1

Затем перезапустите sysctl с помощью:

На FreeBSD:

sudo /etc/rc.d/sysctl reload

В Linux:

sudo sysctl -p /etc/sysctl.conf

Ответ 6

если вы работаете на Linux-машине, также перепроверьте права доступа к файлам и папкам базы данных.

ДБ и путь к нему можно получить через:

в redis-cli:

CONFIG GET dir

CONFIG GET dbfilename

и в командной строке ls -l. Разрешения для каталога должны быть 755, а для файла должны быть 644. Кроме того, обычно redis-server выполняется как пользователь redis, поэтому его также приятно предоставить пользователю redis право собственности на папку, выполнив sudo chown -R redis:redis /path/to/rdb/folder. Это было разработано в ответе здесь.

Ответ 7

Спасибо всем за проверку проблемы, видимо, ошибка возникла во время bgsave.

Для меня, набрав config set stop-writes-on-bgsave-error no в оболочке и перезапустив Redis, решила проблему.

Ответ 8

Запустить Redis Server в каталоге, где у Redis есть разрешения на запись

Ответы выше определенно решают вашу проблему, но вот что происходит:

По умолчанию для хранения файла rdb.dump используется ./ (обозначающий текущий каталог). Вы можете проверить это в своем файле redis.conf. Поэтому каталог, с которого вы запускаете сервер redis, представляет собой файл dump.rdb, который будет создан и обновлен.

Кажется, вы запустили сервер redis в каталоге, где redis не имеет правильных разрешений для создания файла dump.rdb.

Чтобы усугубить ситуацию, redis также, вероятно, не позволит вам отключить сервер либо до тех пор, пока он не сможет создать файл rdb, чтобы обеспечить правильное сохранение данных.

Чтобы решить эту проблему, вы должны перейти в активную клиентскую среду redis с помощью redis-cli и обновить ключ dir и установить его значение в папку проекта или любую папку, в которой у root-root есть права на сохранение. Затем запустите BGSAVE, чтобы вызвать создание файла dump.rdb.

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

(Теперь, если вам нужно сохранить файл dump.rdb в каталоге, в котором вы запустили сервер, тогда вам нужно будет изменить разрешения для каталога, чтобы redis мог писать на него. Вы можете искать stackoverflow для того, чтобы для этого).

Теперь вы можете отключить сервер redis. Обратите внимание, что мы жестко закодировали путь. Hardcoding редко бывает хорошей практикой, и я настоятельно рекомендую запустить redis-сервер из вашего каталога проектов и изменить dir key back to./`.

CONFIG SET dir "./"
BGSAVE

Таким образом, когда вам нужно redis для другого проекта, файл дампа будет создан в вашем текущем каталоге проекта, а не в каталоге проекта с жестким кодом.

Ответ 9

Пожалуйста, проверьте здесь.

$ redis-cli
> config set stop-writes-on-bgsave-error no

Это может помочь решить эту проблему.

Ответ 10

Обнаружил эту ошибку и смог из журнала выяснить, что ошибка из-за нехватки места на диске. Все данные, которые были вставлены в моем случае, больше не были нужны. Поэтому я попытался сбросить. Поскольку процесс redis-rdb-bgsave был запущен, он также не позволял сбрасывать данные. Я выполнил следующие шаги и смог продолжить.

  1. Войдите в Redis клиент
  2. Выполнить конфигурацию set stop-write-on-bgsave-error no
  3. Выполните FLUSHALL (данные не нужны)
  4. Выполнить конфигурацию set stop-write-on-bgsave-error yes

Процесс redis-rdb-bgsave больше не выполнялся после описанных выше шагов.

Ответ 11

Более постоянное исправление может заключаться в том, чтобы посмотреть в /etc/redis/redis.conf вокруг строк 200-250, есть настройки для функций rdb, которые не были частью redis обратно в дни 2.x.

особенно

dir ./

можно изменить на

dir /home/someuser/redislogfiledirectory

или вы можете прокомментировать все строки сохранения и не беспокоиться о сохранении. (См. Комментарии в /etc/redis/redis.conf)

Кроме того, не забывайте

service redis-server stop
service redis-server start

Ответ 12

все эти ответы не объясняют причину сбоя сохранения rdb.


в моем случае я проверил журнал redis и обнаружил:

14975: M 18 Jun 13: 23: 07.354 # Сохранение фона прекращается сигналом 9

выполните следующую команду в терминале:

sudo egrep -i -r 'killed process' /var/log/

это дисплей:

/var/log/kern.log.1:18 июня 13:23:07 10-10-88-16 ядро: [28152358.208108] Убитый процесс 28416 (redis-сервер) total-vm: 7660204kB, anon-rss: 2285492kB, файл-Новости: 0Kb

вот оно что! этот процесс (redis save rdb) убит убийцей OOM

относится:

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

Поиск, какой процесс был убит Linux OOM Killer

Ответ 14

Я сталкивался с подобной проблемой, основной причиной этого было потребление памяти (RAM) redis. У моей машины EC2 было 8 ГБ оперативной памяти (около 7.4 доступно для потребления)

Когда моя программа работала, объем используемой оперативной памяти достигал 7,2 ГБ, оставляя едва ли ~ 100 МБ в ОЗУ, это обычно вызывает MISCONF Redis error...

Вы можете определить потребление оперативной памяти с помощью команды htop. Найдите атрибут Mem после выполнения команды htop. Если он показывает высокое потребление (как в моем случае это было 7,2 ГБ /7,4 ГБ), лучше обновить экземпляр с большей памятью. В этом сценарии использование config set stop-writes-on-bgsave-error no приведет к катастрофе на сервере и может привести к нарушению работы других служб на сервере (если таковые имеются). Так что лучше избегать команды config и ОБНОВЛЯТЬ ВАШУ REDIS MACHINE.

К вашему сведению: вам может понадобиться установить htop, чтобы это работало: sudo apt-get install htop

Еще одним решением этой проблемы может быть запуск какой-либо другой службы, интенсивно работающей с ОЗУ, работающей в вашей системе, проверьте, работает ли другая служба на вашем сервере/компьютере/экземпляре, и остановите ее, если в этом нет необходимости. Чтобы проверить все сервисы, работающие на вашем компьютере, используйте service --status-all

И предложение для людей, непосредственно вставляющих команду config, пожалуйста, немного пересмотрите программу и, по крайней мере, предупредите пользователя перед использованием таких команд. И как @Rodrigo упомянул в своем комментарии: "Не выглядит круто игнорировать ошибки".

Ответ 15

Я тоже столкнулся с той же проблемой. Оба ответа (наиболее одобренный и принятый) просто дают временное исправление для одного и того же.

Кроме того, config set stop-writes-on-bgsave-error no - это ужасный способ просмотреть эту ошибку, поскольку эта опция останавливает redis, уведомляя о том, что запись была остановлена, и продолжает работу без записи данных в снимок. Это просто игнорирование этой ошибки. Отослать это

Что касается установки dir в config в redis-cli, то после перезапуска службы redis это тоже должно быть очищено и снова появится та же ошибка. Значение по умолчанию для dir в redis.conf - ./, и если вы запускаете redis от имени пользователя root, то ./ - это / для которого права на запись не предоставлены, и, следовательно, ошибка.

Лучший способ - установить параметр dir в файле redis.conf и установить соответствующие разрешения для этого каталога. Большинство дистрибутивов Debian должны иметь его в /etc/redis/redis.conf

Ответ 16

В настоящее время проблемы с доступом для записи Redis, которые передают это сообщение об ошибке клиенту, вновь появились в официальных контейнерах redis.

Redis из официального образа redis пытается записать файл .rdb в папку Containers /data, что весьма прискорбно, поскольку это корневая папка, а также ее непостоянное расположение (записанные там данные исчезнут, если ваши сбой контейнера/контейнера).

Таким образом, после часа бездействия, если вы запустили свой контейнер redis от имени пользователя, не являющегося пользователем root (например, docker run -u 1007 вместо стандартного docker run -u 0), вы получите очень подробную ошибку msg на вашем сервере. log (см. 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

Таким образом, это неправильная конфигурация официального образа докера (который должен записывать в /tmp not /data), который производит эту "бомбу замедленного действия", с которой вы, скорее всего, столкнетесь только в производстве... в течение ночи в течение особенно тихих выходных:/

Ответ 17

Я столкнулся с этой проблемой при работе на сервере с дисковым пространством AFS, потому что мой токен аутентификации истек, что дало ответы Permission Denied, когда redis-server попытался сохранить. Я решил это, обновив свой токен:

kinit USERNAME_HERE -l 30d && aklog

Ответ 18

Как отметил @Chris, проблема, вероятно, будет низкой. Мы начали испытывать это, когда мы выделили слишком много ОЗУ для MySQL (innodb_buffer_pool_size).

Чтобы обеспечить достаточную RAM для Redis и других сервисов, мы сократили innodb_buffer_pool_size на MySQL.

Ответ 19

В моем случае причиной было очень мало свободного места на диске (всего 35 Мб). Я сделал следующее -

  1. Остановил все процессы, связанные с Redis
  2. Удалите некоторые файлы на диске, чтобы освободить достаточно места
  3. Удалить файл дампа Redis (если существующие данные не нужны)

    sudo rm/var/lib/redis/*

  4. Удалить все ключи всех существующих баз данных

    sudo redis-cli flushall

  5. перезапустите все задачи сельдерея и проверьте соответствующие журналы для любых проблем

Ответ 20

Если вы работаете с Redis локально на компьютере с Windows, попробуйте "запустить от имени администратора" и посмотрите, работает ли он. У меня проблема была в том, что Redis находился в папке "Program Files", которая по умолчанию ограничивает разрешения. Как это должно.

Однако не запускайте Redis автоматически от имени администратора. Вы не хотите предоставлять ему больше прав, чем он должен иметь. Вы хотите решить это с помощью книги.

Итак, мы смогли быстро выявить проблему, запустив ее от имени администратора, но это не лекарство. Вероятный сценарий состоит в том, что вы поместили Redis в папку, у которой нет прав на запись, и, как следствие, файл БД хранится в том же месте.

Вы можете решить эту проблему, открыв redis.windows.conf и 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 в папку, которая, как вы знаете, имеет необходимые разрешения.

Ответ 21

В случае, если вы используете docker/docker-compose и хотите предотвратить запись 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

Вы можете увидеть больше решений для удаления постоянных данных здесь

Ответ 22

Вы должны chmod и chown новую папку

chown -R redis и chmod...

Ответ 24

В моем случае это было связано с дисковым пространством. (вы можете проверить это с помощью команды df -h bash), когда я освобождаю место, эта ошибка исчезла.

Ответ 25

для меня

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

и я перезагружаю свой Mac, это работает

Ответ 26

Решение @Govind Rai 'сохранить файл dump.rdb в каталоге, в котором вы запустили сервер':

Щелкните правой кнопкой мыши папку Redis, выберите "Свойства" и перейдите на вкладку "Безопасность". Нажмите "Изменить", чтобы открыть диалоговое окно "Разрешения для".

Нажмите на все пакеты приложений

В поле "Разрешения для" установите флажок "Разрешить" "Полный доступ".