Чтобы восстановить базу данных InnoDB до текущего состояния с момента создания физической резервной копии, необходимо запустить сервер MySQL с включённым бинарным протоколированием, даже перед созданием резервной копии. Для достижения восстановления в определённый момент времени после восстановления резервной копии можно применить изменения из бинарного журнала, произошедшие после создания резервной копии. См. Раздел 9.5, «Восстановление в определённый момент времени (инкрементальное)».

Если ваша база данных повреждена или произошёл сбой диска, необходимо выполнить восстановление с помощью резервной копии. В случае повреждения, сначала найдите резервную копию, которая не повреждена. После восстановления основной резервной копии выполните восстановление в определённый момент времени из файлов бинарного журнала, используя mysqlbinlog и mysql для восстановления изменений, произошедших после создания резервной копии.

В некоторых случаях повреждения базы данных достаточно выполнить дамп, удалить и пересоздать одну или несколько повреждённых таблиц. Вы можете использовать оператор CHECK TABLE, чтобы проверить, повреждена ли таблица, хотя CHECK TABLE естественно, не может обнаружить все возможные виды повреждений.

В некоторых случаях, явные повреждения страниц базы данных на самом деле вызваны повреждением операционной системой своего кэша файлов, а данные на диске могут быть в порядке. Лучше всего сначала перезагрузить компьютер. Это может устранить ошибки, которые казались повреждением страниц базы данных. Если MySQL по-прежнему испытывает проблемы с запуском из-за InnoDB проблем согласованности, см. Раздел 17.20.3, «Принудительное восстановление InnoDB», чтобы узнать, как запустить экземпляр в режиме восстановления, что позволяет вам сделать дамп данных.

Для восстановления после неожиданного завершения работы сервера MySQL необходимо только перезапустить сервер MySQL. InnoDB автоматически проверяет журналы и выполняет прокрутку базы данных до текущего состояния. InnoDB автоматически откатывает несохранённые транзакции, существовавшие в момент сбоя.

InnoDB состоит из нескольких этапов:

Шаги, следующие за применением журнала обратной записи, не зависят от журнала обратной записи (кроме записи записей) и выполняются параллельно с обычной обработкой. Из них только откат незавершенных транзакций является специальным для восстановления после сбоя. Объединение буфера вставок и очистка выполняются в ходе обычной обработки.

После применения журнала обратной записи InnoDB пытается принять подключения как можно раньше, чтобы сократить время простоя. В рамках восстановления после сбоя InnoDB откатывает транзакции, которые не были сохранены или находились в состоянии XA PREPARE, когда сервер завершил работу. Откат выполняется фоновым потоком, выполняемым параллельно с транзакциями новых подключений. До тех пор, пока операция отката не будет завершена, новые подключения могут столкнуться с конфликтами блокировок с восстановленными транзакциями.

В большинстве ситуаций, даже если сервер MySQL был неожиданно остановлен посреди активной работы, процесс восстановления происходит автоматически, и от DBA не требуется никаких действий. Если отказ оборудования или серьезная ошибка системы повредила данные InnoDB, MySQL может отказаться запускаться. В этом случае см. Раздел 17.20.3, «Принудительное восстановление InnoDB».

Для получения информации о бинарном журнале и InnoDB восстановлении после сбоя, см. Раздел 7.4.4, «Бинарный журнал».

Если во время восстановления InnoDB обнаруживает журналы обратной записи, записанные с момента последнего контрольного пункта, журналы обратной записи должны быть применены к соответствующим табличным пространствам. Процесс, определяющий соответствующие табличные пространства во время восстановления, называется обнаружением табличного пространства.

Обнаружение табличного пространства зависит от параметра innodb_directories, который определяет каталоги для сканирования при запуске в поисках файлов табличных пространств. Значение по умолчанию для innodb_directories — NULL, но каталоги, определённые параметрами innodb_data_home_dir, innodb_undo_directory и datadir всегда добавляются к аргументу innodb_directories при построении InnoDB списка каталогов для сканирования при запуске. Эти каталоги добавляются независимо от того, указан ли параметр innodb_directories явно. Файлы табличных пространств, определённые с абсолютным путём или находящиеся вне каталогов, добавленных к параметру innodb_directories, должны быть добавлены в параметр innodb_directories. Восстановление прекращается, если какой-либо файл табличного пространства, на который ссылается журнал обратной записи, не был обнаружен ранее.