На какой платформе работает ваша база данных MySQL?
Джек говорит, попробуйте topanswers.xyz
Есть ли шанс, что диск, на котором находится ваша база данных, был заархивирован, и администратор сервера может вас спасти?
Кеннет Фишер
На рынке существует множество инструментов для восстановления поврежденных баз данных MySQL, но для получения лучших и проверенных результатов вы всегда можете положиться на инструменты Stellar для восстановления вашей базы данных. Инструмент может восстанавливать таблицы InnoDB и MyISAM базы данных MySQL. Вы также можете получить предварительный просмотр восстановленных объектов базы данных, который поможет вам получить представление о восстанавливаемых данных. Пробная демо-версия программного обеспечения доступна бесплатно для восстановления базы данных с полной целостностью и оригинальным форматированием, гарантируя отсутствие потери данных.
Митчел
Ответы:
16
Если вы будете действовать быстро, есть большая вероятность вернуть вашу базу данных. Вероятность выше для 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):
Теперь вы можете извлекать записи удаленной таблицы из InnoDB index_id 376. У вас должна быть структура таблицы удаленной таблицы, а именно инструкция CREATE TABLE, с которой таблица была создана. Где это можно взять? Либо из старого бэкапа, либо из другого места. Также возможно восстановить структуру из словаря InnoDB, но я не буду описывать ее в этом ответе. Давайте просто предположим, что у вас это есть.
c_parser выводит записи как дамп, разделенный табуляцией, в стандартный вывод. Дамп может быть загружен командой LOAD DATA. c_parser печатает его в stderr.
все еще можно восстановить, если после удаления таблицы я создаю новую таблицу и вставляю новые записи?
Оки Эри Ринальди
В этом случае вы теряете index_id, потому что CREATE перезаписывает исходное значение. Вам нужно как-то найти это. Обычно я grep известных строк. Следующие INSERT могут или не могут перезаписать данные. Если нет, то это можно восстановить. Надо попробовать, заранее сказать
невозможно
Эта ссылка дает 404!
Nevermore
@akuzminsky Я делал до "словарь / SYS_INDEXES.sql | grep 158" часть. И это дает мне некоторый index_id для моей таблицы, но он говорит, что с моим index_id нет файла подкачки. пример: 0000000000000376.page (когда я запускаю этот c_parser -6f)
Сампат Шри Анурадха
@SampathSriAnuradha должно быть плохо, когда Фортуна не на твоей стороне. Мне жаль.
Акузминский
11
Там нет простого способа сломать это для вас. Неважно, если вы сбросили БД через phpmyadmin или командную строку. Это прошло.
Человеческая ошибка - одна из причин иметь хороший резервный режим.
Я не религиозен, но я помолюсь, надеясь, что это не слишком важно.
это было очень важно, множество транзакций потеряло
kewl
8
Лучшее, что я мог бы порекомендовать в этом случае, - это размонтировать файловую систему, в которой находился ваш datadir. При необходимости выключите сервер. Позвоните в службу восстановления данных и будьте готовы выложить тысячи, если не десятки, всех, пока платите за бесполезную съемку без поручителей: - \
atxdba
3
Если кто-то в подобной ситуации прочтет это в будущем, я думаю, стоит также предположить, что важно отключить файловую систему или сделать ее доступной только для чтения как можно скорее, если вы собираетесь нанять компанию по восстановлению данных. Чем дольше запись продолжается в файловой системе, тем более вероятно, что кластеры, содержащие ваши удаленные файлы, будут перезаписаны.
Джеймс Л
2
Зависит от вашей настройки. Восстановление возможно, если вы правильно настроили свою систему. Если у вас есть резервная копия, вы можете восстановить ее. и затем примените двоичные журналы к точке непосредственно перед тем, как вы уронили таблицу.
Я предлагаю вам сделать это на другом сервере, после восстановления таблицы вы можете использовать mysqldump для ее извлечения и импорта обратно на рабочий сервер. Это не будет быстрое восстановление, но вы можете восстановить данные.
Если вы не знаете, что делаете, я бы предложил заключить контракт на поддержку с одной из консалтинговых компаний mysql (вероятно, Pythian, Percona, Palamino - лучшие) и попросить их помочь вам в этом.
Ответы:
Если вы будете действовать быстро, есть большая вероятность вернуть вашу базу данных. Вероятность выше для 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 из инструментария делает это.
Он будет сканировать файл, находить страницы InnoDB и сортировать их по типу и index_id. index_id - это идентификатор, который InnoDB использует для ссылки на индекс. Таблица хранится в индексе PRIMARY. Чтобы узнать, какой index_id является вашей удаленной таблицей, вам нужно восстановить словарь InnoDB .
Словарь InnoDB хранится в файле ibdat1. Вам нужно сканировать файл ibdata1 так же, как указано выше:
Теперь вам нужно получить записи из таблиц словаря InnoDB SYS_TABLES и SYS_INDEXES (скажем, ваша таблица sakila.actor):
158 это table_id, запомни это.
Итак, index_id вашей удаленной таблицы (sakila.actor) - 376.
Теперь вы можете извлекать записи удаленной таблицы из InnoDB index_id 376. У вас должна быть структура таблицы удаленной таблицы, а именно инструкция CREATE TABLE, с которой таблица была создана. Где это можно взять? Либо из старого бэкапа, либо из другого места. Также возможно восстановить структуру из словаря InnoDB, но я не буду описывать ее в этом ответе. Давайте просто предположим, что у вас это есть.
c_parser выводит записи как дамп, разделенный табуляцией, в стандартный вывод. Дамп может быть загружен командой LOAD DATA. c_parser печатает его в stderr.
Подробности смотрите в постах:
источник
Там нет простого способа сломать это для вас. Неважно, если вы сбросили БД через phpmyadmin или командную строку. Это прошло.
Человеческая ошибка - одна из причин иметь хороший резервный режим.
Я не религиозен, но я помолюсь, надеясь, что это не слишком важно.
источник
Зависит от вашей настройки. Восстановление возможно, если вы правильно настроили свою систему. Если у вас есть резервная копия, вы можете восстановить ее. и затем примените двоичные журналы к точке непосредственно перед тем, как вы уронили таблицу.
http://dev.mysql.com/doc/refman/5.5/en/mysqlbinlog.html
Я предлагаю вам сделать это на другом сервере, после восстановления таблицы вы можете использовать mysqldump для ее извлечения и импорта обратно на рабочий сервер. Это не будет быстрое восстановление, но вы можете восстановить данные.
Если вы не знаете, что делаете, я бы предложил заключить контракт на поддержку с одной из консалтинговых компаний mysql (вероятно, Pythian, Percona, Palamino - лучшие) и попросить их помочь вам в этом.
желаю тебе удачи
источник