Есть ли способ восстановить удаленную базу данных MySQL?

Я случайно сбросил базу данных MySQL на моем сервере. Есть ли способы восстановить удаленную базу данных?

mysql

— Kewl
источник

На какой платформе работает ваша база данных MySQL?

— Джек говорит, попробуйте topanswers.xyz

Есть ли шанс, что диск, на котором находится ваша база данных, был заархивирован, и администратор сервера может вас спасти?

— Кеннет Фишер

На рынке существует множество инструментов для восстановления поврежденных баз данных MySQL, но для получения лучших и проверенных результатов вы всегда можете положиться на инструменты Stellar для восстановления вашей базы данных. Инструмент может восстанавливать таблицы InnoDB и MyISAM базы данных MySQL. Вы также можете получить предварительный просмотр восстановленных объектов базы данных, который поможет вам получить представление о восстанавливаемых данных. Пробная демо-версия программного обеспечения доступна бесплатно для восстановления базы данных с полной целостностью и оригинальным форматированием, гарантируя отсутствие потери данных.

— Митчел

Ответы:

Если вы будете действовать быстро, есть большая вероятность вернуть вашу базу данных. Вероятность выше для InnoDB, для MyISAM она ненулевая, но близкая.

Дело в том, что когда MySQL выполняет DROP TABLE или DROP DATABASE (что по сути то же самое), InnoDB не стирает данные. Страницы с данными все еще на диске.

В зависимости от настройки innodb_file_per_table процесс восстановления отличается. Если innodb_file_per_table выключен (по умолчанию до 5.5), то удаленная таблица остается в ibdata1. Если innodb_file_per_table включен (по умолчанию на 5.5), то удаленная таблица была в соответствующем файле .ibd. MySQL удаляет этот файл при удалении таблицы.

Самое первое, что нужно сделать, это остановить любые возможные записи, чтобы ваша таблица не была перезаписана. Если innodb_file_per_table выключен, этого достаточно, чтобы остановить MySQL (kill -9 еще лучше, но сначала убедитесь, что вы убили safe_mysqld). Если innodb_file_per_table включен, то размонтировать раздел, где MySQL хранит свои данные. Если datadir находится в корневом разделе, я рекомендую завершить работу сервера или, по крайней мере, сделать образ диска. Позвольте мне повторить, цель состоит в том, чтобы предотвратить перезаписывание удаленной таблицы MySQL или операционной системой.

Существует инструмент, позволяющий работать со страницами InnoDB на низком уровне, инструментарий восстановления данных TwinDB . Я буду использовать это, чтобы проиллюстрировать восстановление.

Вам нужно взять носитель с удаленной таблицей (либо ibdata1, либо образ диска) и найти на нем страницы InnoDB. Инструмент stream_parser из инструментария делает это.

./stream_parser -f /path/to/disk/image

Он будет сканировать файл, находить страницы InnoDB и сортировать их по типу и index_id. index_id - это идентификатор, который InnoDB использует для ссылки на индекс. Таблица хранится в индексе PRIMARY. Чтобы узнать, какой index_id является вашей удаленной таблицей, вам нужно восстановить словарь InnoDB .

Словарь InnoDB хранится в файле ibdat1. Вам нужно сканировать файл ibdata1 так же, как указано выше:

./stream_parser -f /var/lib/mysql/ibdata1

Теперь вам нужно получить записи из таблиц словаря InnoDB SYS_TABLES и SYS_INDEXES (скажем, ваша таблица sakila.actor):

./c_parser -4Df pages-ibdata1/FIL_PAGE_INDEX/0000000000000001.page -t dictionary/SYS_TABLES.sql | grep sakila/actor
000000000B28  2A000001430D4D  SYS_TABLES  "sakila/actor"  158  4  1 0   0   ""  0

158 это table_id, запомни это.

./c_parser -4Df pages-ibdata1/FIL_PAGE_INDEX/0000000000000003.page -t dictionary/SYS_INDEXES.sql | grep 158
000000000B28    2A000001430BCA  SYS_INDEXES     158     376     "PRIMARY"       1       3       0       4294967295
000000000B28    2A000001430C3C  SYS_INDEXES     158     377     "idx\_actor\_last\_name"        1       0       0       4294967295

Итак, index_id вашей удаленной таблицы (sakila.actor) - 376.

Теперь вы можете извлекать записи удаленной таблицы из InnoDB index_id 376. У вас должна быть структура таблицы удаленной таблицы, а именно инструкция CREATE TABLE, с которой таблица была создана. Где это можно взять? Либо из старого бэкапа, либо из другого места. Также возможно восстановить структуру из словаря InnoDB, но я не буду описывать ее в этом ответе. Давайте просто предположим, что у вас это есть.

./c_parser -6f pages-ibdata1/FIL_PAGE_INDEX/0000000000000376.page -t actor.sql > dump.tsv 2> load_cmd.sql

c_parser выводит записи как дамп, разделенный табуляцией, в стандартный вывод. Дамп может быть загружен командой LOAD DATA. c_parser печатает его в stderr.

Подробности смотрите в постах:

— akuzminsky
источник

все еще можно восстановить, если после удаления таблицы я создаю новую таблицу и вставляю новые записи?

— Оки Эри Ринальди

В этом случае вы теряете index_id, потому что CREATE перезаписывает исходное значение. Вам нужно как-то найти это. Обычно я grep известных строк. Следующие INSERT могут или не могут перезаписать данные. Если нет, то это можно восстановить. Надо попробовать, заранее сказать

— невозможно

Эта ссылка дает 404!

— Nevermore

@akuzminsky Я делал до "словарь / SYS_INDEXES.sql | grep 158" часть. И это дает мне некоторый index_id для моей таблицы, но он говорит, что с моим index_id нет файла подкачки. пример: 0000000000000376.page (когда я запускаю этот c_parser -6f)

— Сампат Шри Анурадха

@SampathSriAnuradha должно быть плохо, когда Фортуна не на твоей стороне. Мне жаль.

— Акузминский

Там нет простого способа сломать это для вас. Неважно, если вы сбросили БД через phpmyadmin или командную строку. Это прошло.

Человеческая ошибка - одна из причин иметь хороший резервный режим.

Я не религиозен, но я помолюсь, надеясь, что это не слишком важно.

— atxdba
источник

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

— kewl

Лучшее, что я мог бы порекомендовать в этом случае, - это размонтировать файловую систему, в которой находился ваш datadir. При необходимости выключите сервер. Позвоните в службу восстановления данных и будьте готовы выложить тысячи, если не десятки, всех, пока платите за бесполезную съемку без поручителей: - \

— atxdba

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

— Джеймс Л

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

http://dev.mysql.com/doc/refman/5.5/en/mysqlbinlog.html

Я предлагаю вам сделать это на другом сервере, после восстановления таблицы вы можете использовать mysqldump для ее извлечения и импорта обратно на рабочий сервер. Это не будет быстрое восстановление, но вы можете восстановить данные.

Если вы не знаете, что делаете, я бы предложил заключить контракт на поддержку с одной из консалтинговых компаний mysql (вероятно, Pythian, Percona, Palamino - лучшие) и попросить их помочь вам в этом.

желаю тебе удачи

— Аллен Киннард
источник