☰

Таблицы MySQL отсутствуют/повреждены после воссоздания

tag-icon • tag-icon database mysql corruption
Таблицы MySQL отсутствуют/повреждены после воссоздания

Вчера я выгрузил свои базы данных MySQL в файл SQL и переименовал файл ibdata1. Затем я пересоздал его, импортировал файл SQL и переместил новый файл ibdata1 в свой каталог данных MySQL, удалив старый.

Я делал это раньше без проблем, однако в этот раз что-то не так. Когда я проверяю базы данных (личные, не MySQL config), они все там, но они пустые... как бы. В каталоге данных все еще есть файлы .ibd с правильным содержимым, и я могу просматривать таблицусписокв базах данных, но не в самих таблицах. (У меня включена опция «файл на таблицу», и я использую InnoDB по умолчанию для всего.)

Например, сURL-адресабаза данных и ееURL-адресаtable, я могу успешно открыть mysql.exe или phpMyAdmin и use urls;. Я даже могу show tables;увидеть ожидаемую таблицу, но затем, когда я пытаюсь describe urls;или select * from urls;, он жалуется, что таблица не существует (хотя онатолькоперечислил его). (Администратор MySQL перечисляет базы данных, но даже не перечисляет таблицы, он указывает, что базы данных полностью пусты.)

Проблема в том, что я уже удалил файл SQL (и не могу восстановить его даже после очистки жесткого диска). Поэтому я пытаюсь найти способ восстановить эти базы данных/таблицы. Я не могу использовать функцию восстановления таблиц, так как она жалуется, что таблица не существует, и я не могу сделать дамп, так как она снова жалуется, что таблицы не существуют.

Как я уже сказал, сами данные все еще присутствуют в файлах .ibd, и имена таблиц присутствуют. Мне просто нужен способ заставить MySQL распознать, что таблицы существуют в базах данных (я могу найти имена столбцов соответствующих таблиц в файле ibdata1 с помощью шестнадцатеричного редактора).

Есть идеи, как я могу исправить этот тип порчи? Я не против засучить рукава, покопаться и предпринять кучу шагов, чтобы исправить это.

Большое спасибо.

альтернативный текст

решение1

Ну, я перепробовал кучу всего и исследовал кучу команд, переключателей и структур (неудивительно, что документация MySQL оказалась наиболее полезной, хотя и обширной — иголка/стог сена). В конце концов некоторые из моих трюков сработали (оказалось, что другие придумали те же трюки, хотя я не видел двух основных частей — восстановление структуры таблицы и восстановление данных — в одном месте, поэтому я публикую их вместе здесь).

Мне пришлось пересоздать файл IBDATA1. К сожалению, при запуске демон обнаруживает базы данных (каталоги), но не считывает таблицы Innodb внутри (файлы IBD/FRM). Поэтому я сделал следующее:

  1. Очистите каталог данных (или переместите исходный и создайте пустой)
  2. Запустите демон и дайте ему создать новый пустой файл IBDATA1.
  3. Импортируйте системные таблицы с помощью скриптов SQL в…\MySQL\share
  4. Создайте фиктивную базу данных и таблицу с тем же именем.
  5. Скопируйте исходный файл FRM
  6. Используйте либо, DESCRIBEлибо лучше, SHOW TABLE CREATEчтобы извлечь структуру таблицы
  7. Далее я использовал DISCARD TABLESPACEна столе
  8. Скопировано поверх исходного файла IBD
  9. Затем я использовалIMPORT TABLESPACE
  10. Наконец, я перезапустил демон с помощьюinnodb-force-recovery=6
  11. И я побежал mysqldumpизвлекать структуры и данные

Конечно, не всегда все было гладко. Некоторые таблицы были в порядке, но некоторые требовали удаления таблицы и базы данных после SHOW TABLE CREATE, и использования этого для повторного создания таблицы перед попыткой импорта данных. Другие даже не работали так далеко, и мне пришлось вручную получать комментарии и имена столбцов из файла FRM с помощью шестнадцатеричного редактора (хотя выяснение того, какие типы данных и атрибуты, ключи и т. д. были дерьмовыми). Кроме того, было много — слишком много — перезапусков демона и клиента.

(Я все еще ищу инструмент, который будет напрямую анализировать файлы FRM/IBD (или хотя бы отображать структуру таблиц из файла FRM), но, похоже, никто не удосужился «обратно разработать» их, хотя исходный код открыт, а форматы файлов общедоступны. Похоже, все довольствуются использованием официальных инструментов MySQL, тем самым создавая прекрасную возможность для фирм, занимающихся восстановлением данных, и фирменных/коммерческих инструментов.)

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

В любом случае, из множества страниц восстановления MySQL в Интернете, которые я видел за последние пару дней, несколько были довольно полезными, и я добавлю их, как только прочешу свою историю, чтобы их откопать.


Надеюсь, это поможет другим в похожей ситуации.

решение2

Возможность перечислить все таблицы и базу данных обычно означает, что файлы *.frm там есть. Это не значит, что для них есть какие-либо данные. Вы пробовали запустить свой процесс mysqldпринудительное восстановление innodb? Если нет, попробуйте, или да, что говорит журнал mysql при запуске?

После этого: никогда, никогда больше не пытайтесь использовать резервные копии подобным образом.

Связанный контент