На прошлой неделе один из наших разработчиков выполнил запрос на обновление рабочего mysql master. update xxx set yyy=zzz, без где. Мы делаем резервную копию mysql каждый день 00:01, и он делал это 17: xx, есть ли способ восстановить базу данных на какое-то конкретное время в прошлом? Очевидно, мы не можем делать снимок каждую секунду.
Процедура восстановления:
update xxx set yyy=zzzВам нужно будет восстановить из предыдущей резервной копии. Ты можешь только ROLLBACK во время транзакции, т.е. если вы начинаете с BEGIN; вы можете внести изменения, а затем либо подтвердить их с помощью COMMIT; при отмене с помощью ROLLBACK;. Нет другой истории отмены, кроме этой.
Не должно быть необходимости в резервном копировании каждую секунду, но если есть риск, что это может повториться, вы можете рассмотреть более частые sqldump или запретить разработчикам играть с производственной базой данных.
Если у тебя есть двоичный журнал включен, вы могли повторитьвместо отмены всех изменений, сделанных после резервного копирования. Поскольку в двоичном журнале хранятся только запросы, а не данные, это нужно делать, начиная с резервной копии, а не с текущего состояния. Если ошибка произошла на прошлой неделе, это может быть не вариант сейчас, но хорошо, по крайней мере, для включения в будущем.
Ошибка в том, что update xxx set yyy=zzz; у вас есть только один столбец с ложными данными. В зависимости от столбца и того, сколько других таблиц зависят от этих данных, вы можете предотвратить восстановление всей базы данных до предыдущего состояния из последней резервной копии. Если вам повезет, вы сможете взять из дампа только эту конкретную таблицу и изменить INSERT запросы к UPDATE запросы для одного столбца.