Каталог расширений

Популярные теги

3gp       avi       fb2       jpg       mp3       pdf      

Главная » Разное » Mysql как восстановить базу из ibd и frm файлов

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


Как восстановить базы MySQL InnoDB имея на руках только frm и ibd файлы

Случилось у нас тут недавно.... вобщем бэкапы мы вроде как делаем, но, отчего то именно в этот раз всё пошло не так и получилось так, что архивная база оказалась без бэкапа. А файлики ib_logfile* и ibdata* успешно похерились, что привело ненадолго в состояние уныния, но, вспомнив, что уныние есть грех и вобще нефиг там и тут, что сервер был запущен с включеным параметром innodb_file_per_table = 1 (что означает - держим таблички не скопом, а каждый в отдельном файлике), а так же вооружившись гуглом, решил всё таки докопаться до истины и ситуацию исправить.

Итак, что мы имеем:
1. Каталог базы данных с файлами вида *.frm (структура таблицы) и *.ibd (собственно данные).
2. MySQL который в упор не видит эти таблички объявляя базу данных пустой, причём не видит из под phpmyadmin, например, из под консольного клиента по использованию show tables вполне видит таблички, но, при попытке хоть что то сделать с табличками кричит "ERROR 1146 (42S02): Table XXX.xxx_xxx' doesn't exist" (оно и понятно, файл с tablespace то стёрт).
3. В логах сообщение:
"Cannot find or open table XXX/xxx_xxx from
the internal data dictionary of InnoDB though the .frm file for the
table exists. Maybe you have deleted and recreated InnoDB data
files but have forgotten to delete the corresponding .frm files
of InnoDB tables, or you have moved .frm files to another database?
or, the table contains indexes that this version of the engine
doesn't support."

Вооружаемся:
1. Статьями отсюда http://www.chriscalender.com/?p=28=1 и отсюда http://www.mysqlperformanceblog.com/2011/05/13/connecting-orphaned-ibd-files/ (вот прямо по этим статьям у меня ничего не получилось, поэтому пришлось искать свой путь).
2. Комплектом отличных программ для восстановления баз данных innodb отсюда - https://launchpad.net/percona-innodb-recovery-tool
3. Терпением.

Поехали!

Надо всё таки сказать сразу что для экспериментов я быстренько поднял сервер баз данных аналогичный потерпевшему, что в принципе не является критичным - лишь бы мажорная версия 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

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

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

Восстановление базы данных mysql InnoDB если остались только файлы frm и ibd

Случается так, что база данных(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 нужно добавить репозиторий

 deb http://repo.mysql.com/apt/ubuntu/ trusty 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, для этого заходим в каталог где лежат ваши файлы от бд и выполняем следующие команды:

 ls -1 *.frm > ~/tables.sql sed -i 's/^/create table /' ~/tables.sql sed -i 's/.frm/ (id int) engine=innodb;/' ~/tables.sql
В корне домашней директории, появится sql файл с созданием одноименных таблицы в бд.

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

 mysql -uroot -e "create database recover" mysql -uroot recover < ~/tables.sql
Если с паролем то добавляем параметры -p

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

 cd /var/lib/mysql/recover rm -f *.frm cp ~/dbre/*.frm . chmod 660 * chown mysql:mysql *
~/dbre/ — каталог где хранится бд которую восстанавливаем

Запускаем mysql /etc/init.d/mysql startИ смотрим получилось ли у нас что, для этого заходим в mysql

 mysql -uroot use recover; show create table table_name;
Если покажет структуру таблицы, то ура, делаем dump mysqldump -uroot -d recover > ~/struct.sql если напишет recover.table_name does't exist то беда.

Можно попробовать поиграться с параметрами innodb_force_recovery=5, но почему то мне везло только с версий 5.5 mysql server'a и то как то попалась бд от wordpress'a с кодировкой utf8mb4, а в 5.5 естественно нет данной кодировки, и при запросе структуры таблицы выдавал ошибку Unknown collation '#246' Единственный вариант из всех что я видел это mysql workbench он кое как видит структуру, но и то без ключевых полей, а они необходимы, так что если вы примерно знаете структуру, то можно попробовать восстановить.

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

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

 mysql -uroot < ~/struct.sql
Теперь надо отключить ibd файлы у каждой таблицы, для этого нужно вновь провести некоторые манипуляции
 cd /var/lib/mysql/recover ls -1 *.frm > ~/tables.sql sed -i 's/^/alter table /' ~/tables.sql sed -i 's/.frm/ discard tablespace;/' ~/tables.sql
Создали sql файл, который массово отключит ibd для всех таблиц mysql -uroot recover < ~/tables.sql

Теперь самое интересное, копируем ibd файлы с базы которой восстанавливаем и подготавливаем sql файл импорта этих ibd файлов:

 cd /var/lib/mysql/recover cp ~/dbre/*.ibd . chown mysql:mysql * chmod 660 * cp ~/tables.sql ~/tables2.sql sed -i 's/discard/import/' ~/tables2.sql
Скопировали idb файлы и создали sql файл с импортом для всех таблиц, попробуем применить его mysql -uroot recover < ~/tables2.sql

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

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

 #!/bin/bash for dir in `ls -d */ -1 | sort -n` do echo ${dir%%/} for file in `ls -1 $dir | sort -n`;do cat ${dir}/${file} >> data.dat; done; done
Помещаем его в каталог pages-xxxxxxxx/FIL_PAGE_INDEX/ и запускаем, он объеденит все файлы из папок

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

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

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

Делайте бэкапы!

Восстановление базы данных MySQL из .ibd и .frm файлов при помощи сотового телефона

Однажды передо мной возникла такая задача. Есть чужой веб-сервер с рухнувшей MySQL, и ftp-доступ к нему. Нужно перенести файлы на новый сервер и восстановить сайт. Дампа БД нет. Всё, что осталось от БД — файлы .ibd и .frm. А значит, это скорее всего MySQL InnoDB, и просто скопировать файлы, как в случае с MyISAM — не получится. Но восстановить всё же возможно.

Очень помогла вот эта статья: для восстановления таблицы нужно на новом сервере создать по .frm файлу таблицу с прежней структурой, а потом заменить .ibd файл, приведя в соответствие id таблицы в нём и id новой таблицы на сервере. Я попытался воспользоваться вторым из описанных там способов — править в hex-редакторе id таблиц в .ibd. Конечный результат был успешным, лишь пришлось повозиться с теми таблицами, где хранится много записей — в них id содержится не только в начале файла, но и повторяется в каждой странице, и для них больше подошёл бы первый способ (если, конечно, таких таблиц не слишком много).

Но перед тем, как всё получилось, меня ждал ещё один сюрприз. Я создал новую базу данных в Денвере на своём ноутбуке, попробовал, но ничего не заработало. Не понимает MySQL эти файлы, и всё тут. После изучения логов погибшего сервера, для уточнения версии MySQL, причина была найдена: там стоял Percona server.
Отправившись на поиски Percona для Windows, я наткнулся на описание его установки… на Андроид. «Почему бы и не поразвлечься?» — посмотрел я на свой простенький Fly IQ440. Установил Linux Deploy и Ubuntu. Процесс установки оказался не сложнее, чем подключение готового образа к VirtualBox (если на телефоне уже есть права root), но в отличие от VirtualBox на компьютере — здесь не пришлось заниматься колдовством с портами: сразу же заработал интернет, хоть через сотовую сеть, хоть через wifi. Подключившись к телефону через SSH с компьютера, последовал инструкции по вышеприведённой ссылке. Скачалось и без каких-либо проблем установилось необходимое ПО. Я ожидал, что на телефоне всё будет работать очень медленно, но был приятно удивлён: различий с «большим компьютером» на глаз можно и не заметить, а тесты скорости есть по приведённой ссылке. При этом, на самом телефоне, приложение работает в фоне и не вызывает никаких проблем с обычной работой аппарата.

После исправления ошибки для ARM-процессора в исходнике, Percona Server был благополучно скомпилирован и заработал. После решения проблем с восстановлением базы данных, решил систему оставить «на память». Теперь в домашней wifi-сети присутствует ещё один сервер, собранный в таком неожиданном месте.

Восстановление базы данных InnoDB из файлов .ibd — Дюк Юсупов

Дважды с проектом Hattrick Portal попадал в ситуацию «потери» файлов собственной базы MySQL (mysql) — СУБД переставало работать и рапортовало о том, что в первом случае таблицы innodb_index_stats, innodb_table_stats, slave_master_info потеряны, а во втором, что таблицы servers и plugin. Объединяет эти два случая одно — эти таблицы на движке InnoDB. Если раньше все таблицы системной БД mysql были на движке MyISAM, то постепенно MySQL переводит все в InnoDB. С чем связаны были проблемы выяснить не удалось, но нужно было срочно восстанавливать работу СУБД. Быстрое гугление показало один простой вариант — прибиваем все файлы данных, запускаем СУБД с пустыми каталогами данных (она создает их по умолчанию), затем восстанавливаем всё из бэкапа. Но восстановить из бэкапа 10 Гб данных — это долгий процесс. И причем ещё — нужные данные-то у меня все на месте и не пострадали!

Более подробный поиск в сети навел на решение — есть возможность восстановления таблицы из имеющегося файла .ibd, если у нас в СУБД используется опция innodb_file_per_table=1 (т.е. таблицы хранятся в отдельных табличных простраствах, а не в ibdata1. Таким образом можно, например, восстановить всю базу данных по сохранившимся файлам .ibd, без необходимости восстановления из бэкапа (тут, конечно, есть нюансы связанные с потерей данных, если до этого СУБД не корректно завершила работу и не сброшены все блоки в БД).

Для восстановления одной таблицы процесс следующий:

  • переносим во временную папку файл .ibd, соответствующий таблице;
  • если БД «видит» (SHOW TABLES) нашу таблицу, то удаляем её: DROP TABLE таблица;
  • создаем таблицу точно такую же, как была до этого: CREATE TABLE table …;
  • отключаем табличное пространство: ALTER TABLE таблица DISCARD TABLESPACE;
  • соответствующий файл .ibd должен удалиться после удачного выполнения предыдущей команды и таблица размещается в общем табличном пространстве ibdata1;
  • на его старое место копируем сохраненный во временной папке файл .ibd;
  • импортируем табличное пространство: ALTER TABLE таблица IMPORT TABLESPACE;
  • после применения последней команды таблица должна прочитаться со всеми данными, которые были в первом файле .ibd.

По аналогии, для восстановления всей базы данных таким образом соответственно нужно сначала перенести сохранившиеся файлы .ibd во временный каталог. Затем создать такую же структуру таблиц как была. Тут мы вспоминаем, что неплохо бы делать дампы бэкапов не только с данными, но и только со структурой — это сэкономит нам время в этом случае. Т.е. в команду вызова mysqldump нужно добавить опцию —no-data. Например, в моем случае:

@"mysqldump.exe" --host=localhost --port=3306 --user=пользователь --password=пароль --no-data --default-character-set=utf8 --log-error=базаданных.log --set-gtid-purged=OFF --single-transaction 
--add-drop-database --databases базаданных "базаданных.sql"

Если структуры под рукой нет, то вспоминаем про дамп БД, открываем его и ищем последовательно все операторы CREATE TABLE и копируем их содержимое в файл БД.sql. Поскольку файл бэкапа может быть огромным, то открываем его теми просмотровщиками, которые не пытаются полностью считать его в память, например, просмотровщик файлов в Total Commander имеет именно такое свойство. После восстановления структуры, мы готовим и запускаем скрипт вида:

ALTER TABLE таблица1 DISCARD TABLESPACE;
ALTER TABLE таблица2 DISCARD TABLESPACE;
...
ALTER TABLE таблицаN DISCARD TABLESPACE;

Потом возвращаем файлы .ibd обратно м запускаем процесс в обратную сторону скриптом вида:

ALTER TABLE таблица1 IMPORT TABLESPACE;
ALTER TABLE таблица2 IMPORT TABLESPACE;
...
ALTER TABLE таблицаN IMPORT TABLESPACE;

После этого проверяем доступность данных в таблицах, при необходимости выполняем CHECK TABLE таблица; для всех таблиц (хотя в InnoDB данный оператор весьма странно работает). Я на всякий случай выполняю скрипт оптимизации таблиц (см. мою статью MySQL: InnoDB и дефрагментация табличных пространств).

Если что-то пошло не так — у нас остаётся один вариант: восстанавливать БД из дампа. В предыдущей статье (MySQL: Бэкап базы данных и его сжатие) я как раз рассматривал создание сжатых дампов с помощью mydqldump и 7zip и восстановление из них.

Понравилось это:

Нравится Загрузка...

Похожее

Восстановить данные таблицы MYSQL с помощью файлов ibd или frm [duplicate]

Lookbehind теперь является официальной частью спецификации ES 2018 .

Это было в 1998 году, работа Netscape 4, которую я делала в '97, была основана на Perl 4 (!), но мы предложили ECMA TC39 TG1 (группа JS - все было иначе, включая капитализацию), что-то основано на Perl 5. Мы не получили все, и нам пришлось рационализировать некоторые очевидные причуды.

Я не помню, как lookbehind (появившийся в Perl 5.005 в июле 98 года) был специально выделен. Waldemar может вспомнить больше, я передал ему ключи JS внутри netscape.com, чтобы пойти на mozilla.org.

Если вы играете, чтобы написать предложение или мини-спецификацию (в стиле ES5 даже ), дай мне знать.

/ be

blockquote>

В списке рассылки было множество разных элементов с попытками включить его , но он по-прежнему представляется довольно сложной особенностью, потому что EcmaScript Regular Expressions - это backtracking , а backtracking необходим в lookbehind при работе с группами захвата. Это может привести к таким проблемам, как катастрофическое обратное отслеживание при неправильном использовании.

В какой-то момент это было предложено для ES6 / Es 2015, но оно никогда не делало проект, не говоря уже о спецификации , В последнем выпуске в обсуждении кажется, что никто не взял на себя задачу его реализации. Если кто-то чувствует себя призванным для написания реализации, они могут зарегистрироваться для ES Обсудить список и предложить его.

Обновление до 2015 года:

В мае 2015 года , Nozomu Katō предложил реалистичную реализацию ES7 .

Обновление сентябрь 2015:

Regex Look-behind был добавлен как этап 0 Предложение .

Обновление мая 2017 года:

Предложение находится на этапе 3 . Это означает, что теперь по крайней мере два браузера должны реализовать его, чтобы он стал частью следующего стандарта EcmaScript. Как отметил @martixy в комментариях, Chrome реализовал его за экспериментальным флагом JS .

Как восстановить данные таблицы MySQL InnoDB из файлов ibdata и .frm

В этой статье объясняется, как восстанавливать таблицы MySQL при утрате всех или некоторых таблиц или когда MySQL не загружает данные таблицы.

Одна из причин этого – когда данные таблицы повреждены.

В этом конкретном случае, когда вы подключаетесь к серверу базы данных MySQL, вы не видите других таблиц, поскольку они отсутствуют.

В этом сценарии в файле журнала MySQL содержались следующие сообщения:

InnoDB: Error: log file ./ib_logfile0 is of different size 0 46447478 bytes
 InnoDB: than specified in the .cnf file 0 5242880 bytes!
 [ERROR] Plugin 'InnoDB' init function returned error.
 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
 [ERROR] Unknown/unsupported storage engine: InnoDB
 [ERROR] Aborting

 

Метод, описанный ниже, будет работать только для базы данных InnoDB.

Примечание

Прежде чем что-либо сделать, сделайте резервную копию всех файлов и базы данных MySQL в текущем состоянии и сохраните их в безопасном месте.

Чтобы восстановить данные таблицы, убедитесь, что каталог данных и его содержимое не повреждены. В моем случае это было хорошо.

drwx------ 2 mysql mysql 4096 Oct 14 2017 performance_schema
 drwx------ 2 mysql mysql 4096 Dec 12 2017 ndbinfo
 drwx--x--x 2 mysql mysql 4096 Dec 12 2017 mysql
 -rw-rw---- 1 mysql mysql 56 Dec 15 2017 auto.cnf
 drwx------ 2 mysql mysql 4096 Jul 02 2018 bugs
 -rw-r----- 1 mysql mysql 46447478 Mar 24 12:22 ib_logfile0
 -rw-r----- 1 mysql mysql 46447478 Apr 07 2018 ib_logfile1
 -rw-r----- 1 mysql mysql 37954786 Mar 12 12:22 ibdata1
 ..
  • Ibdata1 – этот файл представляет собой системное табличное пространство InnoDB, которое содержит несколько таблиц InnoDB и связанных индексов.
  • * .frm – хранит информацию метаданных для всех таблиц MySQL. Эти файлы находятся внутри папки соответствующей базы данных MySQL. (например, внутри каталога «bugs»)
  • ib_logfile * – Все изменения данных записываются в эти файлы журналов. Это похоже на концепции архивных журналов, которые мы находим в других СУБД.

Скопировать файлы

Чтобы восстановить данные из вышеуказанных файлов, сначала остановите сервер MySQL.

# service mysqld stop

 

Скопируйте файлы ibdata и папку схемы базы данных в другой каталог. Мы будем использовать это для восстановления нашей базы данных MySQL. В этом случае мы скопируем его в каталог /tmp. Имя схемы базы данных в этом примере – это ошибки.

cp –r ibdata* ib_logfile* /tmp
 
 cp –r schema_name/ /tmp/schema_name/

 

Запустите сервер MySQL:

# service mysqld start

 

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

Восстановить данные

Затем восстановите данные таблицы, как описано ниже.

В файле конфигурации my.cnf установите значение следующего параметра в текущий размер файла ib_logfile0. В следующем примере я установил его на 48M, так как это размер, который мы видим для файла ib_logfile0, когда делали «ls -lh ib_logfile0»,

innodb_log_file_size=48M

 

Обратите внимание, что размер файла ib_logfile0 и ib_logfile1 будет таким же.

Скопируйте предыдущие файлы ibdata в соответствующую позицию, в каталог данных mysql.

cp –r /tmp/ibdata* /var/lib/mysql/

 

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

cp –r /tmp/ib_logfile* /var/lib/mysql/
 cp –r /tmp/schema_name/*.frm /var/lib/mysql/schema_name/

 

Наконец, перезапустите сервер MySQL.

service mysqld restart

 

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

 

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Как восстановить данные из MySQL .frm?

Переполнение стека
  1. Около
  2. Товары
  3. Для команд
  1. Переполнение стека Общественные вопросы и ответы
  2. Переполнение стека для команд Где разработчики и технологи делятся частными знаниями с коллегами
  3. Вакансии Программирование и связанные с ним технические возможности карьерного роста
  4. Талант Нанимайте технических специалистов и создавайте свой бренд работодателя
.

Как восстановить базу данных с помощью файлов ibd frm и файлов данных

Привет, ребята,

У меня есть сценарий, в котором у нас есть все файлы в каталоге данных (var / lib / mysql / DB_NAME). У меня нет утилиты дампа для сбора дампа всей базы данных. Теперь, используя эти файлы, как я могу реплицировать БД в другой системе? У нас есть innodb_file_per_table.

1. Какие нужны все файлы из каталога данных? Я знаю, что нам нужны файлы -ibdata1, -ib_logfile0 и -ib_logfile1 и frm. Нужен ли нам еще файл ibd для каждой таблицы? Или любой другой файл?

2. Если мы остановим службу mariadb, просто скопируйте эти файлы в каталог данных во вновь установленной системе и снова перезапустите mariadb. Будет ли он работать и реплицировать базу данных?

3. Если мы можем восстановить базу данных, как мы можем проверить целостность БД, поскольку проверка / восстановление не предназначена для таблиц InnoDB?

Благодарим за любую помощь в этом отношении.

Ответ

Комментарии

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

.

xampp - Как восстановить данные базы данных из файлов .frm с помощью утилит MySQL

Переполнение стека
  1. Около
  2. Товары
  3. Для команд
  1. Переполнение стека Общественные вопросы и ответы
  2. Переполнение стека для команд Где разработчики и технологи делятся частными знаниями с коллегами
.

xampp - Как восстановить базу данных из файлов .ibd, .frm

Переполнение стека
  1. Около
  2. Товары
  3. Для команд
  1. Переполнение стека Общественные вопросы и ответы
  2. Переполнение стека для команд Где разработчики и технологи делятся частными знаниями с коллегами
  3. Вакансии Программирование и связанные с ним технические возможности карьерного роста
  4. Талант Нанимайте технических специалистов и создавайте свой бренд работодателя
  5. Реклама Связаться с разработчиками и техно
.

как восстановить базу данных MySQL из ibdata, журналы ibdata

Переполнение стека
  1. Около
  2. Товары
  3. Для команд
  1. Переполнение стека Общественные вопросы и ответы
  2. Переполнение стека для команд Где разработчики и технологи делятся частными знаниями с коллегами
  3. Вакансии Программирование и связанные с ним технические возможности карьерного роста
  4. Талант Нанимайте технических специалистов и создавайте свой бренд работодателя
.

Как восстановить структуру таблицы из файлов .frm с помощью MySQL Utilities

Структуры таблиц MySQL хранятся в файлах .frm и в словаре данных InnoDB. Иногда, обычно при проблемах с восстановлением данных, нам необходимо восстановить эти структуры, чтобы иметь возможность найти потерянные данные или просто воссоздать таблицы.

Есть разные способы сделать это, и мы уже писали об этом в этом блоге. Например, мы можем использовать инструменты восстановления данных для восстановления структур таблиц из словаря InnoDB Dictionary или из.frm файлы с помощью сервера MySQL. Это сообщение в блоге будет обновлением последнего. Я покажу вам, как легко восстановить структуру из файла .frm, а в некоторых случаях даже без использования сервера MySQL. Это сделает процесс более быстрым и легким для написания сценариев.

mysqlfrm и MySQL Utilities

MySQL Utilities - это набор сценариев, выпущенных Oracle, который помогает нам выполнять некоторые обычные задачи администраторов баз данных более простым способом. Он написан на Python, и его единственная зависимость - это Python Connector.Из большого списка утилит мы собираемся использовать mysqlfrm , инструмент, который поможет нам восстановить структуру.

Как обычно, изображение стоит тысячи слов. Давайте восстановим некоторые структуры таблиц:

Это таблица, которая у нас есть:

СОЗДАТЬ ТАБЛИЦУ `new_table` ( ʻId` int (11) NOT NULL AUTO_INCREMENT, `name` varchar (45) ПО УМОЛЧАНИЮ NULL, ʻAge` tinyint (4) НЕ NULL, ПЕРВИЧНЫЙ КЛЮЧ (ʻid`), КЛЮЧ `name_idx` (` name`) ) ENGINE = InnoDB DEFAULT CHARSET = latin1

CREATE TABLE `new_table` (

ʻid` int (11) NOT NULL AUTO_INCREMENT,

` name` varchar (45) DEFAULT NULL,

tinyint (4) NOT NULL,

PRIMARY KEY (ʻid`),

KEY `name_idx` (` name`)

) ENGINE = InnoDB DEFAULT CHARSET = latin1

Итак, давайте попробуем восстановить это информация из.frm и посмотрим, что у нас получится:

$ mysqlfrm --diagnostic /usr/local/mysql/data/test/new_table.frm # ВНИМАНИЕ: невозможно сгенерировать имена наборов символов или сопоставления без параметра --server. [...] СОЗДАТЬ ТАБЛИЦУ `test`.`new_table` ( ʻId` int (11) NOT NULL AUTO_INCREMENT, `name` varchar (45) ПО УМОЛЧАНИЮ NULL, ʻAge` tinyint (4) НЕ NULL, ПЕРВИЧНЫЙ КЛЮЧ `PRIMARY` (ʻid`), КЛЮЧ `name_idx` (` name`) ) ДВИГАТЕЛЬ = InnoDB;

$ mysqlfrm --diagnostic / usr / local / mysql / data / test / new_table.frm

# ВНИМАНИЕ: Невозможно сгенерировать имена наборов символов или сопоставления без параметра --server.

[...]

CREATE TABLE `test`.`new_table` (

ʻid` int (11) NOT NULL AUTO_INCREMENT,

` name` varchar (45) DEFAULT NULL,

ʻage `tinyint (4) NOT NULL,

ПЕРВИЧНЫЙ КЛЮЧ` PRIMARY` (ʻid`),

KEY `name_idx` (` name`)

) ENGINE = InnoDB;

Довольно хороший результат 🙂

Важно отметить, что у этого инструмента есть два разных способа восстановления.

  • Сначала создается новый экземпляр MySQL и запускается восстановление структуры, очень похожее на то, что PeterZ объяснил в своем блоге. Вам нужно будет использовать каталог –server или –basedir вместе с –port. Он выключит созданный экземпляр после завершения восстановления.
  • Второй, используемый с –diagnostic, читает файл .frm побайтно, чтобы восстановить всю возможную информацию, но без требования экземпляра MySQL. Таким образом, этот метод можно использовать для восстановления всей информации из поврежденной.frm, которые не может прочитать даже MySQL.

Как видно из предупреждения в последнем примере, не всю информацию можно восстановить вторым методом. Например, набор символов или сопоставление невозможно восстановить без параметра –server (первый метод). Давайте посмотрим, как использовать созданный сервер для восстановления информации .frm:

$ mysqlfrm [email protected] --port 3307 ./new_table.frm # Источник на 127.0.0.1: ... подключен. # Запуск порожденного сервера на порту 3307 ... готово.# Чтение файлов .frm # # Чтение файла new_table.frm. # # Оператор CREATE для ./new_table.frm: # СОЗДАТЬ ТАБЛИЦУ `new_table` ( ʻId` int (11) NOT NULL AUTO_INCREMENT, `name` varchar (45) ПО УМОЛЧАНИЮ NULL, ʻAge` tinyint (4) НЕ NULL, ПЕРВИЧНЫЙ КЛЮЧ (ʻid`), КЛЮЧ `name_idx` (` name`) ) ENGINE = InnoDB DEFAULT CHARSET = latin1

1

2

3

4

5

6

7

8

9

100002 9

100002

14

15

16

17

$ mysqlfrm --server = root @ 127.0.0.1 --port 3307 ./new_table.frm

# Источник на 127.0.0.1: ... подключен.

# Запуск порожденного сервера на порту 3307 ... готово.

# Чтение файлов .frm

#

# Чтение файла new_table.frm.

#

# Оператор CREATE для ./new_table.frm:

#

CREATE TABLE `new_table` (

ʻid` int (11) NOT NULL AUTO_INCREMENT,

` name` varchar (45) ПО УМОЛЧАНИЮ NULL,

ʻage` tinyint (4) NOT NULL,

PRIMARY KEY (ʻid`),

KEY `name_idx` (` name`)

) ENGINE = InnoDB DEFAULT CHARSET = latin1

Инструмент подключается к серверу MySQL, получает всю необходимую информацию (на основе и т.д.) и создает новый экземпляр на порту 3307.Затем он использует этот новый экземпляр для восстановления информации из файла .frm. Быстро и легко 🙂

Следует отметить, что не вся необходимая информация хранится в этих файлах .frm. Есть некоторые вещи, которые мы не сможем восстановить, например, ограничения FK и числовые последовательности AI.

Заключение

MySQL Utilities - очень полезный набор инструментов. В этом конкретном случае mysqlfrm может использоваться для восстановления большого списка структур таблиц из их файлов .frm, что делает процесс быстрым и легким для написания сценария.

Связанные

.

Смотрите также