Как восстановить удаленную таблицу mysql
Восстановление базы данных
Через ПУ
Для восстановления базы данных рекомендуем использовать следующий алгоритм:
1. Создайте бэкап базы данных в ее текущем состоянии. После вы сможете его удалить, убедившись, что он больше не требуется.
2. Удалите базу данных в разделе «Базы данных MySQL».
3. Создайте точно такую же базу данных, с таким же именем и паролем.
4. Перейдите в раздел «Резервные копии» панели управления аккаунтом.
5. Выберите вкладку «Базы данных».
6. Выберите из списка доступную дату с сохраненной резервной копией.
7. Напротив «Восстановить» напротив нужной базы.
8. Подтвердите восстановление, нажав на кнопку «ОК».
Через phpMyAdmin
1. Откройте раздел «Базы данных MySQL» панели управления аккаунтом.
2. Перейдите по ссылке «phpMyAdmin» рядом с именем базы данных, в которую следует загрузить дамп. При переходе понадобится ввести пароль базы данных.
3. В открывшейся панели перейдите в раздел «Импорт», расположенный в верхнем меню.
4. Нажмите на кнопку «Выберите файл» и укажите расположение созданного дампа.
5. После нажатия кнопки «Вперед» таблицы будут загружены в базу данных.
Восстановление отдельных таблиц БД через phpMyAdmin
1. Откройте раздел «Базы данных MySQL» панели управления аккаунтом.
2. Перейдите по ссылке «phpMyAdmin» рядом с именем нужной базы данных.
3. В открывшейся панели отметьте таблицы, которые необходимо восстановить.
4. Перейдите в самый низ страницы и нажмите на выпадающее меню «С отмеченными».
5. Выберите вариант «Восстановить таблицу».
При подключении по SSH
Подключитесь к серверу хостинга по SSH и используйте одну из команд ниже.
Для восстановления базы данных из дампа (при условии, что дамп не был сжат и имеет расширение .sql) в SSH-клиенте необходимо выполнить команду:
Для дампа с расширением .sql.zip необходимо выполнить команду:
Для дампа с расширением .sql.gz:
Для дампа с расширением .sql.bz2:
Возможные ошибки
Процесс прерывается из-за ограничений на хостинге
ERROR #1273: Unknown collation
При импорте может наблюдаться подобная ошибка:
В этом случае, оставив исходный файл без изменений, создайте копию дампа, заменив в ней строки, отвечающие за Collation и кодировку:
После чего осуществите импорт измененного дампа стандартным способом.
ERROR #1062: Duplicate entry
Может встречаться ошибка:
В этом случае, оставив исходный файл без изменений, создайте копию дампа и внесите в него изменения командой:
После импортируйте измененный дамп как обычно.
Как восстановить базу MySQL
В данном примере показано восстановление из заранее сделанного dump-файла (с помощью mysqldump). Если нужна инструкция по созданию резервной копии, читайте Как сделать дамп базы MySQL.
Подготовка базы
Подключаемся к командной оболочке mysql:
* данной командой мы подключимся к СУБД под пользователем root. Опция -p потребует ввода пароля.
Для восстановления базы сначала необходимо ее создать:
> CREATE DATABASE db DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci;
При необходимости, также создаем пользователя, который будет иметь доступ к базе:
> GRANT ALL PRIVILEGES ON db.* TO dbuser@localhost IDENTIFIED BY ‘password’ WITH GRANT OPTION;
Подробнее про создание баз читайте на странице Создание и удаление баз в MySQL/MariaDB.
Из файла через командную строку
Если при создании дампа использовалась gzip, сначала распаковываем архив:
Для удобства, создадим переменную с именем базы:
Команда выполняется из UNIX-shell:
* в данном примере выполняется копирование содержимого таблицы table_name из базы данных new_database_name в базу database_name.
2. Резервирование только одной таблицы.
Если восстановление не является экстренным, и мы имеем доступ к источнику данных, можно выполнить резервирование только нужной нам таблицы. Это делается командой на подобие:
После чего уже выполняем восстановление из дампа.
Возможные ошибки
В процессе восстановления мы можем столкнуться с разными ошибками. Рассмотрим их примеры.
MySQL server has gone away
Во время восстановления базы может выскочить ошибка:
at line xxx: MySQL server has gone away.
Как правило, ее причина в низком значении параметра max_allowed_packet, который отвечает за ограничение выполнения команд из файла. Посмотреть текущее значение можно командой в mysql:
> SHOW VARIABLES LIKE ‘max_allowed_packet’;
Чтобы увеличить значение параметра, открываем конфигурационный файл my.cnf:
* в некоторых версиях СУБД конфиг может находится по пути /etc/my.cnf.d/server.cnf.
В разделе [mysqldump] редактируем или добавляем:
[mysqldump]
.
max_allowed_packet = 512M
* значение для данного параметра не обязательно должно быть таким большим.
systemctl restart mariadb || systemctl restart mysql
Row size too large
Ошибка выскакивает после небольшого времени работы восстановления. Более полный текст выглядит, примерно, так:
ERROR 1118 (42000) at line 608: Row size too large (> 8126). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline.
Причина: ошибка встречается, если в нашей базе есть большое количество текстовых полей и мы используем таблицы типа INNODB. По умолчанию, они имеют ограничение на объем данных, которые можно хранить в одной строке таблицы.
Решение:
Для решения проблемы мы можем добавить опцию innodb_strict_mode со значением 0. Данная опция регламентирует более строгий режим работы СУБД. Это грубое решение, которое позволит нам добиться результата, но мы можем выполнить настройку тонко — об этом можно прочитать на соответствующей странице блога mithrandir.ru.
Мы же сделаем все по-быстрому. Открываем конфигурационный файл СУБД — его местоположение зависит от версии и реализации, например:
* это пример расположения для базы MariaDB 10. Более точное расположение можно найти в файле /etc/my.cnf.
Приводим опцию innodb_strict_mode к виду:
[mysqld]
.
innodb_strict_mode = 0
systemctl restart mariadb
* в данном примере мы перезапустили сервис для mariadb.
MySQL – восстановление повреждённых таблиц
Как известно, любые повреждения происходят в результате каких-либо внешних факторов. Состояние внутренней структуры таблиц баз данных (БД), в данном случае таблиц MySQL, всецело определяет, насколько надёжным будет использование самой БД. На высоконагруженных серверах БД повреждение таблиц отнюдь не редкость. Администраторам, да и самим пользователям порой приходится прибегать к починке структуры таблиц своих БД. О том, по каким причинам повреждаются таблицы и какие существуют методы решения данной проблемы на примере MySQL и будет изложено в данной статье.
Причины повреждения таблиц
Если структура таблиц или хранимые в ней данные были повреждены, то MySQL не сможет прочесть их содержимое. Сами же таблицы обслуживаются специальными движками, которые производят, помимо всего прочего, ещё и чтение и запись сданных. Во время этих процессов могут возникать всевозможные непредвиденные ситуации, в результате которых возникают сбои. Хотя MySQL и способна обрабатывать подобные ситуации, но всё же она не всесильна и всего предусмотреть невозможно. Самыми распространёнными причинами повреждения таблиц обычно являются следующие:
В любом случае, первое, что нужно сделать — это остановить работу MySQL-сервера, сделать резервные копии файлов таблиц, которые по умолчанию находятся в каталоге /var/lib/mysql:
Для выполнения этой команды могут потребоваться привилегии суперпользователя или пользователя, имеющего доступ к каталогу /var/lib/mysql. Только после этого можно приступить к разбору ситуации и проверить, действительно ли таблицы повреждены. Для этого можно воспользоваться командной консолью MySQL. Но предварительно необходимо снова запустить MySQL-сервер. И авторизоваться на нём (от имени пользователя-администратора) с помощью команды:
Здесь username – имя пользователя-администратора в системе MySQL.
Проверка таблиц на предмет повреждений
Проверить таблицы на предмет повреждения можно встроенными средствами MySQL, если для них используется движок MyISAM. Для этого используется специальный запрос «CHECK TABLE». Итак, для начала, после авторизации в системе MySQL (как описано в предыдущей главе) необходимо выбрать интересующую БД:
Здесь db_name – имя требуемой базы данных, таблицы которой нужно проверить. Для получения списка всех имеющихся на сервере БД можно выполнить следующий запрос:
Теперь можно выполнить, собственно, саму проверку:
Как нетрудно догадаться, «db_table» здесь — это имя требуемой таблицы. В данном случае вывод в столбце «Msg-text» говорит о том, что с таблицей всё в порядке.
Восстановление MyISAM-таблиц
В случае, когда повреждения таблиц всё же есть. То с большой степенью вероятности таблицу можно починить, используя запрос «REPAIR TABLE»:
Теперь, если починка завершилась нормально, будет получен следующий вывод:
Как можно видеть, всё довольно просто. Однако, если повреждённых таблиц много, то процесс восстановления может быть довольно трудоёмким. Ну а если же данный способ успеха не принёс, то следует обращаться к более сложным методам починки таблиц, рекомендованных самими разработчиками MySQL.
Восстановление InnoDB-таблиц
В случае, если повреждённые таблицы обслуживались движком InnoDB, то придётся использовать более сложный метод восстановления. Дело в том, что движок InnoDB сам способен следить за исправностью таблиц и устранять повреждения. Однако, если он по каким-либо причинам не справляется с этой задачей, то сервер MySQL останавливается.
Метод восстановления для InnoDB-таблиц рекомендуется разработчиками MySQL и суть его в следующем:
Необходимо сделать изменения в разделе [mysqld], добавив в него строку:
Сохранив сделанные изменения и закрыв редактор nano, можно теперь снова попытаться запустить MySQL-сервер. В большинстве случаев это помогает и если доступ к таблицам удалось получить, то теперь можно создать дамп нужных таблиц, выполнив следующую команду:
Дамп back.dump будет сохранён в подкаталоге backups домашнего каталога текущего пользователя.
Теперь необходимо удалить из БД повреждённую таблицу. Для этого после авторизации в командной консоли MySQL (как описано в главе «Причины повреждения таблиц»), нужно выполнить следующий запрос:
Если БД была предварительно выбрана командой use, то в запросе следует указать только таблицу:
Теперь можно выйти из командной консоли MySQL командой exit. И выполнить загрузку дампа таблицы в БД:
В данном случае вместо «/home/username/backups/back.dump» следует использовать местоположение, куда ранее был сохранён дамп.
Заключение
В заключение следует отметить, что представленные способы восстановления являются пожалуй единственными вариантами, когда восстановление можно произвести «малыми силами» и в сжатые сроки. Если же повреждения слишком масштабные и сильные, то необходимо использовать альтернативные, более сложные способы восстановления.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Восстановление данных из удалённой таблицы без наличия резервной копии
Если вы случайно удалили DROP таблицу, а у вас есть полная резервная копия и никаких изменений в БД не происходило после удаления, то вы легко можете вернуть ваши данные путём восстановления исходной базы данных из резервной копии. Но если ваша база данных модифицировалась после удаления таблицы или у вас нет актуальной резервной копий, то есть ещё способ вернуть все потерянные данные.
Каждая операция DROP полностью фиксируется в журнал транзакций SQL Server. Благодаря этому мы можем откатить любую операцию и получить БД на определённый момент времени, при условии, что вы используете полную модель восстановления (FULL RECOVERY).
Если мы в явной транзакции выполним удаление таблицы, а затем откатим транзакцию, то объект будет восстановлен. Если выполнить следующий код:
то мы получим сообщение об ошибке Msg 208, Level 16, State 1 т.к. таблица Customer была удалена.
Тем не менее, следующий скрипт:
вернёт все записи таблицы Customer т.к. операция удаления будет явно отменена (ROLLBACK).
Но как быть если транзакция уже не активна, например, операция удаления проходила не в явной транзакции или вы после удаления выполнили операцию COMMIT. Означает ли это, что данные пропали безвозвратно, при отсутствии актуальных резервных копий?
К счастью, ответ НЕТ. И вам на помощь может прийти ApexSQL Recover.
ApexSQL Recover – это инструмент восстановления данных SQL Server, он позволяет выполнить восстановление удалённых данных (DELETE и TRUCATE) и восстановить полностью удалённые объекты ( DROP ). Кроме того, вы можете в режиме реального времени восстановить большие двоичные данные (BLOB), тем самым это идеальный инструмент для восстановления, если вы используете SharePoint.
Если у вас нет резервной копии, то для восстановления удалённых данных выполните следующие шаги:
и нажмите далее (Next).
На шаге Are additional data sources available? (дополнительные источники) укажите настройку No additional transaction logs are available (никаких дополнительных журналов транзакций)
Шаг Select a recovery action позволяет выбрать настройку Save recovery script to file, которая выгрузит, в указанный вами файл, сценарий восстановления на T-SQL.
Таким простым способом вы сможете вернуть удалённые данные без восстановления из резервной копии.
Есть ли способ восстановить удаленную базу данных MySQL?
Я случайно сбросил базу данных MySQL на моем сервере. Есть ли способы восстановить удаленную базу данных?
Если вы будете действовать быстро, есть большая вероятность вернуть вашу базу данных. Вероятность выше для InnoDB, для MyISAM она ненулевая, но близкая.
Дело в том, что когда MySQL выполняет DROP TABLE или DROP DATABASE (что по сути то же самое), InnoDB не стирает данные. Страницы с данными все еще на диске.
Вам нужно взять носитель с удаленной таблицей (либо ibdata1, либо образ диска) и найти на нем страницы InnoDB. Инструмент stream_parser из инструментария делает это.
Словарь InnoDB хранится в файле ibdat1. Вам нужно сканировать файл ibdata1 так же, как указано выше:
Теперь вам нужно получить записи из таблиц словаря InnoDB SYS_TABLES и SYS_INDEXES (скажем, ваша таблица sakila.actor):
158 это table_id, запомни это.
Теперь вы можете извлекать записи удаленной таблицы из InnoDB index_id 376. У вас должна быть структура таблицы удаленной таблицы, а именно инструкция CREATE TABLE, с которой таблица была создана. Где это можно взять? Либо из старого бэкапа, либо из другого места. Также возможно восстановить структуру из словаря InnoDB, но я не буду описывать ее в этом ответе. Давайте просто предположим, что у вас это есть.
c_parser выводит записи как дамп, разделенный табуляцией, в стандартный вывод. Дамп может быть загружен командой LOAD DATA. c_parser печатает его в stderr.