Я случайно удалил все таблицы. Можно ли восстановить? У меня нет резервной копии.
решение1
Если у вас буквально нет резервной копии, то я на 99% уверен, что вам не повезло.
Если у вас есть какая-либо форма резервной копии, какой бы старой она ни была, то включено ли у вас двоичное ведение журнала через опцию log-bin в файле конфигурации MySQL (my.ini)? Если да, то вы можете восстановить данные с момента последней резервной копии.
Плохое начало недели, чувак, извини.
решение2
Вопрос довольно старый, но на него нет однозначного положительного ответа, поэтому я добавлю свой.
После того, как MySQL удаляет таблицу, данные все еще остаются на носителе некоторое время. Так что вы можете извлечь записи и перестроить таблицу. Позже я напишу об этом в блоге, но пока быстрый набросок.
Вам понадобится структура вашей таблицы (оператор CREATE TABLE).
Если innodb_file_per_table включено, то удаленная таблица находится на разделе диска. Остановите MySQL и перемонтируйте его как read-only как можно скорее. Если MySQL был на корневом разделе (что, кстати, не очень хорошая идея), то сделайте образ или выньте диск и подключите его к другому серверу. Другими словами, остановите все записи.
Если innodb_file_per_table OFF, то просто остановите MySQL.
Затем загрузите и скомпилируйте инструмент un-drop для InnoDB с сайтаhttps://github.com/twindb/undrop-for-innodb/. Подробности смотрите в посте «[Компиляция набора инструментов восстановления TwinDB][1]».
Затем проанализируйте либо раздел диска, либо 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. [1]:https://twindb.com/how-to-recover-innodb-dictionary/
Видеоурок P.S. по Undrop для InnoDB - Обзор Undrop для InnoDBhttps://youtu.be/-1LeLhGjAWM
решение3
Вот что я сделал. В каталоге 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 строк, представляющих недели работы по вводу метаданных, которые, как мы думали, были потеряны навсегда, были сохранены!!
Надеюсь, это кому-то поможет.
решение4
Вы не можете «отменить» DROP TABLE.
Вы можете посмотреть и увидеть, есть ли у MySQLдвоичное ведение журналавключен, возможно, вы сможете извлечь оттуда какие-то данные.
В остальном вы можете забыть о MySQL и оказаться в том же классе проблем, что и "Я случайно удалил некоторые файлы из своей файловой системы". Существуют некоторые инструменты, которые пытаются восстановить файлы, а также есть компании, которые делают это на профессиональной основе.