Já encontramos várias vezes um cenário que faz com que nosso banco de dados MySQL seja corrompido quando tentamos restaurar um arquivo mysqldump. Usamos os mesmos procedimentos (por meio de scripts em lote) há vários anos sem problemas e só recentemente começamos a encontrar o problema nos últimos meses.
Estamos executando a versão do MySQL Server: 5.7.18-0ubuntu0.16.04.1 (Ubuntu 16.04.2 LTS) e estamos restaurando duas tabelas MyISAM com aproximadamente 350 mil registros (combinados).
Usamos o seguinte script cmd para fazer backup das tabelas internas e restaurar para o servidor de banco de dados remoto:
"%mysql_path%\mysqldump.exe" --user=root --password="%PWD%" --host=%source% ourdbname --tables table1 table2 | "%mysql_path%\mysql.exe" -uroot --password="%PWD%" --host=%dbtarget% -C ourdbname
Onde as %%variáveis são fornecidas como parte do script em lote maior. Basicamente, estamos canalizando a saída do dump para o mysql.exe para restaurar no servidor remoto. O script é executado em uma máquina Windows 10, mas os bancos de dados de origem e de destino estão no Linux.
A parte de restauração é onde o banco de dados é corrompido, o que faz com que o uso da CPU do servidor de banco de dados aumente para 100% por núcleo. A única maneira que encontramos para corrigir esse problema é encerrar o processo mysql, excluir os .frm, .MYD, .MYIarquivos, iniciar o mysql e restaurar as tabelas localmente (scp'd o arquivo mysqldump para o servidor e restaurar).
Descobrimos que o banco de dados só fica corrompido quando temos tráfego ativo no site. Assim, poderíamos desativar o site (servidor separado executando Java conectado via JDBC), executar o script e colocar o site online novamente e ele funcionaria 100% do tempo. Obviamente que isto não é o ideal, mas é a única forma de o conseguirmos agora.
Alguma idéia do que poderia estar causando isso? Sugestões sobre como contornar isso sem precisar desligar o servidor front-end?
Responder1
Parece que você está usando MyISAM como mecanismo de banco de dados do seu site. Eu recomendo usar o InnoDB, é melhor em muitos aspectos.
No entanto, o principal problema aqui é que seu aplicativo Web provavelmente está gravando no banco de dados ao mesmo tempo em que seu backup está sendo gravado no banco de dados. Dependendo do esquema da tabela real, isso pode causar todos os tipos de efeitos negativos. Usar MyISAM apenas faz com que funcione, já que não há bloqueio em nível de linha no MyISAM, se bem me lembro.
Portanto, usar o InnoDB poderia ajudar com isso, mas talvez não. A única opção segura seria simplesmente parar o servidor front-end. Outra opção é criar uma API para o aplicativo remoto que gravaria com segurança os dados recebidos no banco de dados.