Удаление таблицы MySQL с ожидающими транзакциями


10

Есть ли способ удалить таблицу или базу данных InnoDB с ожидающими транзакциями в MySQL (предпочтительно на уровне файловой системы)?

Что произошло:

Я использую MySQL 5.5.28 и побежал, LOAD DATA INFILE…чтобы импортировать огромный набор данных (300M строк) в таблицу InnoDB. Я не использовал set autocommit = 0;раньше. К сожалению, mysqldбыл остановлен прямо в середине импорта.

Когда я перезагружаюсь mysql, он пытается откатить транзакцию, заполнив системный журнал сообщениями вроде этого:

mysqld_safe [4433]: 121212 16:58:52 InnoDB: ожидание завершения 1 активной транзакции

Проблема заключается в том, что откат выполняется более 25 часов, в течение которых mysqldне принимаются подключения к сокетам.

Я не могу просто удалить /var/lib/mysql/*и начать с нуля, потому что на этой машине есть и другие базы данных / таблицы InnoDB. Однако проблемная таблица является единственной таблицей в отдельной базе данных. Удаление всей таблицы или всей базы данных не является проблемой, поскольку впоследствии я могу повторно импортировать все данные.

Ответы:


8

На самом деле вы ничего не можете сделать, потому что откат выполняется через табличное пространство UNDO внутри ibdata1 , которое должно было бы значительно увеличиться .

Если вы убьете процесс mysqld и перезапустите mysql, он просто перехватит с того места, на котором остановился, как часть цикла восстановления после сбоя.

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: не несет ответственности за потерю данных

То, что вы можете сделать, может привести к потере данных для других таблиц, но есть что-то, что вы можете сделать, чтобы обойти обычный цикл восстановления после сбоя InnoDB.

Существует опция запуска, называемая innodb_force_recovery , которая позволяет обойти различные этапы восстановления после сбоя InnoDB.

Согласно документации MySQL по принудительному восстановлению InnoDB , здесь приведены настройки и их эффекты:

1 (SRV_FORCE_IGNORE_CORRUPT)

Позвольте серверу работать, даже если он обнаружит поврежденную страницу. Попробуйте заставить SELECT * FROM tbl_name перепрыгивать поврежденные индексные записи и страницы, что помогает при выводе таблиц.

2 (SRV_FORCE_NO_BACKGROUND)

Запретить запуск основного потока. Если во время операции очистки произойдет сбой, это значение восстановления предотвращает это.

3 (SRV_FORCE_NO_TRX_UNDO)

Не запускайте откат транзакций после восстановления после сбоя.

4 (SRV_FORCE_NO_IBUF_MERGE)

Запретить операции слияния буфера вставки. Если они вызовут сбой, не делайте их. Не рассчитывайте статистику таблицы.

5 (SRV_FORCE_NO_UNDO_LOG_SCAN)

Не просматривайте журналы отмены при запуске базы данных: InnoDB обрабатывает даже незавершенные транзакции как зафиксированные.

6 (SRV_FORCE_NO_LOG_REDO)

Не выполняйте откат журнала повторения в связи с восстановлением.

С транзакционными изменениями, скрытыми в журналах UNDO и REDO, вы рискуете

  • потеря данных, предназначенных для записи
  • хранение данных, предназначенных для удаления

Если вы ожидаете плохих побочных эффектов, сделайте резервную копию всего / var / lib / mysql и поместите его куда-нибудь на тот случай, если вы захотите скопировать ibdata1, ib_logfile0 и ib_logfile1 и повторить нормальное восстановление.

Если mysql полностью включен в одном из режимов

  • mysqldump все данные, кроме таблицы с ошибками
  • отключение mysql
  • удалите все в / var / lib / mysql, кроме / var / lib / mysql / mysql
  • начать MySQL
  • перезагрузите mysqldump

ПРЕДУПРЕЖДЕНИЕ: убедитесь, что вы резервное копирование все!

Надеюсь, это поможет !!!


1

У меня была похожая ситуация на этой неделе.

И после четырех итераций восстановления полной резервной копии на тестовом сервере и попытки удаления, удаления или уничтожения таблиц с помощью гигантских транзакций, ожидающих обработки, мы в конечном итоге добрались до вечера пятницы и решили просто запустить его. За три дня транзакция завершилась незначительной нагрузкой на сервер, и база данных была в порядке. Это было намного лучше, чем любая из ручных операций с файлами .frm и таблицами mysql, которые пытались и не удавались.

Мое решение: не удаляйте его . Дайте ожидающим транзакциям завершиться, даже если вам придется отложить другие операции на несколько дней, или найти место на диске где-нибудь, или позволить вашему подчиненному серверу взять на себя нагрузку.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.