У нас только что произошла серьезная катастрофа: кто-то произвел неконтролируемое обновление в производственной базе данных, и очевидно, что процесс резервного копирования не работает уже долгое время, поэтому мы получили серьезную потерю данных. Таблица с 40 миллионами строк теперь заполнена мусором.
Есть ли у кого-нибудь идея восстановить данные? Например, инструмент, использующий восстановление файловой системы?
Факты:
Честно говоря, это не первая крупная катастрофа в нашей компании, но вполне может стать последней. Обычно мы придумываем какую-нибудь идею, чтобы спасти положение, но на этот раз у меня действительно нет идей. Clusterf * ck ...
Изменить: проблема возникла после заявления об обновлении без указания места. Проблема в том, что проблема возникла между полуднем понедельника и утром вторника (по французскому времени) и была обнаружена только сегодня по разным причинам (приложение предлагает инструмент синхронизации, поэтому новые данные вставляются с отсутствующими данными, но внешний ключ в другая таблица теперь полностью сломана). Фактически, почти все строки в таблице (кроме только что вставленной) содержат одни и те же данные (кроме столбца id).
Что касается ibdata * и ib_logfile *, я остановил реплицированный сервер, поэтому они остались такими, как сейчас. Я не могу остановить базу данных на главном сервере, чтобы скопировать файлы.
2 часа и нет ответов? Я думаю, это могло быть только потому, что никто не хочет сообщать вам эту новость.
У вас есть хорошая копия данных где угодно (даже тому, которому месяц или два)? Если нет, боюсь, ты СОЛНЕЧЕН. Вы сделали несколько намеков на синхронизированную копию базы данных, поэтому, если синхронизация была прервана до того, как был выполнен неверный оператор UPDATE, вам нужно будет создать оператор для обновления источника A данными источника B для этой таблицы.
(У меня было это однажды, с MSSQL и доставкой журналов, и, к счастью, я смог остановить доставку журналов до того, как на сайте B были восстановлены неверные данные, и просто выполнил оператор UPDATE между серверами, чтобы исправить мою ошибку).
Как упомянул Марк Б., если у вас включено двоичное ведение журнала (и журнал не был усечен), вы можете восстановить некоторые данные, заставив этот журнал воспроизвести (даже если у вас есть действительно старая копия базы данных. , если ваш журнал не поврежден, все будет в порядке), но это может быть немного случайным.