Início / dba / Perguntas / 11806
Accepted
Buttle Butkus
Asked: 2012-01-28 04:50:19 +0800 CST

Por que o DROP DATABASE está demorando tanto? (MySQL)

  • 772

Nova instalação do CentOS.

Eu estava executando uma importação de um banco de dados grande (arquivo sql de 2 GB) e tive um problema. O cliente SSH parecia perder a conexão e a importação parecia congelar. Eu usei outra janela para fazer login no mysql e a importação parecia estar morta, presa em uma tabela de linhas de 3M específica.

Então eu tentei

DROP DATABASE huge_db;

15-20 minutos depois, nada. Em outra janela, fiz:

/etc/init.d/mysqld restart

A janela DROP DB apresentou a mensagem: SERVER SHUTDOWN. Então eu realmente reiniciei o servidor físico.

Logado novamente no mysql, verificado e o db ainda estava lá, executei

DROP DATABASE huge_db;

novamente, e novamente estou esperando já cerca de 5 minutos.

Mais uma vez, é uma nova instalação. O huge_dbé o único db (diferente do dbs do sistema). Eu juro que deixei cair db's tão grandes antes e rapidamente, mas talvez eu esteja errado.

Eu derrubei com sucesso o banco de dados. Demorou algo como 30 minutos. Observe também que acho que me enganei quando pensei que a importação do mysqldump estava morta. A conexão do terminal foi perdida, mas acho que o processo ainda estava em execução. Eu provavelmente matei a tabela intermediária de importação (a tabela de linhas de 3M) e provavelmente 3/4 do caminho através de todo o banco de dados. Era enganoso que "top" mostrasse o mysql usando apenas 3% da memória, quando parecia que deveria estar usando mais.

Soltar o banco de dados acabou levando 30 minutos, então, novamente, talvez eu não tivesse que reiniciar o servidor e possivelmente poderia ter esperado o DROP terminar, mas não sei como o mysql reagiria ao obter uma consulta DROP para o mesmo db que está importando via mysqldump.

Ainda assim, a pergunta permanece, por que leva mais de 30 minutos para DROP um banco de dados de 2 GB quando tudo o que deveria fazer é excluir todos os arquivos db e remover todas as referências ao banco de dados de information_schema? Qual é o problema?

mysql mysqldump

5 respostas

  1. Best Answer

    Em vez de matar o processo, seria mais seguro se você fizesse isso no MySQL:

    $ mysqladmin processlist -u root -p
Enter password: 
+-----+------+-----------+-------------------+---------+------+-------+------------------+
| Id  | User | Host      | db                | Command | Time | State | Info             |
+-----+------+-----------+-------------------+---------+------+-------+------------------+
| 174 | root | localhost | example           | Sleep   | 297  |       |                  |
| 407 | root | localhost |                   | Query   | 0    |       | show processlist |
+-----+------+-----------+-------------------+---------+------+-------+------------------+

    A consulta com id 174 é a que bloqueia a exclusão do banco de dados 'exemplo', portanto, antes de matar qualquer processo, deixe o MySQL tentar encerrar a consulta:

    $ mysqladmin kill 174

    Execute o processlistcomando acima novamente para confirmar que ele foi morto.

    Se isso não funcionar, talvez você possa tentar matar o processo errante, mas antes disso você pode tentar reiniciar o servidor MySQL.

    Você também pode executar comandos como 'SHOW FULL PROCESSLIST' e 'KILL 174' no shell do MySQL, por exemplo, se você tiver apenas o cliente MySQL instalado. O ponto principal é evitar matar o processo usando 'kill' no shell, a menos que seja absolutamente necessário.

    De um modo geral, você pode usar mysqlou mysqladmin. Você não deve precisar executar comandos como este com frequência; uma vez que você começa a matar consultas regularmente, algo está definitivamente errado e seria melhor corrigir esse problema (matar o processo de consulta é apenas tratar o sintoma).

    • 89

  2. Embora eu achasse que o processo de importação havia morrido, ele provavelmente ainda estava em execução.

    O DROP DATABASEcomando provavelmente esperou que o banco de dados terminasse de importar antes de ser executado.

    Então, em vez de DROP DATABASElevar muito tempo, provavelmente foi apenas a importação.

    1.)

    Se alguém ler isso e estiver tentando cancelar uma importação de banco de dados e descartar o banco de dados, recomendo que você primeiro encontre o PID (id do processo) para a importação e execute-o em um terminal diferente:

    $ kill [PID]

    ...onde [PID] seria o PID real para o processo.

    Você deve ver a importação parar imediatamente se o outro terminal ainda estiver conectado.

    2.)

    Você também pode executar SHOW PROCESSLISTna guia SQL do phpMyAdmin. A tabela resultante mostra os processos em execução e clicar no 'x' ao lado da linha que você deseja eliminar deve resolver o problema. Isso teria o mesmo efeito que a resposta aceita ou mataria o mysqlprocesso na mysqllinha de comando.

    Então corra

    DROP DATABASE `database_name`;

    E tudo deve estar limpo.

    Outra resposta sugeriu que matar o processo dentro do mysql é melhor do que fazê-lo de fora. Eu não testei essa resposta, mas parece muito plausível. Então eu marquei como a "resposta aceita" em vez desta.

    • 11

  3. Eu enfrentei o mesmo problema. Mas desta vez eu verifiquei show processlist; ele disse verificar as permissões por mais tempo. Então descobri que mysqld_safe estava sendo executado como root, enquanto as permissões no nível da pasta eram apenas para o usuário mysql. Por isso, matei a consulta, é claro que demorou muito tempo dizendo que estava no estado morto, mas esperei que ele reagisse, então ele matou a consulta e alterou as permissões de nível de pasta para root também adicionando-o ao grupo e chmod para 770. Então eu executei o mesmo banco de dados drop blah; funcionou para mim em 2 segundos para o banco de dados de 20 GB.

    • 4

  4. Tente truncar as maiores tabelas em seu banco de dados antes de eliminá-lo. Eu vi um comportamento muito semelhante ao trabalhar com arquivos MySQL de tráfego de firewall e isso ajudou imensamente.

    • 3

  5. A primeira coisa que vem à mente é o statusChecking Permissions...

    Quando você emite DROP DATABASE mydb;tudo dentro de /var/lib/mysql/mydb é verificado para ver se as permissões do sistema operacional existem para o direito de descartar todos os arquivos.

    Alguns acharam que reduzir o número de usuários mysql pode ajudar

    • 3

relate perguntas