Видалення таблиці MySQL з відкладеними транзакціями

Чи є можливість видалити таблицю або базу даних InnoDB з відкладеними транзакціями в MySQL (бажано на рівні файлової системи)?

Що трапилось:

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

Коли я перезапускаю mysql, він намагається відмовити транзакцію, наповнюючи системний журнал такими повідомленнями:

mysqld_safe [4433]: 121212 16:58:52 InnoDB: Чекаємо завершення 1 активних транзакцій

Проблема полягає в тому, що відкат працює вже більше 25 годин, протягом яких mysqldне приймається жодне з'єднання з гніздом.

Я не можу просто видалити /var/lib/mysql/*та почати з нуля, оскільки на цій машині є ще деякі бази / таблиці InnoDB. Однак проблемна таблиця - єдина таблиця в окремій базі даних. Видалення всієї таблиці або всієї бази даних не є проблемою, оскільки після цього я можу повторно імпортувати всі дані.

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

CAVEAT: Переконайтесь, що ви створили резервну копію всього !!!

Я сподіваюся, що це допомагає !!!

У мене була схожа ситуація на цьому тижні.

І після чотирьох ітерацій відновлення повної резервної копії на тестовому сервері та спроби скинути, видалити або вбити таблиці з гігантськими відкладеними транзакціями, ми врешті-решт дісталися до п’ятниці вдень і вирішили просто відпустити її. Протягом трьох днів транзакція закінчилася незначним завантаженням сервера, і база даних була нормальною. Що було набагато краще, ніж будь-яка з ручних операцій над .frm файлами та таблицями mysql, які намагалися і не вдалися.

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