Eu construí um aplicativo como parte de minha tese de UG que usa banco de dados mysql (edição da comunidade). Agora, meu professor quer que eu forneça tolerância a falhas ao banco de dados (por paridade!!)! Argumentei que não precisaríamos disso. De qualquer forma, pesquisei e descobri aqui que o mysql possui um mecanismo de replicação embutido (um mecanismo para fornecer tolerância a falhas, certo?), Junto com muitas outras técnicas para fornecer confiabilidade. Mas o que aprendi com isso é que existe um servidor mestre e alguns servidores escravos para fornecer tolerância a falhas usando replicação. Agora minhas perguntas são:
E se eu tiver apenas um servidor de banco de dados? O mysql tem alguma tolerância a falhas para servidores de banco de dados autônomos únicos (ou seja, sem formação mestre-escravo, sem cluster , etc.)?
Preciso tentar fornecer qualquer tipo de tolerância a falhas para os dados armazenados no banco de dados mysql?
Que tipo de diferenças existem (apenas em termos de tolerância a falhas) entre a edição da comunidade e a edição corporativa dos servidores mysql?
De alguma forma, tenho a sensação de que não precisamos fazer nada para fornecer tolerância a falhas ao banco de dados mysql, e está bem por si só. Mas preciso de algumas informações sólidas sobre o assunto.
Edição de recompensa:
A segunda pergunta de cima novamente:
Preciso tentar fornecer qualquer tipo de tolerância a falhas para os dados armazenados no banco de dados mysql?
Qual é a sensatez de tentar fornecer tolerância a falhas para um banco de dados mysql usando paridade (bit por byte)?
Alguns detalhes sobre os dados no banco de dados:
Os dados a serem específicos são uma coleção de cerca de 6500 strings Unicode, com menos de 1 MB de tamanho, são dados de inicialização , que nunca mudarão com o tempo. A única transação será para ler os dados do banco de dados, sem atualização e sem exclusão. Meu aplicativo requer pesquisa de texto completo nessas strings, e esse é o único motivo pelo qual estou usando o mysql, pois ele fornece pesquisa de texto completo. Estou ciente de que poderia evitar a pesquisa FT do mysql usando algo como elasticsearch.
Uma verificação de "paridade" só pode descobrir falhas, portanto, não é tolerante a falhas.
Muitas pessoas decidem que o principal ponto de falha é o subsistema de disco, então usam o RAID. Nesse contexto, você pode supor que a paridade pode ser usada para reparar - mas apenas porque existe algum outro mecanismo para dizer "esta unidade falhou".
Mas e se a placa-mãe morrer?
Portanto, você usa replicação e mestre-escravo com os dois servidores próximos um do outro.
Mas e se a energia do prédio acabar? Ou um tornado atinge os dois servidores? Ou ...
Então você coloca o Slave em outro data center.
(Eu poderia continuar essa história boba, mas não vou.)
Você pode colocar duas "instâncias" do MySQL no mesmo servidor e, em seguida, replicar uma para a outra. Em seguida, dê uma boa olhada em quão grande é a sua solução. (Não importa que praticamente qualquer falha destrua ambas as cópias.)
Ou você pode gastar alguns dólares e alugar espaço na Amazon para outro servidor. Então você pode se gabar honestamente da "tolerância a falhas".
Depois da Edição da Recompensa
Usar Mecanismo=InnoDB; isso oferece uma recuperação mais simples da falha do servidor.
Depois de carregar os dados, faça um dump (
mysqldumpou outro) da tabela estática e armazene-o em outro lugar. Isso é para "recuperação de desastres" de inundações, meteoritos, falhas de software, falha de disco, etc. O recarregamento seria manual e levaria algum tempo (mas você não colocou limites nisso).Essas são medidas simples e efetivamente cobrem praticamente todos os desastres. Se eu fosse listar outras coisas que podem dar errado com uma configuração do mysql, "paridade" não aparece como parte de nenhuma solução.
Para terminar a tarefa que você tem, configure seu disco com RAID-5. Três unidades é o mínimo. Você provavelmente poderia fingir com invasão de software e partições de uma única unidade. No entanto, isso tornaria inútil a recuperação de qualquer tipo de falha; em vez disso, mostraria o uso de "paridade".
"Checksums" são usados com mais frequência para detectar (mas não corrigir) erros. Isso geralmente é uma sobrecarga de 4 a 8 bytes para bytes de dados de 512 a 16 KB. Isso não é, tecnicamente, "paridade", mas é mais eficiente.
Um bit de paridade por byte oferece detecção de erro , mas não correção de erro . Veja
SECDEDpara correção. Isso requer, por exemplo, 8 bits em uma 'palavra' de 64 bits. Seymour Cray disse que "a paridade é para os agricultores", mas eventualmente ele implementou o SECDED nas memórias 'centrais'. (Isso foi nos anos 70. Seu professor é tão antigo assim?)O DBMS pode ser deixado para lidar com a detecção e recuperação de falhas (quando configurado corretamente). Seria muito incomum implementar manualmente tal comportamento no aplicativo. De fato, é para isso que serve uma pilha de software - para remover dos aplicativos os recursos que são comuns e frequentemente necessários, da mesma forma que um sistema operacional cuida do gerenciamento de memória e do agendamento de threads, digamos.
Dito isso, você pode adicionar outra coluna a cada tabela que contém as cadeias de caracteres. Ele manterá um hash da string. Recupere o hash junto com a string, recalcule e gere um erro se os dois hashes forem diferentes.
Dado que se trata de uma tese universitária, o professor pode estar tentando transmitir um ponto de aprendizado, além de qualquer praticidade sobre a implementação. Seu benefício de longo prazo pode ser investigar possíveis implementações de sua sugestão, em vez de listar os motivos pelos quais ele é um idiota. Apenas dizendo'.
Há várias coisas aqui. Se você deseja garantir a integridade dos dados, pode usar um mecanismo com tal coisa integrada. O mecanismo padrão do MySQL, InnoDB, calcula uma soma de verificação de cada página (geralmente, 16K de dados) e se desligará automaticamente se a soma de verificação falhar (na maioria dos casos, devido a um problema de hardware; mas pode ser um bug em si ou alguém adulteração manual dos arquivos).
Além disso, em caso de falha, o InnoDB usa um log de transações para recuperar transações perdidas que podem não estar totalmente sincronizadas com o disco devido ao buffer de memória.
As somas de verificação garantem a consistência física dos dados, mas não permitem recuperá-los; e eles não evitam outros problemas, como incorreção lógica ou exclusão acidental.
Uma configuração de replicação permite redundância de serviço (e até geograficamente redundante) e certa redundância de dados contra perda de dados devido a hardware. No entanto, como a replicação ocorre quase em tempo real, ela não protege contra coisas como a exclusão acidental do usuário. Além disso, embora a replicação tenha, nas versões mais recentes, soma de verificação dos dados na rede, isso raramente é um problema. No entanto, há um problema relativamente comum com um escravo mysql - erros de replicação podem surgir devido a consultas inseguras/não determinísticas (aquelas que podem retornar resultados diferentes em dois servidores diferentes), configuração diferente ou operações potencialmente arriscadas, como filtragem inadequada. Existem ferramentas de terceiros como pt-table-checksumque permite comparar duas réplicas enquanto os dados estão sendo gravados (e também fornecer somas de verificação no nível do usuário).
Embora algo como um escravo atrasado possa ser útil para evitar esses problemas, a maneira mais comum de garantir a capacidade de sobrevivência dos dados é realizar backups regulares . Em particular, backups completos e logs binários permitem recuperação pontual e você pode adicionar somas de verificação para verificar se os dados não estão corrompidos durante o armazenamento. Os backups lógicos são mais lentos do que os backups de linha para grandes conjuntos de dados, mas são mais seguros se a integridade física for algo que se deseja evitar.
Respondendo diretamente às suas perguntas: