MISCONF Redis jest skonfigurowany do zapisywania migawek RDB

Podczas zapisywania do Redis ( SET foo bar) pojawia się następujący błąd:

MISCONF Redis jest skonfigurowany do zapisywania migawek RDB, ale obecnie nie jest w stanie utrzymać się na dysku. Polecenia, które mogą modyfikować zestaw danych, są wyłączone. Sprawdź dzienniki Redis, aby uzyskać szczegółowe informacje na temat błędu.

Zasadniczo rozumiem, że problem polega na tym, że redis nie jest w stanie zapisać danych na dysku, ale nie mam pojęcia, jak pozbyć się problemu.

Również następujące pytanie ma ten sam problem, dawno temu zostało porzucone bez odpowiedzi i najprawdopodobniej bez prób rozwiązania problemu.

W przypadku wystąpienia błędu i niemożności odrzucenia niektórych ważnych danych w działającej instancji Redis (problemy z uprawnieniami do rdbpliku lub jego katalogu nieprawidłowo lub brak miejsca na dysku), zawsze możesz przekierować rdbplik, aby go zapisać w innym miejscu.

Za pomocą redis-climożesz zrobić coś takiego:

CONFIG SET dir /tmp/some/directory/other/than/var
CONFIG SET dbfilename temp.rdb

Następnie możesz wykonać BGSAVEpolecenie, aby upewnić się, że dane zostaną zapisane w rdbpliku. Upewnij się, że podczas wykonywania INFO persistence, bgsave_in_progressjuż jest 0i rdb_last_bgsave_statusjest ok. Następnie możesz rozpocząć tworzenie kopii zapasowej wygenerowanego rdbpliku w bezpiecznym miejscu.

Za pomocą redis-climożesz przerwać próbę zapisania migawki:

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

Jest to szybkie obejście, ale jeśli zależy Ci na danych, z których korzystasz, powinieneś sprawdzić, aby upewnić się, dlaczego bgsave zawiodło na pierwszym miejscu.

Mogą wystąpić błędy podczas procesu bgsave z powodu małej ilości pamięci. Wypróbuj to (z najczęściej zadawanych pytań o zapisywanie w tle Redis)

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

Ten błąd występuje z powodu niepowodzenia BGSAVE. Podczas BGSAVE Redis prosi proces potomny o zapisanie danych na dysku. Chociaż dokładny powód niepowodzenia BGSAVE można sprawdzić z dzienników (zwykle na komputerach /var/log/redis/redis-server.logz systemem Linux), ale wiele razy BGAVE zawodzi, ponieważ widelec nie może przydzielić pamięci. Wiele razy widelec nie przydziela pamięci (chociaż maszyna ma wystarczającą ilość dostępnej pamięci RAM) z powodu sprzecznej optymalizacji przez system operacyjny.

Jak można przeczytać w Redis FAQ :

Schemat zapisywania w tle Redis opiera się na semantyce kopiowania przy zapisie rozwidlenia we współczesnych systemach operacyjnych: Redis forks (tworzy proces potomny), który jest dokładną kopią elementu nadrzędnego. Proces potomny zrzuca DB na dysk i kończy działanie. Teoretycznie dziecko powinno zużywać tyle pamięci, ile rodzic jest kopią, ale w rzeczywistości dzięki semantyce kopiowania przy zapisie zaimplementowanej przez większość nowoczesnych systemów operacyjnych proces nadrzędny i potomny będą dzielić wspólne strony pamięci. Strona zostanie zduplikowana tylko wtedy, gdy zmieni się u dziecka lub rodzica. Ponieważ teoretycznie wszystkie strony mogą się zmieniać podczas zapisywania procesu potomnego, Linux nie może z góry powiedzieć, ile pamięci zajmie dziecko, więc jeśli ustawienie overcommit_memory jest ustawione na zero, rozwidlenie się nie powiedzie, chyba że będzie tyle wolnej pamięci RAM, co wymagane do prawdziwego skopiowania wszystkich stron pamięci nadrzędnej,

Ustawienie overcommit_memory na 1 mówi Linuxowi, aby się zrelaksował i wykonał rozwidlenie w bardziej optymistyczny sposób alokacji, i to jest właśnie to, czego chcesz dla Redis.

Redis nie potrzebuje tyle pamięci, ile system operacyjny uważa, że ​​zapisuje na dysk, więc może wyprzedzająco zawieść rozwidlenie.

Aby rozwiązać ten problem, możesz:

Zmodyfikuj /etc/sysctl.confi dodaj:

vm.overcommit_memory=1

Następnie uruchom ponownie sysctl za pomocą:

Na FreeBSD:

sudo /etc/rc.d/sysctl reload

W systemie Linux:

sudo sysctl -p /etc/sysctl.conf

Uruchom ponownie serwer Redis.

• Macos (piwny) : brew services restart redis.
• Linux: sudo service redis restart /sudo systemctl restart redis
• Windows: Windows + R-> Typ services.msc, Enter-> Wyszukaj, Redisa następnie kliknij restart.

Osobiście miałem ten problem po aktualizacji Redis za pomocą Brew ( brew upgrade). Po ponownym uruchomieniu laptopa od razu zadziałało.

jeśli pracujesz na komputerze z linuksem, sprawdź również uprawnienia do plików i folderów bazy danych.

Db i ścieżkę do niego można uzyskać poprzez:

w redis-cli:

CONFIG GET reż

CONFIG GET nazwa pliku db

i w wierszu poleceń ls -l. Uprawnienia do katalogu powinny wynosić 755 , a uprawnienia do pliku - 644 . Ponadto normalnie serwer redis działa jako użytkownik redis, dlatego dobrze jest też przekazać użytkownikowi rediswłasność folderu poprzez wykonanie sudo chown -R redis:redis /path/to/rdb/folder. Zostało to rozwinięte w odpowiedzi tutaj .

Dziękujemy wszystkim za sprawdzenie problemu, najwyraźniej wystąpił błąd podczas bgsave.

Dla mnie wpisanie config set stop-writes-on-bgsave-error nopowłoki i ponowne uruchomienie Redis rozwiązało problem.

Uruchom serwer Redis w katalogu, w którym Redis ma uprawnienia do zapisu

Powyższe odpowiedzi z pewnością rozwiążą Twój problem, ale oto, co się właściwie dzieje:

Domyślną lokalizacją do przechowywania rdb.dumppliku jest ./(oznaczający bieżący katalog). Możesz to sprawdzić w swoim redis.confpliku. Dlatego katalog, z którego uruchamiasz serwer redis, jest miejscem, w którym dump.rdbplik zostanie utworzony i zaktualizowany.

Wygląda na to, że zacząłeś uruchamiać serwer redis w katalogu, w którym redis nie ma odpowiednich uprawnień do utworzenia dump.rdbpliku.

Co gorsza, redis prawdopodobnie również nie pozwoli ci zamknąć serwera, dopóki nie będzie w stanie utworzyć pliku rdb, aby zapewnić prawidłowe zapisywanie danych.

Aby rozwiązać ten problem, musisz przejść do aktywnego środowiska klienta redis za pomocą redis-clii zaktualizować dirklucz oraz ustawić jego wartość w folderze projektu lub dowolnym folderze, w którym użytkownik inny niż root ma uprawnienia do zapisywania. Następnie uruchom, BGSAVEaby wywołać tworzenie dump.rdbpliku.

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

(Teraz, jeśli potrzeba , aby zapisać plik dump.rdb w katalogu, który rozpoczął się w serwer, a następnie będzie trzeba zmienić uprawnienia do katalogu, tak aby Redis można napisać do niego. Można wyszukiwać stackoverflow dla jak to zrobić ).

Teraz powinieneś być w stanie zamknąć serwer Redis. Zauważ, że zakodowaliśmy ścieżkę na stałe. Hardcoding jest rzadko dobrą praktyką i bardzo polecam uruchomienie serwera redis z katalogu projektu i zmianę dir key back to. / `.

CONFIG SET dir "./"
BGSAVE

W ten sposób, gdy potrzebujesz redis dla innego projektu, plik zrzutu zostanie utworzony w katalogu bieżącego projektu, a nie w katalogu projektu ścieżki zakodowanej na stałe.

Jeśli korzystasz z systemu MacOS i niedawno dokonałeś aktualizacji do Cataliny, może być konieczne uruchomienie brew services restart rediszgodnie z sugestią tego problemu .

Napotkałem ten błąd i mogłem dowiedzieć się z dziennika, że ​​błąd wynika z niewystarczającej ilości miejsca na dysku. Wszystkie dane, które zostały wstawione do mojej skrzynki, nie były już potrzebne. Więc próbowałem FLUSHALL. Ponieważ proces redis-rdb-bgsave był uruchomiony, nie pozwalał również na FLUSH danych. Wykonałem poniższe kroki i mogłem kontynuować.

1. Zaloguj się do klienta redis
2. Wykonaj zestaw konfiguracyjny stop-writes-on-bgsave-error no
3. Uruchom FLUSHALL (przechowywane dane nie były potrzebne)
4. Wykonaj zestaw konfiguracyjny stop-writes-on-bgsave-error yes

Proces redis-rdb-bgsave nie działał już po powyższych krokach.

Napotkałem podobny problem, głównym powodem tego było zużycie pamięci (RAM) przez redis. Moja maszyna EC2 miała 8 GB pamięci RAM (około 7,4 dostępnych do konsumpcji)

Gdy mój program działał, zużycie pamięci RAM wzrosło do 7,2 GB, pozostawiając prawie ~ 100 MB pamięci RAM, co ogólnie powoduje uruchomienie MISCONF Redis error ...

Możesz określić zużycie pamięci RAM za pomocą htoppolecenia. Poszukaj atrybutu Mem po uruchomieniu polecenia htop. Jeśli pokazuje wysokie zużycie (tak jak w moim przypadku było to 7,2 GB / 7,4 GB) Lepiej jest zaktualizować instancję o większą pamięć. W tym scenariuszu korzystanie config set stop-writes-on-bgsave-error nobędzie katastrofą dla serwera i może spowodować zakłócenie działania innych usług działających na serwerze (jeśli występują). Lepiej więc uniknąć polecenia config i ULEPSZ SWOJĄ REDIS MACHINE .

FYI: Może być konieczne zainstalowanie htop, aby to działało:sudo apt-get install htop

Jeszcze jednym rozwiązaniem tego problemu może być inna usługa o dużej pojemności pamięci RAM działająca w systemie, sprawdź inną usługę działającą na serwerze / maszynie / instancji i zatrzymaj ją, jeśli nie jest to konieczne. Aby sprawdzić wszystkie usługi uruchomione na twoim komputerze, użyjservice --status-all

I sugestia dla osób bezpośrednio wklejających polecenie config, proszę ponownie przeszukać i przynajmniej ostrzec użytkownika przed użyciem takich poleceń. I jak wspomniał @Rodrigo w swoim komentarzu: „Zignorowanie błędów nie jest fajne”.

---AKTUALIZACJA---

Możesz także skonfigurować maxmemoryi maxmemory-policyzdefiniować zachowanie Redis po osiągnięciu określonego limitu pamięci. Na przykład, jeśli chcę zachować limit pamięci 6 GB i usunąć ostatnio używane klucze z DB, aby upewnić się, że użycie pamięci redis nie przekracza 6 GB, możemy ustawić te dwa parametry (w redis.conf lub CONFIG SET Komenda):

maxmemory 6gb
maxmemory-policy allkeys-lru

Istnieje wiele innych wartości, które możesz ustawić dla tych dwóch parametrów, o których możesz przeczytać tutaj: https://redis.io/topics/lru-cache

Bardziej trwałym rozwiązaniem może być sprawdzenie w /etc/redis/redis.conf wokół linii 200-250, istnieją ustawienia dla funkcji rdb, które nie były częścią redis w 2.x dniach.

szczególnie

dir ./

można zmienić na

dir /home/someuser/redislogfiledirectory

lub możesz skomentować wszystkie wiersze zapisu i nie martwić się o trwałość. (Zobacz komentarze w /etc/redis/redis.conf)

Nie zapomnij też

service redis-server stop
service redis-server start

wszystkie te odpowiedzi nie wyjaśniają przyczyny niepowodzenia zapisu rdb.

w moim przypadku sprawdziłem dziennik redis i znalazłem:

14975: M 18 czerwca 13: 23: 07.354 # Zapisywanie w tle zakończone sygnałem 9

uruchom następującą komendę w terminalu:

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

wyświetla:

/var/log/kern.log.1:16 czerwca 13:23:07 10-10-88-16 jądro: [28152358.208108] Zabity proces 28416 (serwer redis) total-vm: 7660204kB, anon-rss: 2285492kB, plik-rss: 0kB

to jest to! ten proces (redis save rdb) zostaje zabity przez zabójcę OOM

odnosi się:

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

Ustalenie, który proces został zabity przez zabójcę Linux OOM

FWIW, natknąłem się na to i rozwiązaniem było po prostu dodanie pliku wymiany do pudełka. Zastosowałem tę metodę: https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04

Ja też miałem do czynienia z tym samym problemem. Obie odpowiedzi (najbardziej uprzywilejowana i zaakceptowana) dają tymczasową naprawę tego samego.

Co więcej, config set stop-writes-on-bgsave-error nojest to okropny sposób, aby przeoczyć ten błąd, ponieważ to, co robi ta opcja, to powstrzymanie redis od powiadamiania, że ​​zapisy zostały zatrzymane i przejście bez zapisywania danych w migawce. To po prostu ignoruje ten błąd. Zobacz to

Jeśli chodzi o ustawienie dirw configredis-cli, po ponownym uruchomieniu usługi redis, to również zostanie wyczyszczone i ponownie pojawi się ten sam błąd. Domyślna wartość dirin redis.confto ./, a jeśli zaczniesz redis jako użytkownik root, ./to /do których uprawnień do zapisu nie są przyznawane, i stąd błąd.

Najlepszym sposobem jest ustawienie dirparametru w pliku redis.conf i ustawienie odpowiednich uprawnień do tego katalogu. Większość dystrybucji Debiana powinna to mieć/etc/redis/redis.conf

W dzisiejszych czasach problemy z dostępem do zapisu w Redis, które dają ten komunikat o błędzie klientowi, pojawiły się ponownie w oficjalnych rediskontenerach dokerów.

Redis z oficjalnego redisobrazu próbuje zapisać plik .rdb w /datafolderze pojemników , co jest raczej niefortunne, ponieważ jest to folder będący własnością root i również nietrwałe położenie (zapisane tam dane znikną, jeśli twój kontener / pod awarie).

Więc po godzinie bezczynności, jeśli uruchomiłeś rediskontener jako użytkownik inny niż root (np. docker run -u 1007Zamiast domyślnego docker run -u 0), otrzymasz log szczegółowy błędu w dzienniku serwera (patrz 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

Musisz więc zamapować /datafolder kontenera na lokalizację zewnętrzną (gdzie użytkownik inny niż root, tutaj: 1007, ma dostęp do zapisu, na przykład /tmpna komputerze hosta), np .:

docker run --rm -d --name redis -p 6379:6379 -u 1007 -v /tmp:/data redis

Więc jest to błąd konfiguracji obrazu oficjalny Döcker (który powinien napisać do /tmpnie /data), która produkuje tę „bombę zegarową”, które najprawdopodobniej spotkanie tylko w produkcji ... noc nad jakimś szczególnie cichej weekendu: /

dla mnie

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

i ponownie ładuję komputer Mac, to działa

Wystąpił ten problem podczas pracy na serwerze z miejscem na dysku AFS, ponieważ mój token uwierzytelnienia wygasł, co dało Permission Deniedodpowiedzi, gdy serwer redis próbował zapisać. Rozwiązałem to, odświeżając mój token:

kinit USERNAME_HERE -l 30d && aklog

Jeśli używasz Dockera / Docker-Compose i chcesz uniemożliwić redisowi zapisywanie do pliku, możesz utworzyć konfigurację redis i zamontować w kontenerze

docker.compose.override.yml

  redis:¬
      volumes:¬
        - ./redis.conf:/usr/local/etc/redis/redis.conf¬
      ports:¬
        - 6379:6379¬

Możesz pobrać domyślną konfigurację stąd

w pliku redis.conf upewnij się, że skomentowałeś te 3 linie

save 900 1
save 300 10
save 60 10000

Myou można zobaczyć więcej rozwiązań do usuwania uporczywych dane tutaj

W moim przypadku stało się tak, ponieważ właśnie zainstalowałem redisw szybki sposób. Więc redis nie działa jako root. Byłem w stanie rozwiązać ten problem, postępując zgodnie z instrukcjami podanymi w Installing Redis more properlyczęści ich Przewodnika szybkiego startu . Po wykonaniu tej czynności problem został rozwiązany i redisdziała teraz jako root. Sprawdź to.

Po tym, jak w końcu uderzyłem się w tak wiele pytań SO - dla mnie odpowiedź @Axel Advento zadziałała, ale z kilkoma dodatkowymi krokami - wciąż miałem problemy z pozwoleniami.
Musiałem zmienić użytkownika redis, utworzyć nowy katalog w katalogu domowym, a następnie ustawić go jako katalog redis.

sudo su - redis -s /bin/bash
mkdir redis_dir
redis-cli CONFIG SET dir $(realpath redis_dir)
exit # to logout from redis user (optional)

W moim przypadku było to związane z wolnym miejscem na dysku. (można to sprawdzić za pomocą df -hpolecenia bash), gdy zwolnię trochę miejsca, ten błąd zniknął.

Jeśli uruchamiasz Redis lokalnie na komputerze z systemem Windows, spróbuj „uruchomić jako administrator” i sprawdź, czy działa. Problem ze mną polegał na tym, że Redis znajdował się w folderze „Program Files”, co domyślnie ogranicza uprawnienia. Jak powinno.

Nie uruchamiaj jednak automatycznie Redis jako administrator. Nie chcesz przyznawać mu więcej praw, niż powinno. Chcesz rozwiązać ten problem przez książkę.

Tak więc byliśmy w stanie szybko zidentyfikować problem, uruchamiając go jako administrator, ale to nie jest lekarstwo. Prawdopodobnym scenariuszem jest umieszczenie Redis w folderze, który nie ma uprawnień do zapisu, w wyniku czego plik DB jest przechowywany w tej samej lokalizacji.

Możesz rozwiązać ten problem, otwierając redis.windows.confi, aby wyszukać następującą konfigurację:

    # 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 ./

Przejdź dir ./do ścieżki, dla której masz regularne uprawnienia do odczytu / zapisu

Możesz także przenieść folder Redis w całości do folderu, o którym wiesz, że ma odpowiednie uprawnienia.

Dla mnie był to po prostu problem uprawnień do stałego folderu danych redis. Dałem to:

chmod 777 -Rf data/

I to działa! Być może jest już za wcześnie, aby powiedzieć, że to rozwiązało problem. Ponieważ podejrzewam również, że redis nie wykonuje się jako root, dlatego muszę sprawdzić mój plik dockerFile, aby dowiedzieć się więcej.

Sprawdź dziennik Redis przed podjęciem jakichkolwiek działań. Niektóre rozwiązania w tym wątku mogą skasować dane Redis, więc uważaj na to, co robisz.

W moim przypadku w maszynie zabrakło pamięci RAM . Może się to również zdarzyć, gdy na hoście nie ma już wolnego miejsca na dysku .

Należy pamiętać, że ten błąd pojawia się, gdy serwer jest atakowany. Właśnie odkryłem, że redis nie zapisuje do '/etc/cron.d/web', gdzie po poprawieniu uprawnień dodano nowy plik składający się z algorytmu wyszukiwania z pewnymi opcjami ukrywania.

# 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

Jak zauważył @Chris, problem może być zbyt niski. Zaczęliśmy go doświadczać, gdy przydzieliliśmy zbyt dużo pamięci RAM MySQL (innodb_buffer_pool_size ).

Aby zapewnić wystarczającą ilość pamięci RAM dla Redis i innych usług, które zredukowaliśmy innodb_buffer_pool_sizena MySQL.

W moim przypadku przyczyną było bardzo mało wolnego miejsca na dysku (tylko 35 Mb). Zrobiłem następujące -

1. Zatrzymano wszystkie procesy związane z Redis
2. Usuń niektóre pliki z dysku, aby uzyskać wystarczającą ilość wolnego miejsca

3. Usuń plik zrzutu redis (jeśli istniejące dane nie są potrzebne)

   sudo rm /var/lib/redis/*

4. Usuń wszystkie klucze wszystkich istniejących baz danych

   sudo redis-cli flushall

5. zrestartuj wszystkie zadania selera i sprawdź odpowiednie dzienniki pod kątem problemów

musisz chmod i przejrzeć nowy folder

chown -R redis i chmod ...