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

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

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

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

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

InnoDB: Log scan progressed past the checkpoint lsn 369163704
InnoDB: Doing recovery: scanned up to log sequence number 374340608
InnoDB: Doing recovery: scanned up to log sequence number 379583488
InnoDB: Doing recovery: scanned up to log sequence number 384826368
InnoDB: Doing recovery: scanned up to log sequence number 390069248
InnoDB: Doing recovery: scanned up to log sequence number 395312128
InnoDB: Doing recovery: scanned up to log sequence number 400555008
InnoDB: Doing recovery: scanned up to log sequence number 405797888
InnoDB: Doing recovery: scanned up to log sequence number 411040768
InnoDB: Doing recovery: scanned up to log sequence number 414724794
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: 1 transaction(s) which must be rolled back or cleaned up in
total 518425 row operations to undo
InnoDB: Trx id counter is 1792
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37
38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59
60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81
82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
...
InnoDB: Starting in background the rollback of uncommitted transactions
InnoDB: Rolling back trx with id 1511, 518425 rows to undo
...
InnoDB: Waiting for purge to start
InnoDB: 5.7.18 started; log sequence number 414724794
...
./mysqld: ready for connections.

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

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

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

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

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

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

Обнаружение табличных пространств выполняется путём сканирования записей журнала пересчёта с последней контрольной точки до конца журнала для поиска записей, которые записываются при изменении страницы табличного пространства. Запись содержит идентификатор табличного пространства и имя файла.

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

Записи записываются для всех типов постоянных табличных пространств, включая табличные пространства с файлом на таблицу, общие табличные пространства, системное табличное пространство и табличные пространства журнала отмены.

Обнаружение на основе журнала пересчёта имеет следующие характеристики:

Обнаружение на основе журнала пересчёта, введённое в MySQL 5.7, заменяет сканирование каталогов, которое использовалось в более ранних версиях MySQL для построения карты «идентификатор пространства – имя файла табличного пространства», которая требовалась для применения записей журнала пересчёта.