Восстановить базу данных MySQL с помощью только файла bin-log

Вот КАТАСТРОФА:

Мы работаем в нашей компании с веб-приложением для управления тестированием: TestLink. Одна команда работала над ним более 1 месяца до сих пор. Вчера другая команда тоже хотела начать использовать testLink, поэтому меня попросили установить его для них.

Установка была произведена на том же сервере, где был запущен первый TestLink, я использую WampServer.2.0 в котором я запускаю testLink, поэтому я начал устанавливать его снова, к сожалению, на том же WampServer .. Я немного устал, и я не упомянул при установке, что я давал второй TestLink то же самое имя базы данных как первый .. установка прошла успешно ... но ПОДОЖДИТЕ !! все данные в первой базе данных были УТЕРЯНЫ !! перезаписан пустой и новой базой данных ..! Я чувствовал, что кто-то меня точно убьет!

Итак, я начинаю гуглить, но поскольку с момента установки первого TestLink не было сделано резервных копий базы данных ... я действительно чувствовал, что у меня нет решения ... я пробовал запускать программное обеспечение для резервного копирования перезаписанных и случайно удаленных файлов, это не помогло ... из курс...

я нашел в этот блог рассказ о Бинарные журналы MySQL, но похоже, что для восстановления потерянных данных необходимо иметь хотя бы одну резервную копию. В комплектации мой my.ini файл, log-bin=mysql-bin строка раскомментирована, и я могу найти файлы в mysql \ data \, которые выглядят следующим образом: mysql-bin.00000x

Я запустил mysqlbinlog команду на одном из них, используя: mysqlbinlog --start-datetime="2011-04-01 00:00:00" mysql-bin.000006, что сделало мой экран похожим на матричный, я могу распознать строки, похожие на команды TestLink, кажется, что команда завершилась успешно ... но нет ... таблицы в базе данных остаются неизменными, пустыми ...

Я что-то упускаю? есть ли свет надежды?

Пожалуйста помоги..

mysql database

В bin-log будут записываться все запросы, начиная с момента его запуска, поэтому у вас есть три основных варианта:

Бинарный журнал был включен с самого начала и записывал все запросы в базу данных. В этом случае вы можете просто восстановить всю базу данных из bin-журнала.
У вас есть старая резервная копия, сделанная через некоторое время после включения bin-log. В этом случае вы можете выполнить восстановление из резервной копии, начиная с того места в bin-log, где была сделана резервная копия (инкрементная резервная копия).
Журнал bin не содержит всех запросов из источника базы данных, и у вас нет резервной копии. В этом случае вы (со временем) сможете восстановить все данные, содержащиеся в bin-log, но любые данные, которых там нет, будут потеряны навсегда. Вы можете попытаться вручную восстановить любые недостающие данные, но в зависимости от вашей структуры / размера данных это может быть просто или невозможно.

Судя по звукам, у вас нет резервных копий, что оставляет варианты 1 и 3. Проверьте первый файл bin-log и посмотрите, какая в нем самая ранняя запись, чтобы узнать, какой случай применим к вам. Если вы ищете конкретное использование mysqlbinlog, см. официальная документация что довольно хорошо объясняет.

Если вы когда-нибудь оправитесь от этого, следующее, что вы должны / должны сделать, - это реализовать расписание регулярного резервного копирования базы данных, включая внешние копии.

Я, наконец, избавился от проблемы и минимизировал повреждения, используя файлы bin-log, как сказал uesp. Я использовал mysqlbinlog binlog_file | mysql -u root -p для восстановления 75% данных, содержащихся в БД, плюс ее структура. Остальные 25% были написаны вручную, нам потребовалось около полдня, чтобы вернуть все.

Да, это был плохой опыт, но он обогатил меня: я настроил автоматическое резервное копирование каждый день в 03:00, сжимая .sql дамп, прикрепив его к письму и отправив на другие машины, в случае сгорания основного :)

Спасибо всем за вашу помощь, официальная документация MySQL также была действительно полезной!

Хорошего дня!