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


366

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.


você conseguiu resolver esse problema. Se sim, você poderia ajudar com as etapas. Porque colocar o arquivo rdb em outro lugar não resolveria, eu acho. Eu acho que im faltando alguma coisa aqui
ankur

4
Este erro ocorre devido ao início do servidor redis em um diretório em que o redis não possui permissões. Eu recomendo voltar às configurações padrão depois de corrigir o problema: Consulte a resposta sobre uma correção para esse problema.
Govind Rai 23/09


@GovindRai Eu já concedo permissão redis alterando o grupo e o proprietário para redis, mas não ajuda!
Wdetac

Respostas:


184

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.


7
rdb_bgsave_in_progress: 0 sob Persistence
thanikkal

Por algum motivo, quando tento qualquer comando config set, ele fica carregando para sempre.
Bashar Abdullah

5
Para aqueles infelizes que estão no Windows, me no momento, e whoa estão usando a versão MSOpenTech, você tem que caminho do diretório conjunto na seguinte estilo: dir C:/Temp/. Fazer um bgsave para verificar se ele funciona ..
John P

@ John P, era exatamente o que precisava ser feito. Obrigado!
Sam Sam

2
127.0.0.1:6379> CONFIG SET ERRO dir / root / tool (error) Alterando diretório: Permissão negada
Gank

317

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.


21
Esta é uma solução rápida, mas você deve verificar para certificar-se por bgsave falhou em primeiro lugar
Mandeep Singh

7
Se você usar o redis principalmente para armazenamento em cache e sessões, isso é obrigatório.
Jim

11
Isso não é perigoso? Por exemplo, o NodeBB usa o Redis como um armazenamento de dados.
Codecowboy

2
@LoveToCode configuração set stop-escreve-on-bgsave-erro, sim
Phil

4
Sempre que eu reiniciar o servidor, eu tenho o mesmo problema novamente. Então eu tenho que configurá-lo novamente. Como posso torná-lo permanente?
Zia Qamar

63

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

5
Link: redis.io/topics/faq Pesquisa para isso: " economia de fundo está a falhar com um erro de fork () no Linux, mesmo se eu tenho um monte de RAM livre! "
Bruno Peres

49

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

Saída de systemctl status redisrevelou que há um aviso que sugeriu exatamente alterar a overcommit_memory=0configuração. Alterar isso realmente resolveu o problema para mim.
Algoritmo abstrato

Isso resolveu o problema corretamente e deve ser a resposta aceita #
DSynergy 19/02/19

Portanto, o tldr seria, com as configurações padrão, se o redis estiver usando 10 gb de ram, você precisa ter 10 gb de ram livres para que esse processo filho possa ser executado?
Dan Hastings

@DanHastings - Sim. E definir overcommit_memory como 1 relaxa esse requisito.
Bhindi

26

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.


Se alguém está lendo isso eu tinha o problema com Homebrew tão bem, mas nada a ver com o upgrade: Eu só precisava para iniciar o serviço com sudo: brew services stop redis; sudo brew services start redis.
bfontaine

24

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 .


Quais permissões devem ser?
21417 Stephen

Isso funcionou para mim. Obrigado!
Lordwhizy

19

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.


82
Isso não "resolveu o problema", apenas o ignorou.
Buffalo

Reiniciar o RedisServer no Services.msc funcionou para mim.
precisa saber é

Sempre que eu reiniciar o servidor, eu tenho o mesmo problema novamente. Então eu tenho que configurá-lo novamente. Como posso torná-lo permanente?
Zia Qamar #

@ZiaQamar, você pode definir a propriedade permanentemente no redis.conf, que provavelmente está em /etc/redis/redis.conf, defina "stop-write-on-bgsave-error no"
Gaurav Tyagi

IMO definitivamente não é a solução. Você está apenas dizendo ao Redis para não registrar esses erros. Mas os erros ainda estão lá ...
Erowlin

17

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.


Certifique-se de conceder permissão do usuário não root para o diretório em que o arquivo de despejo será armazenado. No meu caso, eu tenho um usuário, redisassim faço: sudo chown redis:redis /var/lib/redis
#

13

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


12

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.


7

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


6

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

6

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


3

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


Como você descobriu que o excesso de memória era o problema? Eu posso estar tendo o mesmo problema.
DarthSpeedious

@DarthSpeedious Não me lembro. Se eu tivesse que adivinhar, diria que talvez algo nos logs estivesse reclamando por não conseguir alocar memória. Desculpe, não posso ser mais útil.
Ryan Angilly

Em primeiro lugar, pensei também que seria uma ótima solução trabalhar com troca e redis combinados. Depois, fiz algumas pesquisas e cheguei a este artigo antirez.com/news/52 , que afirma que é uma maneira errada de usar redis, de qualquer forma eu não sou 100% concorda com isso, você está satisfeito com o desempenho do uso de redis com swap?
talsibony

11
@DarthSpeedious No seu registro Redis, você verá os erros " Não é possível alocar memória ". Veja aqui como ver o arquivo de log: stackoverflow.com/questions/16337107/…
Bruno Peres

3

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


3

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: /


11
Só queria adicionar um comentário aqui, pois isso ajudou a resolver os problemas que eu estava enfrentando com os redis no Docker. Nossos servidores UAT e Dev Docker são Windows. O Windows Defender identificará os arquivos RDB como possíveis vírus. Portanto, montar seu diretório / data resolverá temporariamente o problema pai; até o Windows Defender colocar o arquivo em quarentena, causando outro. Verifique se você adicionou o diretório de dados montado como uma exceção no Windows Defender para resolver isso.
TrevorB 28/04

11
Lembra-me: que o alerta do Windows Defender pode não ser necessariamente um falso positivo - um cryptominer pode infectar a imagem oficial do Redis mesmo quando executada sem raiz e com todos os recursos descartados - basta expor sua porta à rede
mirekphd

Obrigado, esse é um bom argumento. Apenas curioso, mas como um arquivo RDB seria executado no host, especialmente no Windows? Suponho que possa estar sendo executado dentro do próprio contêiner. Mas isso não é específico para esse contêiner em particular.
TrevorB 30/04

11
Certo, a carga provavelmente falharia em ser executada no Windows, a menos que fosse escrita inteiramente em Lua e, portanto, fosse tão multiplataforma quanto o próprio Redis ... o comando eval é uma invenção do diabo, independentemente do idioma
mirekphd

Essa foi uma experiência esclarecedora; muito obrigado. Aparentemente, nossos arquivos de composição UAT / DEV estavam expondo portas fora da rede do Docker. Não sei como isso é possível, mas essas instâncias estavam recebendo comandos de administrador e, de fato. estavam lançando um minerador de criptografia. Desabilitei essas portas, desliguei a montagem RDB local e reinstalei a exceção do Windows Defender (no entanto, isso não importa com a montagem desativada). Preciso investigar como esses comandos estavam passando pelo firewall, mas estou monitorando de perto
TrevorB

3

para mim

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

e recarrego meu mac, funciona


1

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


1

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


1

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.


1

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)

0

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.


0

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.


0

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.


0

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.


0

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.


0
# 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

-1

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.


-1

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

11
Você deve ter feito isso em sua instância de desenvolvimento. Solução incorreta ao lidar com aplicativos centrados em dados.
Nikesh Devaki #

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.