Eu tenho uma máquina virtual (Debian) em execução em um host de máquina físico. A máquina virtual atua como um buffer para os dados que recebe frequentemente pela rede local (o período para esses dados é de 0,5s, portanto, uma taxa de transferência bastante alta). Todos os dados recebidos são armazenados na máquina virtual e encaminhados repetidamente para um servidor externo pelo UDP. Depois que o servidor externo reconhece (por UDP) que recebeu um pacote de dados, os dados originais são excluídos da máquina virtual e não são enviados ao servidor externo novamente. A conexão à Internet que conecta a VM e o servidor externo não é confiável, o que significa que ela pode ficar inativa por dias a fio.
A máquina física que hospeda a VM é cortada várias vezes por dia aleatoriamente. Não há como saber quando isso está prestes a acontecer e não é possível adicionar um no-break, bateria ou solução semelhante ao sistema.
Originalmente, os dados eram armazenados em um banco de dados HSQLDB baseado em arquivo na máquina virtual. No entanto, os frequentes cortes de energia acabam causando o corrompimento do arquivo de script do banco de dados (não no nível do sistema de arquivos, ou seja, é legível, mas o HSQLDB não consegue entender isso), o que leva à minha pergunta:
Como os dados devem ser armazenados em um ambiente em que os cortes de energia podem e ocorrem com frequência?
Uma opção em que posso pensar é usar arquivos simples, salvando cada pacote de dados como um arquivo no sistema de arquivos. Dessa forma, se um arquivo estiver corrompido devido à perda de energia, ele poderá ser ignorado e o restante dos dados permanecerá intacto. Isso coloca alguns problemas, no entanto, principalmente relacionados à quantidade de dados que provavelmente estão sendo armazenados na máquina virtual. A 0,5s entre cada parte dos dados, 1.728.000 arquivos serão gerados em 10 dias. Isso pelo menos significa usar um sistema de arquivos com um número aumentado de inodes para armazenar esses dados (a configuração atual do sistema de arquivos ficou sem inodes com ~ 250.000 mensagens e 30% de espaço em disco usado). Além disso, é difícil (não impossível) de gerenciar.
Existem outras opções? Existem mecanismos de banco de dados executados no Debian que não seriam corrompidos por cortes de energia? Além disso, qual sistema de arquivos deve ser usado para isso? ext3 é o que é usado no momento.
O software que roda na máquina virtual é escrito usando Java 6, portanto, esperamos que a solução não seja incompatível.
fonte
Respostas:
Honestamente, sua melhor abordagem aqui é corrigir os cortes de energia ou implantar um sistema diferente em um local melhor.
Sim, existem sistemas como o redis que armazenam dados em um registro somente anexado para reprodução, mas você corre o risco de corrupção em níveis mais baixos - por exemplo, se o seu sistema de arquivos for embaralhado, os dados no disco estão potencialmente em risco.
Agradeço que qualquer melhoria seja útil para você, mas, na verdade, o problema não pode ser resolvido de acordo com o cenário que você descreveu.
fonte
Sua abordagem pode funcionar. Deixe-me sugerir algumas melhorias. Havia uma pergunta no estouro de pilha na gravação atômica no arquivo . Basicamente, você salva cada pacote de dados em um arquivo temporário e o renomeia para seu nome final. Renomear é uma operação atômica que estará protegida contra falhas de energia. Dessa forma, você garante que todos os seus arquivos no seu destino final foram salvos corretamente, sem corrupção.
Então, o que você pode fazer para lidar com a questão de ter milhões de arquivos. O cron é um trabalho que pode ser executado a cada hora, que leva todos os arquivos mais antigos que uma hora e os combina em um arquivo grande usando novamente operações atômicas de arquivos para que esse trabalho seja executado com segurança mesmo durante uma falta de energia e exclua os arquivos antigos. Tipo como rotação de log. Uma hora de arquivos custaria cerca de 7.200 arquivos. Portanto, a qualquer momento, você não deve ter mais de 20.000 arquivos em disco.
fonte
Você instala um no-break ou uma placa RAID com um cache de gravação com bateria no sistema e , por apenas US $ 49,95 , realiza o que é simplesmente impossível de realizar apenas em software.
Sua alegação de que de alguma forma não é possível conectar esse servidor a um no-break ou bateria ... simplesmente não é possível.
fonte
My PHB won't let me hook this up to a UPS/batteryé uma coisa muito diferente deit is not possible to add a UPS, a battery, or a similar solution to the system.Não ficar muito pedante, mas é uma distinção importante porque altera a abordagem e as soluções disponíveis.Monte todo o sistema somente leitura, exceto um dispositivo de bloco que armazena todos os seus dados. Use esse dispositivo de bloco diretamente e implemente seu próprio mecanismo de armazenamento de dados usando esse dispositivo de bloco bruto.
fonte