Mysql как восстановить базу из ibd и frm файлов

Обновлено: 05.07.2024

Ранее я сохранил копию каталога / var / lib / mysql / ddms («ddms» - это имя схемы). Теперь я установил новый MySQL на только что установленную Ubuntu 10.04.3 LTS, запустив apt-get install mysql-server версию 5.1. После того, как я скопировал каталог ddms в / var / lib / mysql, некоторые из его таблиц работают нормально, это таблицы с соответствующим набором из трех файлов: файл .frm, файл .MYD и файл .MYI.

Однако есть две таблицы с различным набором файлов: файл .frm и файл .ibd. Эти две таблицы не отображаются в списке таблиц в phpMyAdmin. Когда я смотрю на журнал ошибок, он говорит:

Пожалуйста, помогите с восстановлением этих двух таблиц. Спасибо.

Эта цитата Роландо от 23, 12 апреля остается в силе и сегодня. «Простое копирование файлов .frm и .ibd из одного места в другое вызывает проблемы». Используйте альтернативу, такую ​​как mysqldump, чтобы получить ваши старые данные в форму, которую можно загрузить, как и планировалось несколько лет назад. Также известен как резервное копирование.

Таблицы InnoDB не могут быть скопированы так же, как таблицы MyISAM.

Простое копирование файлов .frm и .ibd из одного места в другое вызывает проблемы. Копирование файлов .frm и .ibd таблицы InnoDB хорошо только тогда и только тогда, когда вы можете гарантировать, что идентификатор табличного пространства файла .ibd точно соответствует записи идентификатора табличного пространства в метаданных файла ibdata1 .

Вы можете применить предложения из ссылки на Календарь Chris, или вы можете вернуться к старой установке mysql, запустить mysql, а затем mysqldump ddms базу данных. Затем импортируйте этот mysqldump в ваш новый экземпляр mysql. Поверь мне, это будет намного проще.

Таким образом, отдельная таблица не может быть хорошей идеей, но как насчет всей базы данных в то время? Моя таблица пользователей плохо работала, и мне пришлось выполнить --initialize для mysqld. Могу ли я скопировать всю папку базы данных InoDB из папки data_backup? Ваш пост How to Recover an InnoDB table whose files were moved around буквально спас мне жизнь. Большое спасибо.

Я недавно испытал эту же проблему. Вот шаги, которые я использовал, чтобы решить эту проблему без необходимости возиться с идентификатором табличного пространства, как упомянуто выше RolandoMySQLDBA. Я на Mac, и поэтому я использовал MAMP для восстановления базы данных до точки, где я мог бы экспортировать ее в дамп MySQL.

Вы должны иметь:

-FRM файлы из вашей папки mysql_database

-Установка MAMP / MAMP Pro, которую вы готовы уничтожить (при необходимости)

  1. SSH на ваш веб-сервер (dev, production, без разницы) и перейдите в вашу папку mysql (моя была в / var / lib / mysql для установки Plesk в Linux)
  2. Сожмите папку mysql
  3. Загрузите архив папки mysql, которая должна содержать все базы данных mySQL, будь то MyISAM или innoDB (вы можете скопировать этот файл или переместить его в загружаемый каталог, если это необходимо)
  4. Установите MAMP (Mac, Apache, MySQL, PHP)
  5. Перейдите в / Приложения / MAMP / DB / MySQL /
  6. Резервное копирование / Applications / MAMP / db / mysql в zip-архив (на всякий случай)

Скопируйте все папки и файлы, входящие в архив папки mysql, с рабочего сервера (в моем случае это среда mt Plesk), КРОМЕ ТОГО, ЧТОБЫ НЕ ПЕРЕЗАПИСАТЬ:

- / Applications / MAMP / дб / MySQL / MySQL /

- / Applications / MAMP / дб / MySQL / mysql_upgrade_info

- / Applications / MAMP / дб / MySQL / performance_schema

И вуаля, теперь вы должны иметь доступ к базам данных из phpMyAdmin, какое облегчение!

Но мы еще не закончили, теперь вам нужно выполнить mysqldump для восстановления этих файлов в вашей производственной среде, а время ожидания интерфейса phpmyadmin для больших баз данных истекло. Следуйте инструкциям здесь:

Скопировано ниже для справки. Обратите внимание, что при установке MAMP по умолчанию пароль является «root».

Как запустить mysqldump для MAMP с помощью терминала

База данных экспорта от MAMP [1]

Шаг первый: откройте новое окно терминала

Шаг второй: перейдите к установке MAMP, введя следующую строку в терминале cd / Applications / MAMP / library / bin. Нажмите клавишу ввода.

Шаг третий: Напишите команду дампа ./mysqldump -u [ИМЯ ПОЛЬЗОВАТЕЛЯ] -p [DATA_BASENAME]> [PATH_TO_FILE] Нажмите клавишу ввода

Совет: чтобы быстро перейти к папке, вы можете перетащить папку в окно терминала, и она запишет местоположение папки. Это был замечательный день, когда кто-то показал мне это.

Шаг четвертый: эта строка текста должна появиться после того, как вы нажмете «Ввод пароля». Так что, угадайте, что, введите ваш пароль, помните, что буквы не появятся, но они есть.

Шаг пятый: Проверьте место, где вы сохранили свой файл, если он там есть, УСПЕХА Теперь вы можете импортировать базу данных, которая будет изложена далее.

Теперь, когда у вас есть экспорт базы данных mysql, вы можете импортировать его в производственную среду.

получение ошибки 1146 таблица не существует при выполнении дампа

Я восстановил свои файлы MySQL 5.5 * .ibd и * .frm с использованием MySQL Utilites и MariaDB 10.

shell> mysqlfrm --server = root: pass @ localhost: 3306 c: \ MY \ t1.frm - -port = 3310

В противном случае вы можете создать свои sql.

2) Создайте свои таблицы
Создайте свои таблицы в базе данных.

3) alter table xxx сбросить табличное пространство
Откажитесь от ваших таблиц, которые вы хотите заменить ваши * .ibd файлы.

4) Скопируйте ваши * .ibd файлы (MySQL или MariaDB) в путь данных MariaDB.
Сначала я пытаюсь использовать MySQL 5.5 и 5.6 для восстановления, но база данных падает и немедленно останавливается из-за ошибки, связанной с идентификатором табличного пространства. ( ОШИБКА 1030 (HY000): Получена ошибка -1 от механизма хранения )
После того, как я использовал MariaDB 10.1.8 и успешно восстановил свои данные.

5) alter table xxx import tablespace
Когда вы запускаете этот оператор, MariaDB предупреждает о файле, но это не важно, чем восстанавливать ваши данные :) База данных все еще продолжается, и вы можете видеть ваши данные.

Я надеюсь, что эта информация будет полезна для вас.

Это сработало для меня. Хотя mysqlfrm (пробовал версии 1.3.5 и 1.6.5 с MySQL 5.6 и 5.7) не дали правильного CREATE определения, даже при использовании MySQL 5.7 ( ROW_FORMAT по умолчанию изменился в MySQL 5.7.9 ), что привело к Schema mismatch (Expected FSP_SPACE_FLAGS=0x21, .ibd file contains 0x0.) импорту табличного пространства. Вручную добавив ROW_FORMAT=compact в конце CREATE заявления, добился цели . @ JānisElmeris> Manually adding ROW_FORMAT=compact at the end of the CREATE statement did the trick. Это тоже сработало для меня. Благодарность! Sy

У меня была та же проблема, только с файлами в качестве резервной копии.

Я решил скопировать файлы базы данных в / var / lib / mysql / yourdb и ibdata1, который находится в / var / lib / mysql.

Затем я смог убедиться, что могу получить доступ к таблицам mysql -u root -p dbname и запросить некоторые таблицы, которые были ранее повреждены.

Затем я сделал дамп базы данных с помощью mysqldump -u root -p [root_password] [database_name]> dumpfilename.sql

Если вы используете MAMP и не можете запустить MySQL после того, как скопируете свои файлы, я вставил innodb_force_recovery = 2 внутрь, my.ini а затем смог запустить mysql и экспортировать мою базу данных.

Если вы можете восстановить файл * .ibd на исходном сервере MySQL, не забудьте также восстановить права доступа к файлу. В моем случае (MySQL8 на CentOS7) я восстановил файл в /var/lib/mysql/db/tablename.ibd и запустил:

Перед исправлением прав доступа доступ к таблице приводил к ошибке «Сервер MySQL 2006 пропал». После исправления прав доступа таблица работала (даже без перезапуска службы mysqld).

Я собрал посты из похожих тем (чьи ответы здесь не публиковались):

Решение 5: с помощью mysqlfrm команды

Это выглядит подозрительно как ответ только для ссылки. Поскольку все ссылки с нашего собственного сайта, они вряд ли исчезнут, поэтому я согласен с этим @mustaccio Это, кажется, не добавляет особой ценности, поскольку большинство из них также появляется в списке «Связанные» на несколько пикселей справа. Нет, но ты должен понять, что он прав. Вы не добавили никакой ценности. Я отвечал правилом, а не потворствовал вашему ответу. Это на самом деле довольно плохой ответ.

Все, что вам нужно сделать, это установить dbsake:

затем используйте команду frmdump и укажите путь к файлу .frm:

Вы получите заявление о создании. Сделав это, я просто выполнил шаги 2–5, уже упомянутые @Ecd. Надеюсь, это кому-нибудь поможет.

Я действительно ценю Ecd. Что сработало для меня:

1.- У меня была резервная копия базы несколько месяцев назад, это помогло мне поднять эту резервную копию в xampp в Windows 10 и создать таблицы, имеющие структуру (конфигурация: Windows 10, xampp-windows-x64-7.1.30- 5-VC14) MySQL файл конфигурации my.ini в конце

2. После установки старой базы данных я приступил к выполнению команды alter table xxx discard tablespace для каждой таблицы в базе данных, которую я хотел восстановить, а затем к файлам .ibd папки данных в C: / xampp / mysql / data / system был удален (в данном случае именно этот путь)

3. Я приступил к копированию файлов .ibd из базы данных, которую я хотел восстановить, в папку xampp старой базы данных.

4. Скопировав файлы, запустите: alter table xxx import tablespace Для каждой таблицы в базе данных появится предупреждение, но мы его проигнорируем, данные будут загружены в таблицу и могут быть экспортированы позже.

5.- Экспортируйте всю базу данных в файл sql и приступайте к созданию ее в производстве и успешной работе!

Я надеюсь, что это помогает кому-то, кто имеет эту ситуацию, с уважением.


Случается так, что база данных(ibdata1, ib_logfile0) накрывается медным тазом, но к счастливейшему стечению обстоятельств остаются файлы frm и ibd и в настройках mysql выставлено innodb_file_per_table = 1, не стоит расстраиваться шанс восстановления данных мал, но он есть.

Успех зависит от того какой версии mysql вы использовали, если 5.6 и выше, то шансы растут, а если у вас еще есть структура таблиц, то там вообще шансы велики.

Для начала нам необходима структура базы данных, если у вас есть дамп то полдела сделано, нам нужна только структура. Для того что бы вынуть структуру из дампа есть такая утилита как awk и следующее выражение awk '/CREATE TABLE /,/ENGINE=/' dump.sql если конечно дамп сделан mysqldump то все получится, если другой утилитой, то придется подредактировать.

А теперь поговорим про ОС, где все эти манипуляции по восстановлению проводить, мой выбор пал на ubuntu 14.04, потому что там можно накатить любую версию mysql 5.5, 5.6, 5.7.

В общем ставим ubuntu, я ставил на VirtualBox с этого образа mini.iso.
Ставим openssh-server, apache, php, phpmyadmin
Если нужна версия mysql 5.7 нужно добавить репозиторий
И ключ командой apt-key adv --keyserver pgp.mit.edu --recv-keys 5072E1F5

И устанавливаем mysql apt-get install mysql-server-5.X вместо X — версия.
После установки не забудьте добавить в конфиг mysql innodb_file_per_table = 1 и перезапустить сервер /etc/init.d/mysql restart

Ну а теперь самое интересное, если у вас есть структура базы данных пропускайте этот пункт.

Можно попробовать достать структуру бд из файлов frm, для этого заходим в каталог где лежат ваши файлы от бд и выполняем следующие команды:
В корне домашней директории, появится sql файл с созданием одноименных таблицы в бд.

Если у вас база данных без пароля для root, то выполняем следующие команды:
Если с паролем то добавляем параметры -p

После создания одноименных таблиц, останавливаем mysql /etc/init.d/mysql stop переходим в каталог где живут файлы mysql, по дефолту это /var/lib/mysql/, там находим нашу бд recover и заменяем все файлы frm на файлы из бд которую восстанавливаем.

/dbre/ — каталог где хранится бд которую восстанавливаем

Запускаем mysql /etc/init.d/mysql start И смотрим получилось ли у нас что, для этого заходим в mysql
Если покажет структуру таблицы, то ура, делаем dump mysqldump -uroot -d recover >

/struct.sql если напишет recover.table_name does't exist то беда.

А теперь внимание, в mysql 5.6+ появилась возможность импорта ibd файлов, что значительно упрощает весь процесс восстановления, поэтому в любому случае ставим mysql 5.6 или 5.7

В общем если у нас есть структура бд(как ее получить описал выше awk '/CREATE TABLE /,/ENGINE=/' dump.sql >

/struct.sql ), заливаем ее в нашу бд
Теперь надо отключить ibd файлы у каждой таблицы, для этого нужно вновь провести некоторые манипуляции
Создали sql файл, который массово отключит ibd для всех таблиц mysql -uroot recover <

Теперь самое интересное, копируем ibd файлы с базы которой восстанавливаем и подготавливаем sql файл импорта этих ibd файлов:
Скопировали idb файлы и создали sql файл с импортом для всех таблиц, попробуем применить его mysql -uroot recover <

Через phpmyadmin или mysql-workbench можно попробовать посмотреть, что мы там на восстанавливали и если все окей сделать нормальный dump mysqldump -uroot recover > recover.sql У меня так успешно восстановилось две базы данных, с другими двумя, они были версии mysql 5.5< поломались поля DATETIME

Еще есть утилита Percona data recovery tool for innodb, но тоже нужно знать структуру, как ей пользоваться описано в этой статье
Мне не понравилось решение с find для объединения файлов и я накатал свой небольшой скриптик, может кому понравится
Помещаем его в каталог pages-xxxxxxxx/FIL_PAGE_INDEX/ и запускаем, он объеденит все файлы из папок

Этой утилитой я тоже восстановил пару таблиц, в некоторых было все хорошо, в некоторых данные все же были повреждены.

Моя заметка скорее перевод вот этой, на авторство не претендую

И если кому вдруг интересно, я писал про восстановление БД wordpress, там структуру вытащить не получилось, поэтому я пошел более простым путем, я установил чистый wordpress и плагины, и сделал discard и import tablespace, и все отлично восстановилось.

Надо всё таки сказать сразу что для экспериментов я быстренько поднял сервер баз данных аналогичный потерпевшему, что в принципе не является критичным - лишь бы мажорная версия MySQL совпадала, платформа, кстати, тоже особой роли не играет, за исключением того, что Percona Data Recovery Tool for InnoDB штука не кроссплатформенная, поэтому unixway всё таки приветствуется.

Итак, создаём на экспериментальном сервере базу данных аналогичную потерпевшей -
mysql CREATE DATABASE XXX;

после чего, создаём табличку из потерпевшей базы данных:
mysql CREATE TABLE `xxx_xxx` (`id` INT PRIMARY KEY) ENGINE=Innodb;

, но вот в чём закавыка - табличку то надо создать со структурой 100% идентичной потерпевшей, а если мы не знаем структуру, как быть. быть то как я вас спрашиваю?
Да проще простого - не выходя из mysql (например в соседней консоли) копируем старый *.frm файл поверх нового, возвращаемся в mysql, делаем show create table xxx_xxx и видим свою структуру таблички, но, так работать не будет, поэтому, экспортируем табличку, уничтожаем её и создаем импортом (я всё это делал при помощи phpMyAdmin).

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

Останавливаем mysql сервер.
Копируем *.ibd файл нашей таблички от потерпевшей базы поверх нового.
Поправляем владельца файла и права доступа чтобы не поймать в дальнейшем ошибку о том что движок InnoDB не видит файл который есть на диске (чесслово - полдня убил пытаясь понять что происходит - файл то вот он, а движок его в упор не видит).
chown -R mysql:mysql /var/db/mysql/XXX
chmod 660 /var/db/mysql/XXX/xxx_xxx.ibd

И, затем, самое интересное - корректируем существующий в новом файле ibdata1 (или как у вас там) id таблицы в соответствии с тем id который имеет место быть у старого файла. Для этого нам и пригодится чудо инструмент Percona Data Recovery Tool for InnoDB, а именно ibdconnect в его составе.

Делаем магию
ibdconnect -o /var/db/mysql/ibdata1 -f /var/db/mysql/XXX/xxx_xxx.ibd -d XXX -t xxx_xxx

После этого Александр Кузьминский рекомендует сделать ещё innochecksum -f /var/db/mysql/ibdata1, для того, чтобы подкорректировать контрольную сумму файла, иначе движок innodb рухнет со страшным грохотом и криками про несовпадение контрольной суммы. Но я запускаю экспериментальный сервер MySQL с параметром "skip-innodb_checksums" и плюваю на контрольные суммы в целом - это же разовый момент, зачем оно нам?

Финально задаём задаём в my.cnf параметр innodb_force_recovery = 6, зажмурившись запускам MySQL сервер и . ВУАЛЯ. - наши данные видно даже в phpmyadmin, работать с ними конечно не рекомендуется, так как таблица всё таки инвалид в прошлом, и как она будет жить дальше малоизвестно, поэтому сразу же бэкапим всё что только можно:
mysqldump --force --compress --triggers --routines --create-options -u someuser -p --databases XXX > /var/spool/mygreatbackup.sql

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

Нескушных летних ночей и почаще заглядывайте в крон занося строчки бэкапа всего что важно и нужно.

Файл .ibd: механизм InnoDB открывает независимое табличное пространство (конфигурация innodb_file_per_table = 1 в my.ini) для хранения файлов данных и индекса таблицы.

1. Установите ту же версию mysql;

Получить структуру таблицы

2. Получить структуру таблицы (если есть структура таблицы, просто импортируйте таблицу напрямую)

  • Создайте таблицу с тем же именем (InnoDB). Если вы не знаете количество столбцов, вы можете использовать одно поле ( Если количество полей несовместимо, будет сообщено об ошибке. Перейдите в файл журнала, чтобы проверить количество столбцов, и повторите эти шаги. )
  • Закройте службу mysql
  • Замените созданный файл .frm восстанавливаемым файлом .frm.
  • Измените конфигурацию my.ini innodb_force_recovery = 6, чтобы войти в режим восстановления (только для чтения).
  • Запустите службу mysql.
  • desc tble_name или показать создать таблицуtbl_nameПолучите инструкцию для создания структуры таблицы. (Прямой просмотр полей дизайна таблицы вызовет исключения базы данных)
  • Скопируйте sql создания таблицы, удалите таблицу (вы не можете удалить .frm и .ibd напрямую, так как новый отчет о времени уже существует. Если вы удалите файл напрямую, Нужно скопировать файл frm обратно, а затем отбросить таблицу ) выполните sql, чтобы создать структуру таблицы. ( На этом шаге необходимо закомментировать innodb_force_recovery = 6 или вернуться к 0, в противном случае будет предложено только чтение )。

После запуска структуры таблицы не будет, это файл журнала mysql

Найдите расположение файла журнала:


Здесь. Относительно mysql, окна могут найти местоположение mysql в соответствии с ярлыком, а затем найти файл ошибки .err

Это означает, что во вновь созданном файле есть 1 столбец, а в скопированном файле frm - 3 столбца. Узнайте количество столбцов на данный момент и повторите вышеуказанные шаги.


Восстановление данных

Удалить вновь созданное табличное пространство

Оператор удаления табличного пространства однократного выполнения

Чтобы удалить пробелы партиями, выполните следующую инструкцию.

Получите оператор удаления табличного пространства для каждой таблицы и выберите все напрямую для копирования (Navicat)


Добавить проверки ограничения внешнего ключа до и после закрытия и открытия выполнения


2. Скопируйте файл <table_name> .ibd для восстановления в папку целевой базы данных ( В настоящее время вы не можете видеть название таблицы в Navicat, не паникуйте! ! ! ) и изменить права доступа к файлу (файл chown u: g), пакетное изменение разрешений chown mysql: mysql / usr / mysql / data / db_name / *

Импортировать табличное пространство

Оператор импорта табличного пространства однократного выполнения

Пакетный импорт табличного пространства

Это то же самое, что и удаление, без его повторения, копирование выбранного оператора, плюс закрытие открытой проверки, выполнение

Может быть проблема

1. Ошибка mysql 1808: это ошибка, вызванная восстановлением файла mysql 5.6 до версии mysql 5.7. Вам необходимо добавить ROW_FORMAT = COMPACT после оператора построения таблицы

2. Ошибка mysql 1812: скопированный файл ibd не авторизован, используйте файл chown u: g


3. ошибка mysql 1451: невозможно удалить или обновить родительскую строку: чужой

Добавить до и после

подводить итоги

1. Создайте структуру таблицы (используйте ее напрямую с резервным копированием, пропустите первый шаг для получения структуры таблицы)

2. Удалите вновь созданное табличное пространство.

3. Скопируйте файл данных .ibd, чтобы перезаписать вновь созданный файл.

4. Импортируйте табличное пространство.

Следующий контент не имеет ничего общего с технологиями (тело - столица революции, вы не можете использовать свою жизнь за деньги):

Сегодняшний кулинарный опыт

При запекании картофеля с жареной свининой мясо следует разрезать по текстуре (иначе оно легко сломается), а при обжиге можно добавить более легкий соевый соус (экстракт фреш), но соевый соус не должен превышать половину лопатки (иначе он станет углеродом) .Это влияет на аппетит каждого.

Читайте также: