Prática recomendada do MongoDB contra falha constante de energia

Question

Histórico:

Eu tenho algumas máquinas de aplicação AIO, (executando o Ubuntu com rails + mongodb + chromium) em uma máquina em um coach móvel para exibir informações, ocasionalmente o usuário pode alterar o mandril de alguns dados para o mongodb.

Agora, a fonte de alimentação da máquina é constante, o condutor do ônibus pode desligar a máquina a qualquer momento. máquina tem 2 partição, primeiro é aufs para /, o outro é ext4 para o diretório mongodb / data. MAS durante o instante do corte de energia, não há entrada de dados no banco de dados.

Problema:

Toda vez que a máquina for reiniciada devido a corte de energia (a cada várias horas), o mongodb deixará um arquivo mongod.lock em seu diretório. em /etc/rd.local Eu tentei apagar o arquivo de bloqueio a cada inicialização, mas às vezes ainda se recusam a iniciar. o que faz com que meu aplicativo falhe no início.

De acordo com documentos oficiais: link , eu ainda tenho algumas oportunidades de começar.

Qual é a melhor prática para executar o mongodb em uma situação de falha de energia regular como acima? Sem lançar hardware adicional.

    

Answer 1

Todo o arquivo mongod.lock está dizendo que o DB teve um desligamento sujo, ou seja, não foi interrompido por um administrador, etc.

Ao executar uma operação --repair , o mongod tentará ler os arquivos existentes, gravar novos arquivos e depois trocá-los. Depois de concluído, ele deve remover o arquivo mongod.lock e permitir que você inicialize o banco de dados.

Se usado em conjunto com --repairpath argumento, o arquivo reparado será colocado no caminho de reparo especificado e o arquivo de bloqueio não pode ser removido, pois os arquivos de dados originais não foram reparados, em vez disso, novos arquivos foram escrito com os dados reparados e o caminho especificado.

Um possível fluxo de trabalho com --repairpath :

1. Inicialização do serviço, a mensagem de registro informa sobre o problema de bloqueio, sai.

   mongod --dbpath=/data/db
   

2. Você executa um comando de reparo semelhante a este:

   mongod --dbpath=/data/db --repair --repairpath=/data/db2
   

   e aguarde a conclusão.

3. Depois de concluído, inicie o mongod do caminho dos arquivos reparados:

   mongod --dbpath=/data/db2
   

4. Uma vez confirmado o trabalho, você pode remover o diretório /data/db se desejar.

Tudo isso provavelmente pode ser eliminado "substituindo" os arquivos em /data/db/ por não usar a opção --repairpath.

Em relação à recuperação, dê uma olhada em Registro no diário - isso cria um diário de operação que é liberado para o disco permanente a cada 100ms, e quando mongod é iniciado e detecta arquivos de diário não aplicados e os aplica, remove o arquivo de bloqueio e inicializa o servidor.

    

Answer 2

Em primeiro lugar, por favor READ a documentação abençoada que você vinculou :

mongod.lock
Do not remove the mongod.lock file. If mongod is unable to start, use one of the methods above to correct the situation.

Removing the lock file will allow the database to start when its data may be corrupt. In general, you should never force the database to start with possibly corrupt data. In an emergency situation, you may want to remove the lock file to pull whatever data you can off the server. If you have ever manually removed the lock file and started the server back up, you should not consider that server "healthy."

Siga os procedimentos descritos em a documentação abençoada à qual você vinculou para recuperar após falhas de energia.

O MongoDB não foi projetado para ser executado em um ambiente onde ele será kickado sem cerimônias - se você precisar desse tipo de durabilidade, precisará de um banco de dados especificamente projetado para gravações de consolidação e liberação em duas fases no disco. / p>