Я случайно уронил все столы. Могу я восстановить обратно? У меня нет резервной копии.
Если у вас буквально нет резервной копии, то я на 99% уверен, что вам не повезло.
Если у вас есть какая-либо форма резервного копирования, даже если она старая, то включается ли двоичное ведение журнала с помощью параметра log-bin в файле конфигурации MySQL (my.ini)? Если это так, их можно будет восстановить с момента последней резервной копии.
Плохой способ начать неделю, чувак, извини.
Вопрос довольно старый, но на него нет однозначного положительного ответа, поэтому я добавлю его.
После того, как MySQL удаляет таблицу, данные еще какое-то время остаются на носителе. Таким образом, вы можете получать записи и перестраивать таблицу. Позже я напишу об этом в блоге, а пока сделаю небольшой набросок.
Вам потребуется структура вашей таблицы (оператор CREATE TABLE).
Если innodb_file_per_table ВКЛЮЧЕНА, отброшенная таблица находится в разделе диска. Остановите MySQL и повторно смонтируйте его как доступный только для чтения как можно скорее. Если MySQL был в корневом разделе (что, кстати, не очень хорошая идея), возьмите образ или извлеките диск и подключите его к другому серверу. Другими словами, прекратить все писать.
Если innodb_file_per_table OFF, просто остановите MySQL.
Затем загрузите и скомпилируйте инструмент un-drop для InnoDB из https://github.com/twindb/undrop-for-innodb/. Проверьте "Компиляция набора инструментов для восстановления TwinDB"сообщение для подробностей.
Затем проанализируйте либо раздел диска, либо 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
Он выводит записи на стандартный вывод, а команду ЗАГРУЗИТЬ ДАННЫЕ - на стандартный вывод.
Вот что я сделал. В каталоге 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 и попасть в тот же класс проблем, что «Я случайно удалил некоторые файлы из своей файловой системы». Есть некоторые инструменты, которые пытаются восстановить файлы, и есть компании, которые делают это на профессиональной основе.
Если у вас включено двоичное ведение журнала, вы можете сначала воссоздать таблицу, если у вас есть схема. Убедитесь, что вы создаете схему, когда у вас отключены бинлоги. Или вы можете просто пропустить сеанс. Затем вы можете воспроизвести двоичные журналы до последнего оператора, который был самой таблицей удаления.
Если нет, то вы можете восстановить, используя резервную копию, если она у вас есть. Если у вас есть файлы csv, вы можете использовать метод load data infile для восстановления данных. Если вы восстанавливаетесь с помощью mysqldump, вы можете рассмотреть возможность восстановления одной таблицы из файла дампа, а не восстановления всей базы данных. Если размер данных слишком велик, вы можете рассмотреть возможность отключения ключей перед загрузкой, это значительно ускорит процесс восстановления.
На будущее вам может понадобиться задержанный раб примерно на 10-24 часа. Вы можете создать отложенное ведомое устройство с помощью инструментария percona (pt-slave-delay)