Por que importar um arquivo .sql de 12 GB leva mais de 36 horas?

16

Estou esperando há 36 horas que um arquivo .sql de 12 GB seja importado com um type site.sql | mysqlcomando simples . Eu posso ver o que ibdata1está crescendo ainda, atualmente quase 40 GB.

Considerando que os gatilhos e os procedimentos armazenados estão no final do .sql, acho que o MySQL deveria adicionar dados e índices de chave.

O site.sql foi gerado usando este comando de outro servidor:

mysqldump -R -e --databases site --add-drop-database --add-create-database --add-drop-table -C --single-transaction --triggers

O que está demorando tanto?

mysql mysql-5 mariadb servermanfail
fonte
3
Quanto cpu o mysql está usando? Se for um valor baixo, provavelmente significa que você está vinculado ao disco
Derek Downey
2
Os arquivos LOAD DATA INFILE. Além disso, ao mover um banco de dados inteiro, veja minha resposta: movendo bancos de dados entre servidores, se você estiver na mesma versão principal. (especialmente se você tiver que abortar e reiniciar) #
212 Joe Joe

Respostas:

23

Tente o seguinte:

$ ps -ef|grep [m]ysql

Identifique o ID do processo

$ strace -cp <pid>

Deixe 10 segundos ou um minuto então ^C. Isso lhe dirá onde o processo está gastando seu tempo, por exemplo, ele poderia estar apenas aguardando o disco se você o visse reade writedominasse.

Gaius
fonte
4
+1 porque eu acabei de aprender um novo comando (strace): P Edit: well crap, não disponível no meu mac por padrão.
Derek Downey
2
É uma ferramenta fantástica, junto com o gdb. Não digo às pessoas que o aplicativo travou mais; Eu digo a eles exatamente o que está preso ou girando, ou a partir de um núcleo, digo a eles a linha de código e o nome do arquivo de origem. Ainda mais poderoso é o dtrace.
Caio
3
Strace é Linux - o equivalente do Solaris é treliça. O Dtrace está disponível no Mac.
Caio
então é. vai ler sobre isso agora.
Derek Downey
Cuidado: Bom comando para saber, mas tenha cuidado, esse comando travou minha instância do MySQL. Não sei porque. Antes do MySQL travar, o servidor ficou sem resposta por alguns minutos.
dabest1
7

Você tem alguma tabela do InnoDB com uma chave primária

  1. contendo várias colunas?
  2. tendo um amplo VARCHAR?
  3. e muitos índices não exclusivos?
  4. um ou mais índices não exclusivos que possuem uma chave ampla?

Qualquer uma dessas condições provavelmente pode fazer com que os nós BTREE grandes em seus índices tenham muito poucas folhas em cada nó BTREE. A chave de cluster na Chave primária também é anexada a cada entrada de chave não exclusiva em chaves não clusterizadas.

Outra consideração: a soma das páginas de dados do InnoDB é significativamente menor que as páginas de índice do InnoDB?

Você pode descobrir isso com esta consulta (em MB):

SELECT SUM(data_length)/POWER(1024,2) InnoDBData,
SUM(index_length)/POWER(1024,2) InnoDBIndexes
FROM information_schema.tables WHERE engine='InnoDB';

Consideração adicional: Você possui log binário ativado no servidor de banco de dados que está carregando? Se estiver, faça isso no servidor que está carregando:

mysql -h... -u... -p... -A -e"SET sql_log_bin=0; source site.sql"

Eu espero que isso ajude !!!

RolandoMySQLDBA
fonte
6

Você tem certeza de que as tabelas em que está lendo estão sem gatilhos, índices e restrições? Em que hardware e SO você está executando? Como o seu armazenamento está configurado?

Eu estou mais familiarizado com o oracle, mas a importação de 12G em tabelas sem gatilhos, índices e restrições deve ir facilmente com 200 GB / h. Um único gatilho pode transformar o processo em um caracol, dependendo do que esse gatilho faz ...

Eu espero que isso ajude

ik_zelf
fonte