MySQL зависает при импорте дамп базы данных

Question

У нас есть сценарий импорта дампа базы данных из нашей производственной базы данных, который мы используем для восстановления нашей базы данных песочницы. Синтаксис, который мы используем для этого, mysql -u uname -ppass dbname < prod_db_export.sql. Сценарий приступает к созданию первой таблицы и затем делает это:

LOCK TABLES `ad` WRITE;
/*!40000 ALTER TABLE `ad` DISABLE KEYS */;
/*!40000 ALTER TABLE `ad` ENABLE KEYS */;
UNLOCK TABLES;

В таблице ad нет данных, поэтому после строки DISABLE KEYS нет оператора импорта. В любом случае, импорт в данный момент зависает, и когда мы запрашиваем базу данных с processlist, мы видим вывод, подобный этому:

| 5116 | uname     | localhost | dbname     | Field List |   85 | Waiting for table |                        | 
| 5121 | uname     | localhost | dbname     | Query      |   44 | Waiting for table | LOCK TABLES `ad` WRITE | 
| 5126 | uname     | localhost | dbname     | Field List |   23 | Waiting for table |                        | 

Кто-нибудь знает, что могло бы вызвать это? и лучше, как это решить?

Наш SA не хочет перезапускать mysql, если это вообще возможно, потому что он обеспокоен, что перезапустить не удастся (что случилось с нами в прошлый раз, когда у нас была похожая ситуация, и ему пришлось перестроить весь БД, включая все dbs песочниц, из бэкапа).

Впоследствии мы создали новую базу данных dbname2 и смогли успешно выполнить импорт без зависаний и сообщений о блокировке таблицы в списке процессов.

Answer 1

В моем случае это работало после перезапуска службы mysql

sudo service mysql restart

Answer 2

Будучи SA, упомянутым в этом вопросе, я хотел бы отметить несколько вещей:

• Перед удалением БД файлы ibdata были удалены (мы используем таблицу на idb) для этой БД
• Затем база данных была удалена и воссоздана
• При импорте первая таблица является рекламной, и она, кажется, уже заблокирована.

Для меня это будет означать, что в метаданных InnoDB сохраняется информация о блокировке, которая хранится в общем файле ibdata. В прошлый раз у меня были проблемы с синхронизацией метаданных InnoDB с файлами отдельных таблиц ibdata, я все испортил и снова импортировал. Когда я попытался перезапуститься в этом случае, MySQL отказался, так как не смог найти файлы ibd таблицы, которые были удалены, но все еще были в метаданных.

Постоянная проблема здесь - удаление файлов ibd через командную строку, а не удаление базы данных. pebkac.

Answer 3

В моем случае дамп базы данных попытался вставить миллион строк в одном операторе вставки. Правильный дамп пытается за один раз вставить только 1500 строк в одном операторе вставки.

INSERT INTO `employees` (`id`, `name`) VALUES 
(1, 'jack'),
(2, 'mary'),  
--don't have too many of these rows -- start a new INSERT statement
--However, don't go the other extreme and only insert 1 row per insert statement

Answer 4

если вы удалите файлы пространства таблиц inno без предварительного удаления таблиц, то вы вообще не сможете управлять таблицами. сервер может даже отказаться от подключения.

в этом случае вам необходимо использовать параметр innodb_force_recovery .

УБЕДИТЕСЬ, ЧТОБЫ УВЕДОМИТЬ, ЧТО ПРИ ИСПОЛЬЗОВАНИИ ЭТОГО ВАРИАНТА, ДРУГИЕ КЛИЕНТЫ НЕ ПОДКЛЮЧАЮТСЯ И ПОПРОБУЙТЕ ДЕЛАТЬ.

вам, вероятно, нужно установить innodb_force_recovery на 3. Если при завершении работы сервера происходили транзакции, а inno не зафиксировала / откатила их без ошибок, вам, возможно, придется использовать 6.

тогда вы можете УДАЛИТЬ таблицы и базу данных. снова выключите сервер и установите innodb_force_recovery обратно на 0.

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