MISCONF Redis è configurato per salvare le istantanee RDB

Durante le scritture su Redis ( SET foo bar) ricevo il seguente errore:

MISCONF Redis è configurato per salvare le istantanee RDB, ma al momento non è in grado di persistere sul disco. I comandi che possono modificare il set di dati sono disabilitati. Controllare i log di Redis per i dettagli sull'errore.

Fondamentalmente capisco che il problema è che redis non è in grado di salvare i dati sul disco, ma non ho idea di come sbarazzarsi del problema.

Anche la seguente domanda ha lo stesso problema, è stata abbandonata molto tempo fa senza risposte e molto probabilmente senza tentativi di risolvere il problema.

Nel caso in cui si verifichi l'errore e alcuni dati importanti non possano essere scartati sull'istanza redis in esecuzione (problemi con le autorizzazioni per il rdbfile o la sua directory in modo errato o lo spazio su disco insufficiente), è sempre possibile reindirizzare il rdbfile da scrivere altrove.

Usando redis-cli, puoi fare qualcosa del genere:

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

Successivamente, potresti voler eseguire un BGSAVEcomando per assicurarti che i dati vengano scritti nel rdbfile. Assicurarsi che quando si esegue INFO persistence, bgsave_in_progressè già 0ed rdb_last_bgsave_statusè ok. Successivamente, ora puoi iniziare a eseguire il backup del rdbfile generato in un luogo sicuro.

Utilizzando redis-cli, puoi fermarlo provando a salvare l'istantanea:

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

Questa è una soluzione rapida, ma se ti preoccupi dei dati per cui li stai usando, dovresti verificare per prima cosa perché bgsave non è riuscito.

Potrebbero esserci errori durante il processo bgsave a causa della memoria insufficiente. Prova questo (dalle domande frequenti sul salvataggio in background di redis)

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

Questo errore si verifica a causa del fallimento di BGSAVE. Durante BGSAVE, Redis esegue un processo figlio per salvare i dati sul disco. Anche se la ragione esatta del fallimento di BGSAVE può essere verificata dai log (di solito /var/log/redis/redis-server.logsu macchine linux), ma molte volte BGAVE non riesce perché il fork non può allocare memoria. Molte volte il fork non riesce ad allocare memoria (sebbene la macchina abbia abbastanza RAM disponibile) a causa di un'ottimizzazione contrastante da parte del sistema operativo.

Come si può leggere dalle FAQ di Redis :

Lo schema di salvataggio in background di Redis si basa sulla semantica della fork di copia su scrittura nei moderni sistemi operativi: forcelle Redis (crea un processo figlio) che è una copia esatta del genitore. Il processo figlio esegue il dump del DB su disco e alla fine si chiude. In teoria il bambino dovrebbe usare tutta la memoria di cui il genitore è una copia, ma in realtà grazie al semantico copia-scrittura implementato dalla maggior parte dei sistemi operativi moderni il processo genitore e figlio condivideranno le pagine di memoria comuni. Una pagina verrà duplicata solo quando cambia nel figlio o nel genitore. Poiché in teoria tutte le pagine possono cambiare mentre il processo figlio sta salvando, Linux non può dire in anticipo quanta memoria occuperà il bambino, quindi se l'impostazione overcommit_memory è impostata su zero fork fallirà a meno che non ci sia tanta RAM libera quanto richiesto per duplicare davvero tutte le pagine di memoria principale,

Impostando overcommit_memory su 1, Linux si rilassa ed esegue il fork in modo più ottimistico, e questo è davvero ciò che desideri per Redis.

Redis non ha bisogno di tanta memoria come pensa il sistema operativo per scrivere su disco, quindi potrebbe fallire preventivamente il fork.

Per risolvere il problema, puoi:

Modifica /etc/sysctl.confe aggiungi:

vm.overcommit_memory=1

Quindi riavviare sysctl con:

Su FreeBSD:

sudo /etc/rc.d/sysctl reload

Su Linux:

sudo sysctl -p /etc/sysctl.conf

Riavvia il tuo server redis.

• MacOs (birra) : brew services restart redis.
• Linux: sudo service redis restart /sudo systemctl restart redis
• Windows: Windows + R-> Tipo services.msc, Enter-> Cerca Redisquindi fare clic su restart.

Personalmente ho avuto questo problema dopo aver aggiornato redis con Brew ( brew upgrade). Dopo aver riavviato il laptop, ha funzionato immediatamente.

nel caso in cui si stia lavorando su una macchina linux, ricontrollare anche le autorizzazioni per file e cartelle del database.

Il db e il percorso ad esso possono essere ottenuti tramite:

in redis-cli:

CONFIG OTTIENI dir

CONFIG OTTIENI dbfilename

e nella riga di comando ls -l. Le autorizzazioni per la directory dovrebbero essere 755 e quelle per il file dovrebbero essere 644 . Inoltre, normalmente redis-server viene eseguito come utente redis, quindi è anche bello dare all'utente redisla proprietà della cartella eseguendola sudo chown -R redis:redis /path/to/rdb/folder. Questo è stato elaborato nella risposta qui .

Grazie a tutti per aver verificato il problema, apparentemente l'errore è stato prodotto durante bgsave.

Per me, digitare config set stop-writes-on-bgsave-error nouna shell e riavviare Redis ha risolto il problema.

Avviare Redis Server in una directory in cui Redis dispone delle autorizzazioni di scrittura

Le risposte sopra risolveranno sicuramente il tuo problema, ma ecco cosa sta realmente succedendo:

Il percorso predefinito per l'archiviazione del rdb.dumpfile è ./(che indica la directory corrente). Puoi verificarlo nel tuo redis.conffile. Pertanto, la directory da cui si avvia il server redis è la posizione in cui dump.rdbverrà creato e aggiornato un file.

Sembra che tu abbia iniziato a eseguire il server redis in una directory in cui redis non ha i permessi corretti per creare il dump.rdbfile.

A peggiorare le cose, probabilmente redis non ti consentirà nemmeno di spegnere il server fino a quando non sarà in grado di creare il file rdb per garantire il corretto salvataggio dei dati.

Per risolvere questo problema, è necessario accedere all'ambiente client redis attivo utilizzando redis-clie aggiornare la dirchiave e impostarne il valore sulla cartella del progetto o su qualsiasi cartella in cui non sono disponibili autorizzazioni per il salvataggio. Quindi eseguire BGSAVEper richiamare la creazione del dump.rdbfile.

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

(Ora, se è necessario salvare il file dump.rdb nella directory in cui è stato avviato il server, sarà necessario modificare le autorizzazioni per la directory in modo che Redis possa scrivere su di essa. È possibile cercare stackoverflow come farlo ).

Ora dovresti essere in grado di chiudere il server Redis. Nota che abbiamo codificato il percorso. L'hardcoding è raramente una buona pratica e consiglio vivamente di avviare il server redis dalla directory del progetto e di modificare dir key back to. / `.

CONFIG SET dir "./"
BGSAVE

In questo modo quando è necessario redis per un altro progetto, il file di dump verrà creato nella directory del progetto corrente e non nella directory del progetto del percorso hardcoded.

Se stai utilizzando MacOS e hai recentemente aggiornato a Catalina, potresti dover eseguire brew services restart rediscome suggerito in questo problema .

Aveva riscontrato questo errore ed è stato in grado di capire dal registro che l'errore è dovuto allo spazio su disco non sufficiente. Tutti i dati inseriti nel mio caso non erano più necessari. Quindi ho provato a FLUSHALL. Poiché il processo redis-rdb-bgsave era in esecuzione, non consentiva anche di FLUSH i dati. Ho seguito i passaggi seguenti e sono stato in grado di continuare.

1. Accedi al client redis
2. Eseguire il set di configurazione stop-write-on-bgsave-error no
3. Esegui FLUSHALL (i dati memorizzati non erano necessari)
4. Eseguire config set stop-write-on-bgsave-error sì

Il processo redis-rdb-bgsave non era più in esecuzione dopo i passaggi precedenti.

Ho affrontato il problema simile, il motivo principale dietro questo era il consumo di memoria (RAM) da parte di Redis. La mia macchina EC2 aveva 8 GB di RAM (arounf 7.4 disponibile per il consumo)

Quando il mio programma era in esecuzione, l'utilizzo della RAM è salito a 7,2 GB lasciando quasi ~ 100 MB in RAM, in genere ciò provoca MISCONF Redis error ...

È possibile determinare il consumo di RAM usando il htopcomando Cerca l' attributo Mem dopo aver eseguito il comando htop. Se mostra un consumo elevato (come nel mio caso era 7,2 GB / 7,4 GB) È meglio aggiornare l'istanza con una memoria più grande. In questo scenario l'utilizzo config set stop-writes-on-bgsave-error nosarà un disastro per il server e potrebbe comportare l'interruzione di altri servizi in esecuzione sul server (se presenti). Quindi, è meglio evitare il comando di configurazione e AGGIORNARE LA MACCHINA REDIS .

Cordiali saluti: Potrebbe essere necessario installare htop per farlo funzionare:sudo apt-get install htop

Un'altra soluzione a questo può essere un altro servizio pesante RAM in esecuzione sul sistema, verificare la presenza di altri servizi in esecuzione sul server / macchina / istanza e arrestarlo se non è necessario. Per controllare tutti i servizi in esecuzione sulla macchina, utilizzareservice --status-all

E un suggerimento per le persone che incollano direttamente il comando config, per favore fai un po 'di ricerca e almeno avvisa l'utente prima di usare tali comandi. E come ha detto @Rodrigo nel suo commento: "Non sembra bello ignorare gli errori".

---AGGIORNARE---

È inoltre possibile configurare maxmemorye maxmemory-policydefinire il comportamento di Redis quando viene raggiunto un limite specifico di memoria. Ad esempio, se voglio mantenere il limite di memoria di 6 GB ed eliminare dal DB le chiavi utilizzate meno di recente per accertarmi che l'utilizzo di redis mem non superi i 6 GB, possiamo impostare questi due parametri (in redis.conf o CONFIG SET comando):

maxmemory 6gb
maxmemory-policy allkeys-lru

Ci sono molti altri valori che puoi impostare per questi due parametri che puoi leggere su questo da qui: https://redis.io/topics/lru-cache

Una correzione più permanente potrebbe essere quella di guardare in /etc/redis/redis.conf intorno alle righe 200-250 ci sono impostazioni per le funzionalità rdb, che non facevano parte del redis nei giorni 2.x.

segnatamente

dir ./

può essere modificato in

dir /home/someuser/redislogfiledirectory

oppure potresti commentare tutte le righe di salvataggio e non preoccuparti della persistenza. (Vedi i commenti in /etc/redis/redis.conf)

Inoltre, non dimenticare

service redis-server stop
service redis-server start

tutte queste risposte non spiegano il motivo per cui il salvataggio di rdb non è riuscito.

come nel mio caso, ho controllato il registro redis e ho trovato:

14975: M 18 giu 13: 23: 07.354 # Salvataggio in background interrotto dal segnale 9

eseguire il seguente comando nel terminale:

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

visualizza:

/var/log/kern.log.1:Jun 18 13:23:07 10-10-88-16 kernel: [28152358.208108] Processo ucciso 28416 (redis-server) total-vm: 7660204kB, anon-rss: 2285492kB, file-rss: 0KB

questo è tutto! questo processo (redis save rdb) viene ucciso dal killer OOM

si riferisce:

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

Scoprire quale processo è stato ucciso dal killer OOM di Linux

FWIW, mi sono imbattuto in questo e la soluzione era semplicemente aggiungere un file di scambio alla scatola. Ho usato questo metodo: https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04

Anch'io stavo affrontando lo stesso problema. Entrambe le risposte (la più votata e quella accettata) forniscono solo una soluzione temporanea per lo stesso.

Inoltre, config set stop-writes-on-bgsave-error noè un modo orribile di guardare oltre questo errore, poiché ciò che fa questa opzione è impedire a redis di notificare che le scritture sono state interrotte e di andare avanti senza scrivere i dati in un'istantanea. Questo sta semplicemente ignorando questo errore. Riferiscilo

Per quanto riguarda l'impostazione dirin configredis-cli, una volta riavviato il servizio redis, anche questo verrà cancellato e verrà nuovamente visualizzato lo stesso errore. Il valore predefinito di dirin redis.confè ./, e se si avvia redis come utente root, allora ./è /a quali autorizzazioni di scrittura non vengono concesse e quindi l'errore.

Il modo migliore è impostare il dirparametro nel file redis.conf e impostare le autorizzazioni appropriate per quella directory. La maggior parte delle distribuzioni debian deve averlo/etc/redis/redis.conf

Oggi i problemi di accesso in scrittura di Redis che danno questo messaggio di errore al client sono riemersi nei rediscontainer docker ufficiali .

Redis dall'immagine ufficialeredis tenta di scrivere il file .rdb nella /datacartella dei contenitori , il che è piuttosto sfortunato, in quanto è una cartella di proprietà di root ed è anche una posizione non persistente (i dati scritti lì scompariranno se il tuo contenitore / pod si blocca).

Quindi dopo un'ora di inattività, se hai eseguito il rediscontainer come utente non root (ad es. docker run -u 1007Anziché come predefinito docker run -u 0), visualizzerai un messaggio di errore ben dettagliato nel registro del server (vedi 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

Quindi quello che devi fare è mappare la /datacartella del contenitore su una posizione esterna (dove l'utente non root, qui: 1007, ha accesso in scrittura, come /tmpsul computer host), ad esempio:

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

Quindi è una configurazione errata dell'immagine docker ufficiale (che dovrebbe scrivere per /tmpnon /data) che produce questa "bomba a orologeria" che molto probabilmente incontrerai solo in produzione ... durante la notte in un fine settimana di vacanza particolarmente tranquillo: /

per me

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

e ricarico il mio mac, funziona

Ho riscontrato questo problema mentre lavoravo su un server con spazio su disco AFS perché il mio token di autenticazione era scaduto, il che ha prodotto Permission Deniedrisposte quando il redis-server ha tentato di salvare. Ho risolto questo aggiornando il mio token:

kinit USERNAME_HERE -l 30d && aklog

Nel caso in cui si utilizzi docker / docker-compose e si desideri impedire a redis di scrivere su file, è possibile creare una configurazione redis e montarla in un contenitore

docker.compose.override.yml

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

Puoi scaricare la configurazione predefinita da qui

nel file redis.conf assicurati di commentare queste 3 righe

save 900 1
save 300 10
save 60 10000

Puoi visualizzare più soluzioni per rimuovere i dati persistenti qui

Nel mio caso è successo perché ho appena installato redisusando il modo rapido. Quindi redis non funziona come root. Sono stato in grado di risolvere questo problema seguendo le istruzioni nella Installing Redis more properlysezione della loro Guida rapida . Dopo averlo fatto, il problema è stato risolto e redisora è in esecuzione come root. Controlla.

Dopo aver sbattuto la testa attraverso così tante domande SO finalmente - per me la risposta di @Axel Advento ha funzionato ma con pochi passaggi extra - mi trovavo ancora di fronte ai problemi di autorizzazione.
Ho dovuto cambiare utente redis, creare una nuova directory nella sua home directory e quindi impostarla come dir di 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)

Nel mio caso era legato allo spazio libero su disco. (puoi controllarlo con il df -hcomando bash) quando libero spazio questo errore è scomparso.

Se si esegue Redis localmente su un computer Windows, provare a "eseguirlo come amministratore" e vedere se funziona. Con me, il problema era che Redis si trovava nella cartella "Programmi", che limita le autorizzazioni per impostazione predefinita. Come dovrebbe.

Tuttavia, non eseguire automaticamente Redis come amministratore. Non si desidera concedergli più diritti che dovrebbe avere. Vuoi risolverlo con il libro.

Quindi, siamo stati in grado di identificare rapidamente il problema eseguendolo come amministratore, ma questa non è la cura. Uno scenario probabile è che hai messo Redis in una cartella che non ha diritti di scrittura e di conseguenza il file DB è archiviato nella stessa posizione.

È possibile risolvere questo problema aprendo redis.windows.confe per cercare la seguente configurazione:

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

Passare dir ./a un percorso per il quale si dispone di autorizzazioni regolari di lettura / scrittura

Puoi anche spostare la cartella Redis nella sua interezza in una cartella che sai che ha le autorizzazioni giuste.

Per me era solo un problema di autorizzazioni per la cartella di dati redis persistenti. Gli ho dato un:

chmod 777 -Rf data/

E funziona! Potrebbe essere presto per dire che risolve il problema. Perché sospetto anche che redis non stia eseguendo come root, quindi ho bisogno di ispezionare il mio dockerFile per capire di più.

Controlla il tuo registro Redis prima di intraprendere qualsiasi azione. Alcune delle soluzioni in questo thread potrebbero cancellare i tuoi dati Redis, quindi fai attenzione a ciò che stai facendo.

Nel mio caso, la macchina stava esaurendo la RAM . Questo può accadere anche quando non c'è più spazio libero su disco nell'host.

Tieni presente che questo errore viene visualizzato quando il tuo server è sotto attacco. Ho appena scoperto che redis non riesce a scrivere in '/etc/cron.d/web' dove, dopo aver corretto i permessi, è stato aggiunto un nuovo file costituito da un algoritmo di mining con alcune opzioni nascoste.

# 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

Come sottolineato da @Chris, è probabile che il problema abbia poca memoria. Abbiamo iniziato a sperimentarlo quando abbiamo allocato troppa RAM su MySQL ( innodb_buffer_pool_size).

Per garantire che ci sia abbastanza RAM per Redis e altri servizi che abbiamo ridotto innodb_buffer_pool_sizesu MySQL.

Nel mio caso, la ragione era lo spazio libero sul disco molto basso (solo 35 Mb). Ho fatto quanto segue -

1. Arrestato tutto il processo relativo a Redis
2. Elimina alcuni file sul disco per creare spazio libero adeguato

3. Elimina il file di dump redis (se non sono necessari dati esistenti)

   sudo rm /var/lib/redis/*

4. Elimina tutte le chiavi di tutti i database esistenti

   sudo redis-cli flushall

5. riavviare tutte le attività del sedano e controllare i registri corrispondenti per eventuali problemi

è necessario chmod e chown la nuova cartella

chown -R redis e chmod ...