MariaDB demorando séculos para restaurar o backup

Question

Então, eu fiz um mysqldump de um banco de dados muito grande e estou tentando restaurá-lo agora usando:

mysql db_test < db_test.sql

mas parece que não vai terminar até o final deste ano. Já faz uma hora e ainda "restaura". Fazer o backup demorou cerca de 10 minutos, então estou com medo de que algo ruim esteja acontecendo.

Até agora:

• Eu verifiquei que mysqld está consumindo meu cpu (até 80% às vezes).
• Não há nada relevante nos logs.

• Eu posso ver o banco de dados criado e preenchido com uma tonelada de tabelas (não tudo tho). Além disso, quando executo use db_test; , recebo o seguinte mensagem:

  Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A

• Arquivos db originais com cerca de 25 GB, após a hora inteira, df -h retorna o mesmo espaço livre de antes. Então eu acho que não está fazendo nada no disco.

Algo estranho aqui é que, ao verificar top , descobri que kworker estava consumindo até 100% de cpu às vezes, o que não deveria acontecer

Alguma ideia ou qualquer coisa que eu possa fazer para ver o que está acontecendo?

    

Answer 1

Soa como os discos subjacentes estão ocupados. O problema na restauração de um banco de dados grande é que cada (grupo de) INSERT requer uma operação de flush / sync, que é muito lenta em discos mecânicos (um disco de 7200 RPM é da ordem de ~ 100 IOPS).

Para acelerar a restauração, você tinha que instruir temporariamente o MySQL / MariaDB para não emitir liberações / sincronizações. Para fazer isso, interrompa a restauração e edite seu /etc/my.ini com as duas linhas a seguir:

• innodb_flush_method=nosync
• innodb_flush_log_at_trx_commit=2

Em seguida, reinicie o MariaDB e tente novamente a restauração. As coisas devem ser muito mais rápidas agora.

Após a restauração, REMOVER AS LINHAS ACIMA do seu banco de dados terá uma vida curta e ruim: liberações / sincronizações existem por razões muito importantes. Embora seja aceitável desativá-los para uma restauração, um banco de dados de produção deve nunca ser executado sem eles.

    

Answer 2

Se o armazenamento subjacente for simples, para um banco de dados MySQL de 25 GB no disco, é bastante normal fazer uma restauração de horas - especialmente para alguns bancos de dados mal estruturados (muitas tuplas, índices, etc.). / p>

Para começar, comprima seu despejo, isso economiza toneladas de E / Ss e coloca menos estresse na memória cache:

mysqldump foo |gzip >foo.sql.gz
zcat foo.sql.gz |mysql foo

No seu caso, já que você já fez o mysqldump:

gzip db_test.sql
zcat db_test.sql.gz |mysql db_test

Além do desempenho do seu sistema (armazenamento, RAM, etc.), as configurações do MySQL podem ter um grande impacto. Mas isso é um conhecimento todo lá, nada que pode ser tratado através de um problema ServerFault ...