Глава 5. Восстановление базы данных

Окончательная цель данных резервного копирования состоит в том, чтобы помочь восстановиться после проблемы базы данных или создать клон оригинальной базы данных в другом месте (как правило, управлять запросами или создать новую точную копию). Эта секция описывает процедуры, чтобы это сделать.

После серьезной проблемы базы данных вы, возможно, должны были бы выполнить восстановление при серьезной нехватке времени. Очень важно подтвердить заранее:

5.1. Выполнение операции восстановления

Команды mysqlbackup, чтобы выполнить восстановление, это copy-back-and-apply-log и copy-back (см. раздел 5.1.7). Обычно процесс восстановления требует, чтобы сервер базы данных был уже закрыт (или по крайней мере не воздействовал на каталог, в который вы вернули данные), за исключением частичного восстановления. Процесс копирует файлы данных, журналы и другие поддержанные файлы из резервного каталога назад к их исходным местоположениям и выполняет любую необходимую последующую обработку.

Пример 5.1. Восстановление базы данных

mysqlbackup --defaults-file=<my.cnf> -uroot \
            --backup-image=<image_name> \
            --backup-dir=<backupTmpDir> --datadir=<restoreDir> \
            copy-back-and-apply-log

Команда copy-back-and-apply-log достигает двух вещей:

См. раздел 4.2.4 для объяснения важных вариантов, используемых в восстановлении, в частности --defaults-file, --datadir, --backup-image и --backup-dir .

Восстановленные данные включают таблицу backup_history, где MySQL Enterprise Backup делает запись деталей каждой резервной копии. Это позволяет вам выполнять будущие возрастающие резервные копии, используя --incremental-base=history:last_backup.

Следующие подразделы описывают много различных сценариев для восстановления резервной копии.

5.1.1. Восстановление сжатой резервной копии

MySQL Enterprise Backup 8.0.21 и позже: опция --uncompress больше не необходима, восстанавливая сжатую резервную копию.

Восстановите сжатый образ резервной копии <image_name>, используя опцию --backup-dir, чтобы определить временный каталог, в который будут сохранены файлы статуса и метаданные резервных копий:

Пример 5.2. Восстановление сжатой резервной копии

mysqlbackup --defaults-file=<my.cnf> -uroot \
            --backup-image=<image_name> \
            --backup-dir=<backupTmpDir> --datadir=<restoreDir> \
            --uncompress copy-back-and-apply-log

Дополнительно: сделайте то же самое для сжатого резервного каталога <backupDir> в <restoreDir> на сервере, применив copy-back-and-apply-log:

Пример 5.3. Восстановление сжатой директивной резервной копии

mysqlbackup --defaults-file=<my.cnf> -uroot \
            --backup-dir=<backupDir> --datadir=<restoreDir> \
            --uncompress copy-back-and-apply-log

Чтобы восстановить сжатую и подготовленную директивную резервную копию, созданную командой backup-and-apply-log (поддерживается только для MySQL Enterprise Backup 4.0.1 и позже), используйте команду the copy-back и опцию --uncompress :

Пример 5.4. Восстановление сжатой и подготовленной директивной резервной копии

mysqlbackup --defaults-file=<my.cnf> -uroot \
            --backup-dir=<backupDir> --datadir=<restoreDir> \
            --uncompress copy-back

См. разделы 4.3.4 и 20.6.

5.1.2. Восстановление зашифрованного образа резервной копии

Восстановите зашифрованный образ резервной копии <image_name> в <restoreDir> на сервере с помощью copy-back-and-apply-log с использованием ключа шифрования, содержавшегося в файле <keyFile> :

Пример 5.5. Восстановление зашифрованного образа резервной копии

mysqlbackup --defaults-file=<my.cnf> --backup-image=<image_name> \
            --backup-dir=<backupTmpDir> --datadir=<restoreDir> \
            --decrypt --key-file=<keyFile> copy-back-and-apply-log

См. раздел 20.13.

5.1.3. Восстановление инкрементного резервного копирования

MySQL Enterprise Backup 8.0.21 и позже: опция --incremental больше не необходима, восстанавливая инкрементное резервное копирование.

Есть различные способы использовать возрастающие резервные копии, чтобы восстановить базу данных согласно различным сценариям. Предпочтительный метод состоит в том, чтобы сначала восстановить полное резервное копирование и сделать его актуальным ко времени, в которое полное резервное копирование было выполнено, используя copy-back-and-apply-log (см. пример 5.1), затем использовать copy-back-and-apply-log снова, чтобы восстановить образ инкрементного резервного копирования сверху полного резервного копирования, которое было просто восстановлено:

Пример 5.6. Восстановление образа инкрементного резервного копирования

mysqlbackup --defaults-file=<my.cnf> -uroot \
            --backup-image=<inc_image_name> \
            --backup-dir=<incBackupTmpDir> \
            --datadir=<restoreDir> --incremental \
            copy-back-and-apply-log

В этом примере образ инкрементного резервного копирования <inc_image_name> восстановлен в <restoreDir> на сервере (где полное резервное копирование, на основе которого был сделан образ инкрементного резервного копирования, было уже восстановлено). Опция --backup-dir используется, чтобы определить временный каталог, в который сохранены файлы статуса и метаданные резервных копий. Повторите шаг с другими образами инкрементного резервного копирования, которые вы имеете, пока данные не вернутся к желаемому моменту времени.

Дополнительно: восстановление каталога инкрементного резервного копирования

Возрастающие директивные резервные копии могут быть восстановлены в серии команд copy-back-and-apply-log, как иллюстрировано выше для однофайлового резервного копирования. Альтернативно в любое время после того, как инкрементное резервное копирование взято и прежде, чем данные будут восстановлены, можно сделать полное резервное копирование актуальным с инкрементным резервным копированием. Во-первых, примените к полному резервному копированию любые изменения, которые произошли в то время как, резервная копия делалась:

$ mysqlbackup --backup-dir=/full-backup/2010-12-08_17-14-11 apply-log
..many lines of output...
101208 17:15:10 mysqlbackup: Full backup prepared for recovery successfully!
101208 17:15:10 mysqlbackup: mysqlbackup completed OK!

Затем мы применяем изменения от инкрементного резервного копирования, используя apply-incremental-backup:

$ mysqlbackup --incremental-backup-dir=/incr-backup/2010-12-08_17-14-48 \
              --backup-dir=/full-backup/2010-12-08_17-14-11 \
              apply-incremental-backup
...many lines of output...
101208 17:15:12 mysqlbackup: mysqlbackup completed OK!

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

Восстановление журналов

Когда инкрементное резервное копирование восстанавливается, используя любую из команд copy-back-and-apply-log или apply-incremental-backup, двоичная регистрация (а также журнал реле в случае сервера точной копии), если включена в инкрементное резервное копирование, также вернется целевому серверу по умолчанию. Это поведение по умолчанию отвергнуто, когда (1) опция --skip-binlog (или --skip-relaylog для журнала реле) используется с командой восстановления или (2) если у полного резервного копирования, на основе которого было инкрементное резервное копирование или любого предшествующего инкрементного резервного копирования, которое было между полным резервным копированием и этим инкрементным резервным копированием, есть двоичная регистрация (или журнал реле), в обоих случаях MySQL Enterprise Backup 8.0.19 и позже переименует любую двоичную регистрацию (но не журнал реле) и их индексные файлы, которые были уже восстановлены на сервере, добавив расширение .old к их именам файлов).

Местоположение двоичной регистрации (или журнала реле) после инкрементного резервного копирования восстановлено по умолчанию как местоположение регистрации на поддержанном сервере, когда инкрементное резервное копирование было взято или как определено опцией --log-bin (или --relay-log) во время восстановления.

См. разделы 4.3.3 и 20.7.

5.1.4. Table-Level Recovery (TLR)

MySQL Enterprise Backup 8.0.20 и позже: Table-Level Recovery (TLR) позволяет отобранным таблицам (или схемам) быть восстановленными из резервной копии (будь это полное резервное копирование, частичная резервная копия или резервная копия, созданная, используя transportable tablespaces (TTS)) с опциями --include-tables и --exclude-tables. Особенность также известна как частичное восстановление. Вот некоторые общие требования для выполнения TLR:

Вот некоторые ограничения для TLR:

Следующая команда восстанавливает таблицу cats в схеме pets:

Пример 5.7. Восстановление отобранной таблицы из образа резервного копирования

mysqlbackup --socket=/tmp/restoreserver.sock --include-tables="^pets\.cats" \
            --backup-dir=/dba/backuptmp \
            --backup-image=/dba/my.mbi copy-back-and-apply-log

Следующая команда восстанавливает все таблицы в базе данных sales из резервной копии, но исключает таблицу hardware:

Пример 5.8. Восстановление отобранной таблицы в схеме из образа резервного копирования

mysqlbackup --socket=/tmp/restoreserver.sock --include-tables="^sales\." \
            --exclude-tables="^sales\.hardware$" \
            --backup-dir=/dba/backuptmp --backup-image=/dba/my.mbi \
            copy-back-and-apply-log

См. раздел 5.1.5 для получения дополнительной информации о частичном восстановлении с использованием резервных копий TTS.

MySQL Enterprise Backup 8.0.19 и ранее: частичное восстановленин поддерживается только для резервных копий TTS.

5.1.5. Восстановление резервных копий, созданных с опцией --use-tts

Требования для восстановления резервных копий, созданных с transportable tablespaces (TTS) (то есть, с опцией --use-tts) подобны перечисленным в разделе 5.1.4, с некоторыми различиями, отмеченными в секции. Следующее это некоторая дополнительная информация о частичном восстановлении с использованием резервных копий TTS.

Чтобы сделать копию и восстановить резервные копии, созданные с использованием TTS, дополнительные привилегии требуются для пользователя, через которого mysqlbackup соединяется с сервером, посмотрите раздел 4.1.2.

Когда восстановление резервного копирования выполняется с опцией --use-tts= with-minimum-locking, то каталог, определенный --backup-dir, помимо файлов статуса и метаданных также используется для извлечения временно всех таблиц в резервной копии и для выполнения apply-log, чтобы сделать данные актуальными прежде, чем вернуть их в каталог данных сервера.

Можно переименовать таблицу, восстанавливая ее из резервной копии TTS при помощи опции --rename (не поддерживается для резервных копий не-TTS):

Пример 5.9. Восстановление и переименование таблицы из резервной копии TTS

# Using fully qualified table names:
mysqlbackup --socket=/tmp/restoreserver.sock \
            --backup-dir=/BackupDirTemp \
            --backup-image=/home/user/dbadmin/backups/tts-backup.mbi \
            --include-tables="^sales\.cars" \
            --rename="sales.cars to sales.autos" copy-back-and-apply-log

# It works the same if database names are omitted in the argument for --rename:
mysqlbackup --socket=/tmp/restoreserver.sock \
            --backup-dir=/BackupDirTemp \
            --backup-image=/home/user/dbadmin/backups/tts-backup.mbi \
            --include-tables="^sales\.cars" \
            --rename="cars to autos" copy-back-and-apply-log

# A table can be restored into another database; the target database is created if it is not existing on the server:
mysqlbackup --socket=/tmp/restoreserver.sock \
            --backup-dir=/BackupDirTemp \
            --backup-image=/home/user/dbadmin/backups/tts-backup.mbi \
            --include-tables="^sales\.cars" \
            --rename="sales.cars to new_sales.autos" copy-back-and-apply-log

5.1.6. Восстановление внешних табличных пространств InnoDB к иным местоположениям

Когда резервная копия содержит внешние табличные пространства InnoDB, которые находились за пределами каталога данных поддержанного сервера, можно вернуть их к местоположениям, отличающимся от оригинальных, обновив их пути в файле tablespace_tracker в резервной копии, см. описание файла в таблице 1.1.

5.1.7. Дополнительно: подготовка и восстановление директивной резервной копии

Директивная резервная копия, точно так же как однофайловое резервное копирование, может быть подготовлена и восстановлена с использованием команды copy-back-and-apply-log как объяснено в начале раздела 5.1.

Пример 5.10. Восстановление резервного каталога, используя copy-back-and-apply-log

mysqlbackup --defaults-file=/usr/local/mysql/my.cnf \
            --backup-dir=/export/backups/full copy-back-and-apply-log

Однако, две альтернативы существуют для директивных резервных копий:

После того, как резервная копия была подготовлена, можно теперь восстановить ее, используя copy-back:

mysqlbackup --defaults-file=/usr/local/mysql/my.cnf \
            --backup-dir=/export/backups/full copy-back

5.2. Восстановление резервной копии с облачного хранилища на сервер MySQL

Восстановить образ резервной копии от облачного хранилища в datadir на сервере можно, применив варианты облачного хранилища, а также опцию --backup-dir, чтобы определить временный каталог, в который будут сохранены файлы статуса и метаданные резервных копий:

Пример 5.13. Восстановление однофайлового резервного копирования из хранилища объектов Oracle Cloud Infrastructure (OCI) на сервер MySQL

mysqlbackup --defaults-file=<my.cnf> \
            --backup-dir=/home/user/dbadmin/backuptmp \
            --datadir=<server_datadir> \
            --with-timestamp --backup-image=---cloud-service=OCI \
            --cloud-par-url=<backup_PAR_URL> \
            copy-back-and-apply-log

Пример 5.14. Восстановление инкрементного резервного копирования из Oracle Cloud Infrastructure (OCI) на сервер MySQL

mysqlbackup --defaults-file=<my.cnf> \
            --backup-dir=/home/user/dbadmin/backuptmp \
            --datadir=<server_datadir> \
            --with-timestamp --backup-image=---cloud-service=OCI \
            --cloud-par-url=<incremental-backup_PAR_URL> \
            --incremental copy-back-and-apply-log

Пример 5.15. Восстановление однофайлового резервного копирования из OpenStack Object Storage на MySQL Server

mysqlbackup --defaults-file=<my.cnf> \
            --cloud-service=openstack--cloud-container=<swift container> \
            --cloud-user-id=<keystone user> \
            --cloud-password=<keystone password> \
            --cloud-region=<keystone region> \
            --cloud-tenant=<keystone tenant> \
            --cloud-identity-url=<keystone url> \
            --cloud-object=image_800.mbi \
            --backup-dir=/home/user/dba/swiftbackuptmpdir \
            --datadir=/home/user/dba/datadir --backup-image=- \
            copy-back-and-apply-log

Пример 5.16. Восстановление однофайлового резервного копирования из Amazon S3 на MySQL Server

mysqlbackup --defaults-file=<my.cnf> \
            --cloud-service=s3 --cloud-aws-region=<aws region> \
            --cloud-access-key-id=<aws access key id> \
            --cloud-secret-access-key=<aws secret access key> \
            --cloud-bucket=<s3 bucket name> \
            --cloud-object-key=<aws object key> \
            --backup-dir=/home/user/dba/s3backuptmpdir --with-timestamp \
            --datadir=/home/user/dba/datadir --backup-image=- \
            copy-back-and-apply-log

Пример 5.17. Восстановление однофайлового резервного копирования из GCP Storage Service на MySQL Server

mysqlbackup --defaults-file=<my.cnf> \
            --cloud-service=GCP \
            --cloud-bucket=<bucket name> \
            --cloud-object=<object name> \
            --cloud-access-key=<access name> \
            --cloud-secret-key=<secret key> \
            --backup-dir=/home/user/dba/backuptmpdir --with-timestamp \
            --datadir=/home/user/dba/datadir \
            --backup-image=- copy-back-and-apply-log

5.3. Восстановление момента времени

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

Это шаги для восстановления момента времени:

  1. Восстановите ряд резервных копий к серверу, за исключением последнего инкрементного резервного копирования в ряду (которое покрывает предназначенный момент времени для восстановления). По окончании отметьте двоичное положение регистрации, к которому вы вернули сервер. Информация доступна в файле backup_variables.txt в восстановленном каталоге данных сервера: ищите значение binlog_position, например:

    binlog_position=binlog.000012:426
    

    Это означает, что после восстановления резервного ряда сервер будет в положении 426 регистрации, найденном в двоичном файле журнала binlog.000012. Вам будет нужна эта информация позже.

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

  2. Извлеките двоичную регистрацию из последнего инкрементного резервного копирования в резервном ряду (то есть, резервной копии, которая касается предназначенного момента времени для восстановления). Вы делаете это, распаковывая образ инкрементного резервного копирования в резервный каталог, используя image-to-backup-dir:

    mysqlbackup --backup-dir=incr-backup-dir2 \
                --backup-image=incremental_image2.bi image-to-backup-dir
    

    Затем войдите в получающийся резервный каталог (incr-backup-dir2 в этом примере) и в соответствии с каталогом данных внутри найдите файл двоичного журнала (binlog.000012 в этом примере):

    incr-backup-dir2$ ls datadir
    binlog.000012 ibbackup_logfilemysql petsundo_002
    ...
    
  3. Накатите базу данных к ее состоянию в предназначенном моменте времени для восстановления, определенного как tR в этом примере, используя файл журнала, извлеченный на последнем шаге. Затем используя mysqlbinlog накатите к серверу действия SQL, зарегистрированные в файле журнала с позиции, на которой восстановлен сервер на шаге 1 (в нашем примере 426) полностью ко времени tR. Определите ряд событий двоичной регистрации, чтобы переиграть с использованием опций --start-position и --stop-position (которые указывают на соответствующее положение двоичной регистрации для tR) и перенаправьте вывод клиенту mysql:

    mysqlbinlog --start-position="binary-log-position-at-the-end-of-backup-restores" \
                --stop-position="binary-log-position-corresponding-to-tR" \
                binary-log-filename \
                | mysql -uadmin -p
    

    Можно также свалить весь вывод mysqlbinlog к единственному файлу сначала, а затем перенаправить файл mysql.

    Для большего количества объяснений при использовании двоичной регистрации для восстановления момента времени посмотрите Point-in-Time (Incremental) Recovery.

  4. Проверьте, что сервер вернулся к желаемому моменту времени.

5.4. Восстановление резервной копии с модернизацией базы данных

Можно столкнуться с техническими проблемами во время модернизации сервера и это вне функций MySQL Enterprise Backup как резервного инструмента, чтобы гарантировать успешную модернизацию сервера. Пользователям, заинтересованным темой, рекомендуется проконсультироваться с серверным руководством MySQL, особенно с разделами Upgrading MySQL и Downgrading MySQL и обратить особое внимание на требования и ограничения, обсужденные там.

Можно облегчить модернизацию сервера при помощи MySQL Enterprise Backup, чтобы сделать резервную копию данных из исходного сервера и восстановить их на целевом сервере, а затем после некоторых приготовлений запустить иную версию MySQL Server на восстановленных данных. Вот много вещей, на которые пользователи должны обратить внимание, восстанавливая резервную копию с модернизацией базы данных: