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 save save FAQ)

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

Ця помилка виникає через помилку BGSAVE. Під час BGSAVE Redis відсилає дочірній процес для збереження даних на диску. Хоча точну причину відмови BGSAVE можна перевірити з журналів (як правило, /var/log/redis/redis-server.logна машинах Linux), але багато разів BGAVE виходить з ладу, оскільки вилка не може виділити пам'ять. Багато разів вилка не в змозі виділити пам'ять (хоча машина має достатню кількість оперативної пам’яті) через конфліктну оптимізацію ОС.

Як можна прочитати з FAQ щодо Redis :

Схема збереження фонового зображення Redis покладається на семантику fork-write-fork у сучасних операційних системах: Redis forks (створює дочірній процес), що є точною копією батьківського. Дочірній процес скидає БД на диск і, нарешті, виходить. Теоретично дитина повинна використовувати стільки пам’яті, скільки батьків є копією, але насправді завдяки семантиці копіювання під час запису, впровадженій більшістю сучасних операційних систем, батько та дочірній процес поділяться спільними сторінками пам’яті. Сторінка буде дубльована лише тоді, коли вона зміниться у дитини або у батьків. Оскільки теоретично всі сторінки можуть змінюватися під час збереження дочірнього процесу, Linux не може заздалегідь сказати, скільки пам’яті займе дитина, тому якщо для параметра overcommit_memory встановлено нульовий форк, не вийде, якщо не буде стільки вільної оперативної пам’яті, скільки необхідний для дійсного копіювання всіх батьківських сторінок пам'яті,

Якщо встановити 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

Перезавантажте сервер redis.

• macOS (варити) : brew services restart redis.
• Linux: sudo service redis restart /sudo systemctl restart redis
• Windows: Windows + R-> Тип services.msc, Enter-> Пошук і Redisнатисніть наrestart .

У мене особисто виникло це питання після оновлення Redis до Brew ( brew upgrade). Після перезавантаження ноутбука він негайно спрацював.

якщо ви працюєте на машині Linux, також перевірте права доступу до файлів і папок бази даних.

ДБ та шлях до нього можна отримати за допомогою:

в redis-cli:

CONFIG GET реж

CONFIG GET dbfilename

і в командному рядку ls -l. Дозволи для каталогу повинні бути 755 , а для файлу - 644 . Крім того, звичайно redis-сервер виконується як користувач redis, тому також приємно надати користувачеві redisправо власності на папку шляхом виконання sudo chown -R redis:redis /path/to/rdb/folder. Це було розроблено у відповіді тут .

Дякуємо всім за перевірку проблеми, мабуть, помилка виникла протягом bgsave.

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

Запустіть Redis Server у каталог, де Redis має дозволи на запис

Відповіді вище, безумовно, вирішать вашу проблему, але ось що насправді відбувається:

Місце для зберігання rdb.dumpфайлу за замовчуванням ./(позначає поточну директорію). Ви можете підтвердити це у своєму redis.confфайлі. Тому каталог, з якого ви запускаєте сервер redis, - це те, де dump.rdbбуде створений і оновлений файл.

Здається, ви почали запускати сервер redis в каталозі, де redis не має правильних дозволів для створення dump.rdbфайлу.

Що ще гірше, Redis також, ймовірно, не дозволить вам відключити сервер, поки він не зможе створити файл rdb для забезпечення належного збереження даних.

Щоб вирішити цю проблему, ви повинні зайти в активне клієнтське середовище redis, використовуючи redis-cliта оновити dirключ, і встановити його значення в папці проекту або будь-якій папці, де не-root має дозволи зберегти. Потім запустіть, 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

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

Якщо ви працюєте з MacOS і нещодавно оновили до Каталіни, можливо, вам доведеться запустити, brew services restart redisяк запропоновано в цьому випуску .

Зустрівшись із цією помилкою і зміг зрозуміти з журналу, що помилка через те, що місця на диску не вистачає. Усі дані, які були вставлені в моєму випадку, більше не потрібні були. Тому я спробував ПЛАТИТИ. Оскільки процес redis-rdb-bgsave запускався, він також не давав змоги передавати дані. Я дотримувався нижче кроків і зміг продовжити.

1. Увійдіть до клієнта redis
2. Виконати налаштування налаштування stop-write-on-bgsave-error немає
3. Виконати FLUSHALL (Дані, які зберігаються, не потрібні)
4. Виконайте налаштування конфігурації stop-write-on-bgsave-error так

Процес redis-rdb-bgsave вже не виконувався після вищезазначених кроків.

Я зіткнувся з подібним питанням, основною причиною цього було споживання оперативної пам’яті Redis. Мій апарат EC2 мав 8 Гб оперативної пам’яті (arounf 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 .

FYI: Вам може знадобитися встановити htop, щоб зробити цю роботу:sudo apt-get install htop

Ще одне рішення цього може бути деяким іншим важким сервісом оперативної пам’яті, що працює у вашій системі, перевірте наявність іншої служби, що працює на вашому сервері / машині / екземплярі, та зупиніть її, якщо її немає необхідності. Щоб перевірити всі служби, що працюють на вашому пристроїservice --status-all

І пропозиція для людей, які безпосередньо вставляють команду config, будь-ласка, повторно дослідіть і принаймні попередити користувача перед використанням таких команд. І як згадував @Rodrigo у своєму коментарі: "Ігнорувати помилки не виглядає круто".

--- ОНОВЛЕННЯ ---

Ви також можете налаштувати maxmemoryта maxmemory-policyвизначити поведінку Redis, коли буде досягнуто певного обмеження пам’яті. Наприклад, якщо я хочу зберегти ліміт пам’яті в 6 Гб і видалити з БД найменше використовувані ключі, щоб переконатися, що використання повторної пам’яті не перевищує 6 ГБ, то ми можемо встановити ці два параметри (в redis.conf або CONFIG SET команда):

maxmemory 6gb
maxmemory-policy allkeys-lru

Є багато інших значень, які можна встановити для цих двох параметрів. Про це можна прочитати тут: https://redis.io/topics/lru-cache

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

помітно

dir ./

може бути змінено на

dir /home/someuser/redislogfiledirectory

або ви можете прокоментувати всі рядки збереження, і не турбуватися про наполегливість. (Дивіться коментарі в /etc/redis/redis.conf)

Також не забувайте

service redis-server stop
service redis-server start

всі ці відповіді не пояснюють причину невдалого збереження rdb.

як мій випадок, я перевірив журнал redis і виявив:

14975: M 18 червня 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, file-rss: 0kB

це все! цей процес (redis save rdb) вбивається вбивцею OOM

посилається:

https://github.com/antirez/redis/isissue/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це жахливий спосіб переглядати цю помилку, оскільки те, що ця опція робить, - це зупинити повторне повідомлення про те, що записи припинені, і продовжувати роботу, не записуючи дані на знімку. Це просто ігнорування цієї помилки. Зверніться до цього

Що стосується налаштування dirв configredis-cli, після перезапуску послуги redis це також буде очищено, і знову з’явиться така ж помилка. Значенням за замовчуванням dirв redis.confє ./, і якщо ви почнете редагувати як користувач root, то./ є , /до якого права на запис не надаються, і , отже , помилка.

Найкращий спосіб - встановити dirпараметр у файлі redis.conf і встановити належні дозволи для цього каталогу. Більшість дистрибутивів debian мають його мати/etc/redis/redis.conf

Нині проблеми з доступом до запису Redis, які дають це повідомлення про помилку клієнту, знову з’явилися в офіційних redisконтейнерах докера.

Редіс з офіційного redisзображення намагається записати файл .rdb у /dataпапку контейнерів , що дуже прикро, оскільки це папка, що належить root, і це також непостійне розташування (дані, записані там, зникнуть, якщо ваш контейнер / pod збої).

Отже, через годину бездіяльності, якщо ви запустили redisконтейнер як некоріозний користувач (наприклад, docker run -u 1007а не за замовчуванням docker run -u 0), ви отримаєте чітко детальну msg помилку у журналі свого сервера (див. 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не /data) дає такий "бомба часу", з якою ви, швидше за все, зіткнетесь лише у виробництві ... на ніч протягом особливо спокійних вихідних вихідних: /

для мене

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

і я перезавантажую свій Mac, він працює

Я зіткнувся з цією проблемою під час роботи на сервері з дисковим простором AFS, оскільки мій термін автентифікації закінчився, що дало Permission Deniedвідповіді, коли сервер redis намагався зберегти. Я вирішив це, оновивши маркер:

kinit USERNAME_HERE -l 30d && aklog

Якщо ви використовуєте 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

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

У моєму випадку це сталося тому, що я просто встановив, redisвикористовуючи швидкий спосіб. Отже, redis не працює як root. Мені вдалося вирішити цю проблему, дотримуючись вказівок, наведених у Installing Redis more properlyрозділі їх Короткого керівництва . Після цього проблема була вирішена і redisтепер вона працює як корінь. Перевір.

Після удару головою через стільки запитань ТА, нарешті - для мене відповідь @Axel Advento спрацювала, але з кількома додатковими кроками - я все ще стикався з питаннями дозволу.
Мені довелося переключити користувача redis, створити новий dir у його домашньому dir, а потім встановити його як redis's dir.

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 -hкомандою bash), коли я звільнив простір, ця помилка зникла.

Якщо ви запускаєте Redis локально на машині Windows, спробуйте "запустити як адміністратор" і подивіться, чи працює він. У мене проблема полягала в тому, що Redis знаходився в папці "Файли програм", яка обмежує дозволи за замовчуванням. Як слід.

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

Отже, нам вдалося швидко визначити проблему, запустивши її як адміністратора, але це не є лікуванням. Ймовірний сценарій полягає в тому, що ви помістили Redis в папку, яка не має прав на запис, і, як наслідок, файл БД зберігається в тому самому місці.

Ви можете вирішити це, відкривши 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, тому будьте уважні до того, що ви робите.

У моєму випадку на машині не вистачало оперативної пам’яті . Це також може статися, коли на хості більше немає вільного місця на диску .

Зауважте, що ця помилка з’являється, коли ваш сервер атакується. Щойно встановлено, що 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 (innodb_buffer_pool_size ).

Для забезпечення достатньої кількості оперативної пам’яті для Redis та інших сервісів ми скоротили innodb_buffer_pool_sizeна MySQL.

У моєму випадку причиною було дуже мало вільного місця на диску (всього 35 Мб). Я зробив наступне -

1. Припинено всі процеси, пов'язані з Redis
2. Видаліть деякі файли на диску, щоб забезпечити достатньо вільного місця

3. Видаліть файл перезавантажувального файлу (якщо наявні дані не потрібні)

   sudo rm /var/lib/redis/*

4. Видаліть усі ключі з усіх існуючих баз даних

   sudo redis-cli flushall

5. перезапустіть усі завдання із селери та перевірте відповідні журнали щодо будь-яких проблем

ви повинні chmod і замовити нову папку

chown -R redis and chmod ...