Чому ДРОФАЦІЯ ДРОПУ займає так довго? (MySQL)

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

Я проводив імпорт великого БД (файл 2 Гб sql), і у мене виникла проблема. Клієнт SSH, здавалося, втратив зв’язок, а імпорт ніби застиг. Я використовував інше вікно для входу в mysql, а імпорт виявився мертвим, застряг у певній таблиці рядків 3M.

Тому я спробував

DROP DATABASE huge_db;

Через 15-20 хвилин нічого. В іншому вікні я зробив:

/etc/init.d/mysqld restart

Повідомлення вікна DROP DB: SERVER SHUTDOWN. Тоді я фактично перезапустив фізичний сервер.

Повернувся назад до mysql, перевірив, а db все ще там, побіг

DROP DATABASE huge_db;

знову, і знову чекаю вже близько 5 хвилин.

Ще раз, це свіжа установка. huge_dbЄ єдиним дб (крім системи DBS). Я клянусь, що раніше і швидко скинув db's великий, але, можливо, я помиляюся.

Я успішно скинув базу даних. Минуло щось на кшталт 30 хвилин. Також зауважте, що я думаю, що я помилявся, коли думав, що імпорт mysqldump мертвий. Термінальне з'єднання було втрачено, але я думаю, що процес все ще тривав. Я, швидше за все, вбив імпортну середину таблиці (таблиця рядків 3M) і, ймовірно, 3/4 шляху через весь db. Введено в оману, що "верх" показав mysql, використовуючи лише 3% пам'яті, коли здавалося, що він повинен використовувати більше.

Відкидання БД закінчилося 30 хвилин, тому, знову ж таки, мені, можливо, не довелося б перезавантажувати сервер і, можливо, я міг би просто чекати закінчення DROP, але я не знаю, як mysql відреагує на отримання запиту DROP для той самий db, який він імпортує через mysqldump.

І все-таки залишається питання, чому потрібно 30min +, щоб знищити базу даних 2 Гб, коли все, що потрібно зробити, - це видалити всі db-файли та видалити всі посилання на БД з information_schema? Яка велика справа?

Замість того, щоб вбивати процес, було б безпечніше, якби ви це зробили в 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 |
+-----+------+-----------+-------------------+---------+------+-------+------------------+

Запит з id 174 блокує видалення бази даних "example", тому перш ніж вбити будь-які процеси, дозвольте MySQL спробувати припинити запит:

$ mysqladmin kill 174

processlistЗнову запустіть команду, щоб підтвердити, що вона вбита.

Якщо це не працює, то, можливо, ви можете подивитися на вбивство помилкового процесу, але перед цим ви можете спробувати перезапустити сервер MySQL.

Ви також можете запускати команди, наприклад "SHOW FULL PROCESSLIST" та "KILL 174" в оболонці MySQL, наприклад, якщо у вас встановлений лише клієнт MySQL. Основний момент - уникати вбивства процесу, використовуючи 'kill' в оболонці, якщо це абсолютно не потрібно.

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

Хоча я думав, що процес імпорту загинув, він, ймовірно, ще тривав.

DROP DATABASEКоманда , ймовірно , чекали бази даних для завершення імпорту , перш ніж він побіг.

Тож, замість того, щоб DROP DATABASEзайняти багато часу, це було, мабуть, лише імпорт.

Якщо хтось інший читає це і намагається скасувати імпорт бази даних та скинути базу даних, я рекомендую спочатку знайти імпорт PID (ідентифікатор процесу) для імпорту та запустити це з іншого терміналу:

$ kill [PID]

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

Якщо інший термінал все ще підключений, вам слід побачити зупинку імпорту негайно.

Ви також можете запустити SHOW PROCESSLISTна вкладці phpMyAdmin SQL. Отримана таблиця показує запущені процеси, а натискання кнопки "x" поруч із рядком, який ви хочете вбити, має зробити трюк.

Потім бігайте

DROP DATABASE `database_name`;

І все повинно бути чисто.

Інша відповідь припускає, що вбивати процес у mysql краще, ніж робити це ззовні. Я не перевіряв цю відповідь, але це звучить дуже правдоподібно. Тому я позначив це як "прийняту відповідь" замість цієї.

Спробуйте обрізати найбільші таблиці у вашій базі даних, перш ніж її скинути. Я бачив дуже схожу поведінку під час роботи з архівами MySQL трафіку брандмауера, і це дуже допомогло.

Перше, що спадає на думку - це статус Checking Permissions...

Коли ви видаєте DROP DATABASE mydb;все всередині / var / lib / mysql / mydb, перевіряється, чи існують права доступу до ОС для права скидання кожного файлу.

Деякі вважають, що зменшення кількості користувачів mysql може допомогти

Я зіткнувся з тією ж проблемою. Але цього разу я перевірив показ процесорного списку; він сказав, що перевірка дозволів довший час. Тоді я виявив, що mysqld_safe працює як root, тоді як дозволи на рівні папки призначені лише для користувача mysql. Отже, я вбив запит, звичайно, це зайняло тривалий час, кажучи, що це вбитий стан, але я чекав, коли він відреагує, тоді він убив запит і змінив дозволи дозволу рівня папки на root, додавши його до групи та chmod на 770. Потім я виконав той самий баз даних крапель; він працював для мене за 2 секунди для 20 ГБ бази даних.