Antes de postar a resposta, gostaria de repetir que fiz minha pergunta aqui e aqui . Como se pode sugerir, esta questão pertence a dba SE . Mas a razão pela qual eu postei aqui é porque envolve editar o arquivo de configuração em /etc/my.cnf .
Primeira solução
Edite o /etc/my.cnf para incluir os parâmetros abaixo. O local do arquivo de configuração pode variar dependendo da distribuição do Linux. No RHEL6, está presente em /etc/my.cnf .
innodb_doublewrite = 0
innodb_flush_log_at_trx_commit = 0
innodb_support_xa = 0
innodb_locks_unsafe_for_binlog = 1
Esta sugestão foi fornecida por derobert e gostaria de agradecer-lhe por sugerir esta solução.
Teste : Apesar de não ser tão lento quanto o comando mysql para restauração, esse método ainda levava um tempo considerável. O comando foi executado por 3 dias e restaurou cerca de 130 GB.
Segunda solução
Ao definir alguns sinalizadores antes de importar os despejos de banco de dados, podemos acelerar bastante o processo de restauração:
SET autocommit=0;
SET unique_checks=0;
SET foreign_key_checks=0;
Os sinalizadores acima precisam ser definidos no arquivo .sql . Como desativamos a confirmação automática, também precisamos confirmar manualmente no final da restauração:
COMMIT;
A declaração acima deve ser a última declaração do arquivo .sql . Na verdade, podemos encontrar um script para fazer o mysqldump de aqui .
Eu não tive a chance de testar essa solução, mas faz muito sentido, pois desativa as verificações de chave estrangeira.
Como estamos restaurando um banco de dados inteiro, podemos acelerar as coisas desabilitando verificações exclusivas e verificações de chaves estrangeiras. Além disso, ao confirmar tudo no final da restauração, em vez de a restauração estar em andamento, temos aumentos de velocidade adicionais significativos.
Terceira solução
Eu tenho todo o diretório mysql data com backup feito comigo. O diretório de dados normalmente está localizado em /var/lib/mysql . No meu caso, o diretório de dados foi montado como uma partição separada em /mounts/mysql . Eu tinha feito backup da pasta inteira e, portanto, restaurei a pasta inteira para a mais nova máquina RHEL6. Antes de restaurar, precisamos apenas certificar-se de que o daemon mysqld não seja iniciado. Porém, eu restaurei usando o comando rsync , queria ter certeza de que as permissões de arquivo estão definidas atualmente na nova máquina RHEL6. Então, depois de restaurar /mounts/mysql no novo sistema RHEL6, emiti o comando abaixo.
chown -R mysql:mysql /mounts/mysql
Agora, eu testei o banco de dados e tudo parecia perfeitamente legal. O tempo de restauração foi de cerca de 3 horas.
Eu não vi pessoas sugerindo a abordagem acima para a restauração do banco de dados mysql em qualquer lugar. Eu vejo de isso resposta que as versões mysql tem que ser compatível para restaurar os bancos de dados de diretórios de dados. No entanto, com a minha experiência na restauração até agora, isso não é verdade. Contanto que as permissões estejam definidas corretamente, os bancos de dados funcionam perfeitamente bem.
No entanto, precisamos do arquivo .sql quando tentarmos restaurar um banco de dados mysql em um banco de dados sql-server ou um banco de dados postgre .