Я случайно уронил все столы. Могу ли я восстановить обратно? У меня нет резервной копии.
Я случайно уронил все столы. Могу ли я восстановить обратно? У меня нет резервной копии.
Ответы:
Если у вас буквально нет резервной копии, то я на 99% уверен, что вам не повезло.
Если у вас есть какая-либо форма резервного копирования, какой бы старой она ни была, то включена ли бинарная регистрация через опцию log-bin в файл конфигурации MySQL (my.ini)? Если это так, вы можете восстановить с момента последнего резервного копирования.
Плохой способ начать неделю, чувак, извини.
Вопрос довольно старый, но нет однозначного положительного ответа, поэтому я добавлю один.
После того, как MySQL удаляет таблицу, данные некоторое время остаются на носителе. Таким образом, вы можете получить записи и перестроить таблицу. Позже я напишу об этом в блоге, а пока о быстром наброске.
Вам потребуется структура вашей таблицы (оператор CREATE TABLE).
Если innodb_file_per_table включен, удаленная таблица находится на разделе диска. Остановите MySQL и заново смонтируйте его как доступный только для чтения. Если MySQL был в корневом разделе (кстати, это не очень хорошая идея), тогда возьмите образ или извлеките диск и подключитесь к другому серверу. Прекратить все записи другими словами.
Если innodb_file_per_table OFF, тогда просто остановите MySQL.
Затем загрузите и скомпилируйте инструмент удаления для InnoDB с https://github.com/twindb/undrop-for-innodb/ . Обратитесь к сообщению " Compiling TwinDB recovery toolit " для получения подробной информации.
Затем разберите либо раздел диска, либо ibdata1 (в зависимости от настройки innodb_file_per_table) с помощью stream_parser:
./stream_parser -f /path/to/diskimage_or_ibdata1
Затем восстановите словарь InnoDB, чтобы узнать, в каком index_id была удаленная таблица.
Затем возьмите структуру таблицы и получите записи
./c_parser -f pages-diskimage_or_ibdata1/FIL_PAGE_INDEX/00000<index_id>.page
Он выведет записи в stdout и команду LOAD DATA в stderr.
Вот что я сделал. В каталоге mysql (для Ubuntu это / var / lib / mysql, для Mac с использованием Homebrew это / usr / local / var / mysql) я нашел несколько файлов. Сначала я скопировал каталог myapp_development /, содержащий конкретную схему, в мой локальный каталог mysql. Затем я скопировал свой локальный ibdata1 и скопировал ibdata1 сервера в каталог mysql. Убил mysqld. ( ps auxчтобы найти PID, затем kill PID). Перезапустил mysql, он запустился в режиме восстановления после сбоя. Затем запустил мой локальный клиент mysql и сгенерировал полный дамп нужных мне таблиц.
И 15 000 строк, представляющих недели работы с метаданными, которые, как мы думали, исчезли навсегда, сохранены!
Надеюсь, это кому-нибудь поможет.
К сожалению, вы мало что можете сделать, кроме как извлечь очень ценный урок о необходимости хорошего плана резервного копирования.
В зависимости от типа таблицы вы можете найти эксперта, который сможет собрать воедино данные из того, что они оставили на диске, но такой криминалистический анализ будет очень очень очень дорогим (поскольку потребует относительно необычных навыков) и совсем не гарантируется быть действительно полезным.
Если это таблица MyISAM, вам нужно просто восстановить файлы таблиц в / var / log / mysql или в любом другом каталоге данных. Для этого вы можете использовать утилиту ext3grep .
Вы не можете «отменить» а DROP TABLE.
Вы можете посмотреть, было ли в MySQL включено двоичное ведение журнала , может быть, вы можете извлечь некоторые данные оттуда.
Кроме этого, вы можете забыть о MySQL, и у вас возник такой же класс проблем: «Я случайно удалил некоторые файлы из моей файловой системы». Есть некоторые инструменты, которые пытаются восстановить файлы, и есть также компании, которые делают это на профессиональной основе.
Если у вас включено двоичное ведение журнала, вы можете просто заново создать таблицу, если у вас есть схема. Убедитесь, что вы создаете схему, когда у вас отключены binlogs. Или вы можете просто пропустить сеанс. Затем вы можете воспроизводить бины до последнего оператора, который был самой таблицей удаления.
Если нет, то вы можете восстановить с помощью резервной копии, если у вас есть. Если у вас есть CSV-файлы, вы можете использовать метод загрузки данных для восстановления данных. Если вы восстанавливаетесь из mysqldump, вы можете подумать о восстановлении одной таблицы из файла дампа, а не о восстановлении полной базы данных. Если размер данных слишком велик, вы можете отключить ключи перед загрузкой, что значительно ускорит процесс восстановления.
В будущем вам может понравиться задержанный раб, отставание примерно на 10-24 часа. Вы можете создать отложенное ведомое устройство, используя набор инструментов Percona (pt-slave-delay)