Вопросы Теги

MySQL Tables Missing/Corrupt After Recreation

Сокращение большой лист Застежки на липучке и формы те мини-полосы, которые стоят 10x's слишком много!

1
задан 8 March 2017 в 20:00
2 ответа

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

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

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

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

(Я все еще ищу инструмент, который непосредственно проанализирует файлы FRM/IBD (или по крайней мере отобразит структуру таблицы из файла КАДРА), но похоже, что никто не потрудился “перепроектировать” их даже при том, что это - открытый исходный код, и форматы файлов общедоступны. Кажется, что все - удовлетворенное использование официальных инструментов MySQL — таким образом создание прекрасной возможности для фирм по восстановлению данных и собственных/коммерческих инструментов.)

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

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


Надежда это может помочь другим в аналогичной ситуации.

1
ответ дан 4 December 2019 в 02:04

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

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

0
ответ дан 4 December 2019 в 02:04
  • 1
    Как я сказал, и КАДР и файлы IBD для баз данных, и их таблицы присутствуют и прекрасны, и I’m с помощью файла на таблицу для всего кроме системной таблицы. Единственная вещь that’s добралась, проблемой является IBDATA1. Да, я пытался вызвать его, но это справка didn’t. Я don’t вспоминают то, что журнал, сказанный, потому что это было давным-давно (I’ve сделал несколько копий и попробовал миллион вещей с тех пор, таким образом, я can’t находят записи в журнале от той точки). –  Synetech 6 June 2010 в 17:39
  • 2
    Я понятия не имею, что Вы подразумеваете под резервными копиями “using как that”. Я вывел данные и структуры, как любой будет и импортировал их, как любой будет. Как я сказал, я сделал то же самое прежде, и оно было прекрасно. Я удалил файл SQL, потому что это, казалось, было прекрасно как прошлый раз, и это, вероятно, было некоторое время после. Что-то было повреждено позже так или иначе (из пространства? катастрофический отказ???); это происходит. –  Synetech 6 June 2010 в 17:43
  • 3
    Дамп: хорошо, Импорт: хорошо. Ожидание, что файл данных InnodDB может просто быть передан (" перемещенный новый ibdata1 файл в мои данные MySQL directory"): ошибка, не полагайтесь на это, никогда. И при запуске MySQL eerver you' d, вероятно, все еще получают журналы ошибок, когда что-то неправильно пока он isn' t зафиксированный. Мораль истории: даже если MySQL хранит it' s данные в файловой системе, don' t ожидают, что можно переместить что-либо там. Несомненно, много времени это работает, но случаи когда это doesn' t работа not' t стоящий того. –  Wrikken 6 June 2010 в 18:40

Теги

Похожие вопросы