O MyIsam é mais seguro que o InnoDB?

Question

O mecanismo MyIsam é mais seguro do que o InnoDB sobre a perda de dados devido ao erro do FileSystem?

Parece que o InnoDB não é reparável com a ferramenta MySQL.

Eu tive que escolher o meu motor e escolhi o InnoDB por causa de chaves estrangeiras, mas vou considerar a migração do motor se isso parecer mais seguro.

    

Answer 1

O InnoDB tem uma arquitetura muito elaborada em segundo plano

Arquitetura InnoDB

Nocasodeumafalha,oInnoDBtemobufferdegravaçãoduploeosarquivosdelogparasuportarmecanismosderecuperaçãodefalhas.OMyISAMnãopossuiessaproteção.EuescrevipostsnoDBAStackExchangesobreisso:

• Oct08,2012: Implementação de recuperação de dados MYSQL MyISAM
• Mar 19, 2012 : Muito pequena tabela MySQL continua travando
• Mar 15, 2012 : Por que as tabelas do MySQL travam? Como faço para evitar isso?
• Feb 16, 2012 : A tabela MyISAM fica bloqueada. Quais são minhas opções?

O MyISAM pode travar com muita facilidade, pois os dados nunca são armazenados em cache na memória. Todas as leituras e gravações requerem E / S de força bruta do arquivo .MYD das tabelas MyISAM. Isso significa que os identificadores de arquivos abertos estão à mercê do sistema operacional.

Se você quiser que o InnoDB seja reparável, você precisa configurar o my.cnf para tornar o InnoDB menos dependente do SO e mais dependente da Arquitetura Interna. Veja minha postagem recente Alta carga média devido ao uso da CPU do alto mysql . Dessa forma, o InnoDB Crash Recovery pode ser mais auto-recuperável.

    

Answer 2

Eu usaria InnoDB por causa de bloqueios por registro vs MyIsam bloqueia por tabela de buraco. Também InnoDB não requer ferramenta de reparo como já foi dito anteriormente. Além disso, o mecanismo InnoDB pode salvar tabelas em arquivos separados para que pareça mais seguro do ponto de falha do sistema de arquivos.

    

Answer 3

Erros do sistema de arquivos, ou até mesmo erros de nível de bloco, não são o tipo de itens testados extensivamente ou contabilizados pela implementação do MyISAM ou Innodb. Embora alguma detecção possa acontecer quando são escritas, há uma grande suposição de que o que uma vez foi escrito sem um erro retornou, está correto. Somas de verificação existem e são verificadas em leitura, mas o caminho de recuperação de erro em páginas / linhas que falham na soma de verificação não acho que foi totalmente pensado.

Eu suspeito que a estratégia correta de mitigação de risco para isso (e algumas outras formas de falha do servidor) é executar um escravo de replicação em um sistema de arquivos diferente e, como um DR, manter logs binários e um despejo lógico do snapshot SQL. Dessa forma, você não precisa depender de ferramentas que possam resolver algumas formas de falha com o dataloss.