MISCONF Redis está configurado para salvar instantâneos de RDB

Durante gravações no Redis ( SET foo bar), estou recebendo o seguinte erro:

O MISCONF Redis está configurado para salvar instantâneos de RDB, mas atualmente não pode persistir no disco. Os comandos que podem modificar o conjunto de dados estão desativados. Verifique os logs do Redis para obter detalhes sobre o erro.

Basicamente, entendo que o problema é que o redis não é capaz de salvar dados no disco, mas não tem idéia de como se livrar do problema.

Além disso, a pergunta a seguir tem o mesmo problema, foi abandonada há muito tempo sem respostas e, provavelmente, sem tentativas de solucionar o problema.

Caso encontre o erro e alguns dados importantes não possam ser descartados na instância redis em execução (problemas com permissões para o rdbarquivo ou seu diretório incorretamente ou com falta de espaço em disco), você sempre pode redirecionar o rdbarquivo para ser gravado em outro lugar.

Usando redis-cli, você pode fazer algo assim:

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

Depois disso, convém executar um BGSAVEcomando para garantir que os dados sejam gravados no rdbarquivo. Certifique-se de que, quando você executa INFO persistence, bgsave_in_progressjá é 0e rdb_last_bgsave_statusé ok. Depois disso, agora você pode iniciar o backup do rdbarquivo gerado em algum lugar seguro.

Usando redis-cli, você pode parar de tentar salvar o instantâneo:

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

Esta é uma solução rápida, mas se você se preocupa com os dados para os quais está usando, verifique se o bgsave falhou em primeiro lugar.

Pode haver erros durante o processo bgsave devido à pouca memória. Tente isso (em redis background save FAQ)

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

Este erro ocorre devido à falha de BGSAVE. Durante o BGSAVE, o Redis bifurca um processo filho para salvar os dados no disco. Embora o motivo exato da falha do BGSAVE possa ser verificado a partir dos logs (geralmente /var/log/redis/redis-server.logem máquinas Linux), mas muitas vezes o BGAVE falha porque o fork não pode alocar memória. Muitas vezes o fork não consegue alocar memória (embora a máquina tenha RAM suficiente disponível) devido a uma otimização conflitante do sistema operacional.

Como pode ser lido nas Perguntas frequentes do Redis :

O esquema de economia de plano de fundo do Redis depende da semântica de cópia na gravação dos garfos nos sistemas operacionais modernos: Redis bifurca (cria um processo filho) que é uma cópia exata do pai. O processo filho despeja o banco de dados no disco e finalmente sai. Em teoria, o filho deve usar tanta memória quanto o pai sendo uma cópia, mas, na verdade, graças à semântica de copiar na gravação implementada pela maioria dos sistemas operacionais modernos, o processo pai e filho compartilhará as páginas de memória comum. Uma página será duplicada somente quando for alterada no filho ou no pai. Como, teoricamente, todas as páginas podem mudar enquanto o processo filho está salvando, o Linux não pode contar com antecedência a quantidade de memória que o filho terá, portanto, se a configuração overcommit_memory estiver definida como zero, a falha será falha, a menos que haja tanta RAM livre quanto realmente necessário duplicar todas as páginas de memória dos pais,

Definir overcommit_memory como 1 indica que o Linux relaxa e executa a bifurcação de uma maneira de alocação mais otimista, e é isso mesmo que você deseja para o Redis.

O Redis não precisa de tanta memória quanto o sistema operacional pensa para gravar no disco; portanto, pode falhar preventivamente na bifurcação.

Para resolver isso, você pode:

Modifique /etc/sysctl.confe adicione:

vm.overcommit_memory=1

Em seguida, reinicie o sysctl com:

No FreeBSD:

sudo /etc/rc.d/sysctl reload

No Linux:

sudo sysctl -p /etc/sysctl.conf

Reinicie seu servidor redis.

• macos (fermentação) : brew services restart redis.
• Linux: sudo service redis restart /sudo systemctl restart redis
• Windows: Windows + R-> Digite services.msc, Enter-> Procurar Redise clique em restart.

Pessoalmente, tive esse problema depois de atualizar o redis com o Brew ( brew upgrade). Depois de reiniciar o laptop, ele imediatamente funcionou.

caso você esteja trabalhando em uma máquina Linux, verifique novamente as permissões de arquivo e pasta do banco de dados.

O banco de dados e o caminho para ele podem ser obtidos via:

em redis-cli:

Dir de CONFIG GET

CONFIG GET dbfilename

e na linha de comando ls -l. As permissões para o diretório devem ser 755 e as para o arquivo devem ser 644 . Além disso, normalmente o redis-server é executado como usuário redis, portanto, também é bom atribuir ao usuário redisa propriedade da pasta executando sudo chown -R redis:redis /path/to/rdb/folder. Isso foi elaborado na resposta aqui .

Obrigado a todos por verificar o problema, aparentemente o erro foi produzido durante bgsave.

Para mim, digitar config set stop-writes-on-bgsave-error noum shell e reiniciar o Redis resolveu o problema.

Inicie o Redis Server em um diretório em que o Redis tenha permissões de gravação

As respostas acima definitivamente resolverão seu problema, mas aqui está o que realmente está acontecendo:

O local padrão para armazenar o rdb.dumparquivo é ./(indicando o diretório atual). Você pode verificar isso no seu redis.confarquivo. Portanto, o diretório a partir do qual você inicia o servidor redis é onde um dump.rdbarquivo será criado e atualizado.

Parece que você começou a executar o servidor redis em um diretório em que o redis não tem as permissões corretas para criar o dump.rdbarquivo.

Para piorar a situação, os redis provavelmente também não permitirão que você desligue o servidor até que seja capaz de criar o arquivo rdb para garantir o salvamento adequado dos dados.

Para resolver esse problema, você deve entrar no ambiente ativo do cliente redis usando redis-clie atualizar a dirchave e definir seu valor para a pasta do projeto ou qualquer pasta em que o usuário não raiz tenha permissões para salvar. Em seguida, execute BGSAVEpara invocar a criação do dump.rdbarquivo.

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

(Agora, se você precisar salvar o arquivo dump.rdb no diretório em que iniciou o servidor, será necessário alterar as permissões do diretório para que os redis possam gravar nele. Você pode pesquisar o stackoverflow para saber como fazer isso )

Agora você deve conseguir desligar o servidor redis. Observe que codificamos o caminho. Hardcoding raramente é uma boa prática e eu recomendo iniciar o servidor redis a partir do diretório do projeto e alterar o dir key back to. / `.

CONFIG SET dir "./"
BGSAVE

Dessa forma, quando você precisar redis para outro projeto, o arquivo de despejo será criado no diretório do projeto atual e não no diretório do projeto do caminho codificado.

Se você estiver executando o MacOS e atualizou recentemente para a Catalina, pode ser necessário executar brew services restart redisconforme sugerido neste problema .

Tinha encontrado esse erro e foi capaz de descobrir no log que o erro ocorreu devido ao espaço em disco não ser suficiente. Todos os dados inseridos no meu caso não eram mais necessários. Então eu tentei FLUSHALL. Como o processo redis-rdb-bgsave estava em execução, não estava permitindo liberar os dados também. Segui as etapas abaixo e fui capaz de continuar.

1. Efetue login no cliente redis
2. Execute o conjunto de configurações stop-write-on-bgsave-error no
3. Executar FLUSHALL (os dados armazenados não eram necessários)
4. Executar o conjunto de configurações stop-write-on-bgsave-error sim

O processo redis-rdb-bgsave não estava mais sendo executado após as etapas acima.

Eu enfrentei o problema semelhante, a principal razão por trás disso foi o consumo de memória (RAM) por redis. Minha máquina EC2 tinha 8 GB de RAM (cerca de 7.4 disponível para consumo)

Quando meu programa estava executando, o uso da RAM subiu para 7,2 GB, deixando quase 100 MB de RAM, geralmente isso aciona o MISCONF Redis error ...

Você pode determinar o consumo de RAM usando o htopcomando Procure o atributo Mem após executar o comando htop. Se ele mostrar alto consumo (como no meu caso, foi de 7,2 GB / 7,4 GB), é melhor atualizar a instância com memória maior. Nesse cenário, a utilização config set stop-writes-on-bgsave-error noserá um desastre para o servidor e poderá resultar na interrupção de outros serviços em execução no servidor (se houver). Portanto, é melhor evitar o comando config e ATUALIZAR SUA REDIS MACHINE .

FYI: Pode ser necessário instalar o htop para fazer isso funcionar:sudo apt-get install htop

Uma solução a mais para isso pode ser outro serviço pesado de RAM em execução no sistema, verifique se há outro serviço em execução no servidor / máquina / instância e pare-o, se não for necessário. Para verificar todos os serviços em execução na sua máquina, useservice --status-all

E uma sugestão para as pessoas que colam diretamente o comando config, pesquise um pouco e pelo menos avise o usuário antes de usar esses comandos. E como @Rodrigo mencionou em seu comentário: "Não parece legal ignorar os erros".

---ATUALIZAR---

Você também pode configurar maxmemorye maxmemory-policydefinir o comportamento do Redis quando um limite específico de memória é atingido. Por exemplo, se eu quiser manter o limite de memória de 6 GB e excluir as chaves usadas menos recentemente do banco de dados para garantir que o uso de redis mem não exceda 6 GB, podemos definir esses dois parâmetros (em redis.conf ou CONFIG SET comando):

maxmemory 6gb
maxmemory-policy allkeys-lru

Existem muitos outros valores que você pode definir para esses dois parâmetros que podem ser lidos aqui: https://redis.io/topics/lru-cache

Uma correção mais permanente pode ser procurar no /etc/redis/redis.conf, nas linhas 200-250, configurações para os recursos rdb, que não faziam parte do redis nos dias 2.x.

notavelmente

dir ./

pode ser alterado para

dir /home/someuser/redislogfiledirectory

ou você pode comentar todas as linhas de salvamento e não se preocupar com persistência. (Veja os comentários em /etc/redis/redis.conf)

Além disso, não esqueça

service redis-server stop
service redis-server start

todas essas respostas não explicam o motivo pelo qual o rdb save falhou.

no meu caso, verifiquei o log redis e descobri:

14975: M 18 de jun 13: 23: 07.354 # Economia de fundo terminada pelo sinal 9

execute o seguinte comando no terminal:

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

exibe:

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

é isso! esse processo (redis save rdb) é eliminado pelo OOM killer

refere:

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

Localizando qual processo foi morto pelo Linux OOM killer

FWIW, eu me deparei com isso e a solução era simplesmente adicionar um arquivo de troca à caixa. Eu usei este método: https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04

Eu também estava enfrentando o mesmo problema. Ambas as respostas (a mais votada e a mais aceita) fornecem uma correção temporária para a mesma.

Além disso, config set stop-writes-on-bgsave-error noé uma maneira horrível de ignorar esse erro, pois o que essa opção faz é parar o redis de notificar que as gravações foram interrompidas e seguir em frente sem gravar os dados em um instantâneo. Isso é simplesmente ignorar esse erro. Consulte este

Quanto à configuração direm configredis-cli, depois de reiniciar o serviço redis, isso também será limpo e o mesmo erro será exibido novamente. O valor padrão de dirin redis.confé ./e, se você iniciar o redis como usuário root, ./é /para isso que as permissões de gravação não são concedidas e, portanto, o erro.

A melhor maneira é definir o dirparâmetro no arquivo redis.conf e definir as permissões apropriadas para esse diretório. A maioria das distribuições debian deve ter isso em/etc/redis/redis.conf

Atualmente, os problemas de acesso de gravação do Redis que transmitem essa mensagem de erro ao cliente ressurgiram nos rediscontêineres oficiais da janela de encaixe.

Os redis da imagem oficialredis tentam gravar o arquivo .rdb na /datapasta containers , o que é bastante lamentável, pois é uma pasta de propriedade da raiz e também é um local não persistente (os dados gravados ali desaparecerão se o container / pod falhas).

Portanto, após uma hora de inatividade, se você executou seu rediscontêiner como um usuário não raiz (por exemplo, em docker run -u 1007vez de padrão docker run -u 0), receberá uma mensagem de erro bem detalhada no log do servidor (consulte 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

Portanto, o que você precisa fazer é mapear a /datapasta do contêiner para um local externo (onde o usuário não raiz, aqui: 1007, possui acesso de gravação, como /tmpna máquina host), por exemplo:

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

Portanto, é uma configuração incorreta da imagem oficial do docker (que deve ser gravada como /tmpnão /data) que produz essa "bomba-relógio" que você provavelmente encontrará apenas em produção ... durante a noite durante um fim de semana de feriado particularmente tranquilo: /

para mim

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

e recarrego meu mac, funciona

Eu encontrei esse problema enquanto trabalhava em um servidor com espaço em disco do AFS porque meu token de autenticação expirou, o que gerou Permission Deniedrespostas quando o redis-server tentou salvar. Resolvi isso atualizando meu token:

kinit USERNAME_HERE -l 30d && aklog

Caso esteja usando o docker / docker-compose e deseje impedir que os redis gravem no arquivo, é possível criar uma configuração redis e montar em um contêiner

docker.compose.override.yml

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

Você pode baixar a configuração padrão aqui

no arquivo redis.conf, certifique-se de comentar estas 3 linhas

save 900 1
save 300 10
save 60 10000

você pode ver mais soluções para remover os dados persistentes aqui

No meu caso, aconteceu porque eu acabei de instalar redisusando o caminho rápido. Então redis não está sendo executado como root. Consegui resolver esse problema seguindo as instruções na Installing Redis more properlyseção do Guia de Iniciação Rápida . Depois disso, o problema foi resolvido e redisagora está sendo executado como root. Confira.

Depois de enfiar minha cabeça em tantas perguntas de SO, finalmente - para mim, a resposta do @Axel Advento funcionou, mas com algumas etapas extras - eu ainda estava enfrentando os problemas de permissão.
Eu tive que mudar de usuário redis, criar um novo diretório no diretório home e depois defini-lo como o dir de 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)

No meu caso, estava relacionado ao espaço livre em disco. (você pode verificá-lo com o df -hcomando bash) quando eu libero algum espaço, esse erro desapareceu.

Se você estiver executando o Redis localmente em uma máquina Windows, tente "executar como administrador" e verifique se funciona. Comigo, o problema era que o Redis estava localizado na pasta "Arquivos de Programas", que restringe as permissões por padrão. Como deveria.

No entanto, não execute o Redis automaticamente como administrador Você não deseja conceder mais direitos do que deveria. Você quer resolver isso pelo livro.

Portanto, conseguimos identificar rapidamente o problema executando-o como administrador, mas essa não é a solução. Um cenário provável é que você colocou o Redis em uma pasta que não possui direitos de gravação e, como conseqüência, o arquivo DB é armazenado no mesmo local.

Você pode resolver isso abrindo o redis.windows.confe para procurar a seguinte configuração:

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

Mude dir ./para um caminho para o qual você tem permissões regulares de leitura / gravação para

Você também pode simplesmente mover a pasta Redis na sua totalidade para uma pasta que você sabe que possui as permissões corretas.

Para mim, era apenas um problema de permissões na pasta de dados redis persistente. Eu dei a:

chmod 777 -Rf data/

E é obras! Pode ser que seja cedo para dizer que resolve o problema. Como também suspeito que o redis não esteja sendo executado como raiz, preciso inspecionar meu dockerFile para descobrir mais.

Verifique seu log do Redis antes de executar qualquer ação. Algumas das soluções neste encadeamento podem apagar seus dados Redis, portanto, tenha cuidado com o que está fazendo.

No meu caso, a máquina estava ficando sem memória RAM . Isso também pode acontecer quando não há mais espaço livre em disco no host.

Por favor, esteja ciente de que este erro aparece quando seu servidor está sendo atacado. Acabei de descobrir que o redis falha ao gravar em '/etc/cron.d/web', onde após a correção das permissões, um novo arquivo que consiste no algoritmo de mineração com algumas opções de ocultação foi adicionado.

# 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

Como apontado por @ Chris, o problema provavelmente está com pouca memória. Começamos a experimentar quando alocamos muita RAM para o MySQL ( innodb_buffer_pool_size).

Para garantir que haja RAM suficiente para Redis e outros serviços, reduzimos innodb_buffer_pool_sizeno MySQL.

No meu caso, o motivo era muito pouco espaço livre no disco (apenas 35 Mb). Eu fiz o seguinte -

1. Parou todo o processo relacionado ao Redis
2. Exclua alguns arquivos do disco para obter espaço livre adequado

3. Excluir arquivo redis dump (se dados existentes não forem necessários)

   sudo rm /var/lib/redis/*

4. Exclua todas as chaves de todos os bancos de dados existentes

   sudo redis-cli flushall

5. reinicie todas as tarefas de aipo e verifique se há problemas nos logs correspondentes

você deve chmod e mostrar a nova pasta

chown -R redis e chmod ...