Почему DROP DATABASE занимает так много времени? (Баз данных)

Новая установка CentOS.

Я запускал импорт большого DB (2GB sql-файла) и имел проблему. Клиент SSH, похоже, потерял соединение, и импорт, казалось, замерз. Я использовал другое окно для входа в mysql, и импорт оказался мертвым, застрявшим на определенной таблице строк 3M.

Итак, я попробовал

DROP DATABASE huge_db;

Через 15-20 минут ничего. В другом окне я сделал:

/etc/init.d/mysqld restart

Окно DROP DB messaged: SERUT SHUTDOWN. Затем я фактически перезапустил физический сервер.

Записанный в mysql, проверен и db все еще там, побежал

DROP DATABASE huge_db;

снова, и снова я жду уже около 5 минут.

Еще раз, это новая установка. huge_db - это только db (кроме системных dbs). Я клянусь, что я сбросил db до этого и быстро, но, возможно, я ошибаюсь.

Я успешно удалил базу данных. Это заняло около 30 минут. Также обратите внимание, что я думаю, что ошибался, когда думал, что импорт mysqldump был мертв. Соединение терминала было потеряно, но я думаю, что процесс все еще работал. Я, скорее всего, убил средний стол импорта (таблицу строк 3M) и, вероятно, 3/4 пути через весь db. Было неверно, что «топ» показал, что mysql использует только 3% памяти, когда казалось, что он должен использовать больше.

Удаление базы данных закончилось тем, что заняло 30 минут, поэтому снова мне не пришлось перезапускать сервер и, возможно, просто ждал завершения DROP, но я не знаю, как mysql будет реагировать на получение DROP для того же самого DB, который он импортирует через mysqldump.

Тем не менее, остается вопрос, почему требуется 30min + для DROP базы данных 2 ГБ, когда все, что ему нужно сделать, это удалить все файлы db и удалить все ссылки на БД из information_schema? В чем дело?

39 голосов | спросил Buttle Butkus 27 Jpm1000000pmFri, 27 Jan 2012 16:50:19 +040012 2012, 16:50:19

5 ответов


57

Вместо того, чтобы убивать процесс, было бы безопаснее, если бы вы сделали это в 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 |
+-----+------+-----------+-------------------+---------+------+-------+------------------+

Запрос с идентификатором 174 является блокирующим удалением базы данных «example», поэтому перед тем, как вы удалите все процессы, сначала попросите MySQL попытаться завершить запрос:

$ mysqladmin kill 174

Выполните команду processlist выше, чтобы подтвердить, что она была убита.

Если это не сработает, вы можете посмотреть на убийство ошибочного процесса, но перед этим вы можете попробовать перезапустить сервер MySQL.

Вы также можете запускать команды, такие как «SHOW FULL PROCESSLIST» и «KILL 174» в оболочке MySQL, например, если у вас установлен только клиент MySQL. Главное, чтобы избежать убийства процесса, используя «kill» в оболочке, если это абсолютно необходимо.

Вообще говоря, вы можете использовать либо mysql, либо mysqladmin. Вам не нужно часто запускать такие команды, как это; как только вы начинаете убивать запросы регулярно, что-то определенно неверно, и вам лучше справиться с этой проблемой (убить процесс запроса просто лечить симптом).

ответил Stefan Magnuson 27 MaramWed, 27 Mar 2013 09:32:50 +04002013-03-27T09:32:50+04:0009 2013, 09:32:50
7

Хотя я думал, что процесс импорта умер, он, вероятно, все еще работает.

Команда DROP DATABASE, вероятно, дождалась завершения импорта базы данных до ее запуска.

Итак, вместо долгого времени DROP DATABASE это скорее всего был импорт.

Если кто-то еще читает это и пытается отменить импорт базы данных и удалить базу данных, я рекомендую сначала найти идентификатор PID (идентификатор процесса) для импорта и запустить его с другого терминала:

$ kill [PID]

... где [PID] будет фактическим PID для процесса.

Вы должны немедленно остановить импорт, если другой терминал все еще подключен.

Вы также можете запустить SHOW PROCESSLIST на вкладке phpMyAdmin SQL. Полученная таблица показывает запущенные процессы, и щелчок «x» рядом с строкой, которую вы хотите убить, должен сделать трюк.

Затем запустите

DROP DATABASE `database_name`;

И все должно быть чистым.


Другой ответ предполагал, что убить процесс в mysql лучше, чем делать его извне. Я не тестировал этот ответ, но это звучит очень правдоподобно. Поэтому я отметил его как «принятый ответ» вместо этого.

ответил Buttle Butkus 3 FebruaryEurope/MoscowbFri, 03 Feb 2012 14:16:40 +0400000000pmFri, 03 Feb 2012 14:16:40 +040012 2012, 14:16:40
3

Первое, что приходит в голову, это статус Checking Permissions...

При выпуске DROP DATABASE mydb; все, что находится внутри /var /lib /mysql /mydb, проверяется, чтобы увидеть, существуют ли разрешения OS для права на удаление каждого файла.

Некоторые считают, что сокращение количества пользователей mysql может помочь

ответил RolandoMySQLDBA 3 FebruaryEurope/MoscowbFri, 03 Feb 2012 22:51:49 +0400000000pmFri, 03 Feb 2012 22:51:49 +040012 2012, 22:51:49
3

Я столкнулся с той же проблемой. Но на этот раз я проверил список процессов; он сказал, что проверяет разрешения на более длительное время. Затем я обнаружил, что mysqld_safe работает от имени root, а права доступа к папкам - только для пользователя mysql. Поэтому я убил запрос, потому что долгое время он говорил об этом в убитом состоянии, но я ждал, пока он отреагирует, тогда он убил запрос и изменил разрешения на уровне папки для root, добавив его в группу и chmod на 770. Затем я выполнил та же самая база данных бла-бла; он работал для меня за 2 секунды для базы данных 20 ГБ.

ответил Mannoj 12 J000000Thursday12 2012, 13:04:20
2

Попробуйте обрезать самые большие таблицы в базе данных youra, прежде чем вы его удалите. Я видел очень похожее поведение при работе с MySQL-архивами трафика брандмауэра, и это очень помогло.

ответил Tim Brigham 27 Jpm1000000pmFri, 27 Jan 2012 17:04:34 +040012 2012, 17:04:34

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132