Создание резервной копии mysql при помощи утилиты xtrabackup / хабр

Настройка БД для бекапа

Создаем пользователя бд и даем ему права на все базы данных.

> CREATE USER 'bkpuser'@'localhost' IDENTIFIED BY '123456789';
> GRANT SELECT, PROCESS, RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'bkpuser'@'localhost';
> FLUSH PRIVILEGES;

Создаем папку куда будем складывать бэкапы.

$ mkdir /var/backups

Ключи

—port	порт для подключения к БД
—socket	сокет для подключения к БД
—host	хост для подключения к БД
—defaults-file	с этим ключом можно указать конфигурационный файл для innobackupex, при использовании обязательно должен стоять первым в списке параметров
—use-memory	позволяет указать кол-во оперативной памяти для осуществления операции (по умолчанию равно 100М), может значительно ускорить восстановление из резервной копии
—no-lock	не блокировать таблицы в момент создания резервной копии
—no-timestamp	ключ указывает, что не нужно создавать поддиректорию с временной меткой
—rsync	используется для копирования файлов БД отличных от типа InnoDB (например, таблиц MyISAM), копирует часть до блокировки, копирует часть внутри блокировки. Не работает в потоковом режиме!
—open-files-limit	установить лимит на количество открытых файлов
—databases=LIST	база данных
—parallel	использовать параллельное копирование (имеет смысл только с параметром innodb_file_per_table)
—compress	компрессия данных
—decompress	декомпрессия данных (необходимо установить qpress)

Preparing Partial Backups¶

For preparing partial backups, the procedure is analogous to restoring individual tables : apply the logs and use the option:

$ innobackupex --apply-log --export /path/to/partial/backup

You may see warnings in the output about tables that don’t exist. This is because InnoDB -based engines stores its data dictionary inside the tablespace files besides the files. innobackupex will use xtrabackup to remove the missing tables (those who weren’t selected in the partial backup) from the data dictionary in order to avoid future warnings or errors:

111225  5406  InnoDB Error table 'mydatabase/mytablenotincludedinpartialb'
InnoDB in InnoDB data dictionary has tablespace id 6,
InnoDB but tablespace with that id or name does not exist. It will be removed from data dictionary.

You should also see the notification of the creation of a file needed for importing ( file) for each table included in the partial backup:

xtrabackup: export option is specified.
xtrabackup: export metadata of table 'employees/departments' to file `.//departments.exp` (2 indexes)
xtrabackup:     name=PRIMARY, id.low=80, page=3
xtrabackup:     name=dept_name, id.low=81, page=4

Note that you can use the option with to an already-prepared backup in order to create the files.

Finally, check for the confirmation message in the output:

Принцип работы

Утилита основана на механизме crash-recovery(аварийное восстановление), который предоставляет движок InnoDB. Во время копирования возможны транзакции, связывающие уже скопированные таблицы с теми, что ещё не были скопированы, как результат, может возникнуть внутренняя противоречивость данных. Во избежание этого применяется механизм восстановления, чтобы сделать данные вновь согласованными и пригодными для использования.

Для возможности восстановления InnoDB ведет так называемый redo log — транзакционный журнал. Он содержит запись каждого изменения в БД. При старте InnoDB проверяет данные и транзакционный журнал, после чего применяет законченные и откатывает незаконченные транзакции.

Идея реализации

Перед началом работы ExtraBackup запоминает позицию в последовательности логов (log sequence number (LSN)) после чего начинает копирование. Процесс копирования может занять некоторое время, в течение которого данные базы могут изменяться. В то же время ExtraBackup запускает фоновый процесс, который отслеживает транзакционный журнал и копирует изменения оттуда. Журнал должен отслеживаться постоянно, поскольку запись в него ведется циклически, а значит события могут перезаписаться из-за переполнения спустя некоторое время.

Подготовка бэкапа

Затем, в фазе подготовки бэкапа (prepare phase), применяется механизм восстановления crash-recovery, используя данные из скопированного журнала транзакций. В результате мы получаем актуальную на момент окончания копирования базу данных.

Примечателен вариант, когда база данных состоит как из InnoDB/XtraDB, так и MyISAM таблиц. Первые не прекращают свое функционирование в процессе копирования, тогда как вторые должны быть заблокированы. Возникает риск несогласованности копируемых таблиц базы. В этом случае процесс бэкапа происходит следующим образом: запускается копирование InnoDB/XtraDB таблиц, затем, в момент его окончания, происходит блокировка MyISAM таблиц с последующим копированием. По завершению этого этапа осуществляется подготовка скопированных InnoDB/XtraDB. Таким образом достигается согласованность блокируемых и неблокируемых таблиц.

STEP 2: Copy backed up data to TheSlave¶

Use rsync or scp to copy the data from Master to Slave. If you’re syncing the data directly to slave’s data directory it’s advised to stop the mysqld there.

TheMaster$ rsync -avpP -e ssh /path/to/backupdir TheSlave:/path/to/mysql/

After data has been copied you can back up the original or previously installed MySQL (NOTE: Make sure mysqld is shut down before you move the contents of its datadir, or move the snapshot into its datadir.):

TheSlave$ mv /path/to/mysql/datadir /path/to/mysql/datadir_bak

and move the snapshot from in its place:

TheSlave$ xtrabackup --move-back --target-dir=/path/to/mysql/backupdir

After you copy data over, make sure MySQL has proper permissions to access them.

TheSlave$ chown mysql:mysql /path/to/mysql/datadir

Проблема

У mysql_dump есть три основных проблемы — скорость, неконсистентность и блокировки. Все три проблемы проистекают из его архитектуры, так что вылечить их невозможно. Чтобы понять проблемы, опишу алгоритм работы mysql_dump:

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

Самая серьезная проблема, которая лежит на поверхности — блокировки. В момент, когда mysql_dump блокирует таблицу — записать в нее что-либо становится невозможно. В лучшем случае изменения в таблице будут накапливаться (если приложение умеет копить изменения и работать с базой асинхронно, как gorm). В худшем случае приложение упадет с ошибкой записи, а пользователь получит фигу в виде ошибки 500. Проблема консистентности лежит глубже, а потому она много опаснее, так как сходу эти грабли неочевидны, а по лбу бьют больно. Рассмотрим пример. У нас есть база, в которой лежит 3 таблицы: “affilates”, “logs” и “organisations”. Таблица logs очень большая. Таблицы affilates и organisations связаны через внешний ключ. Приложение вставляет запись в “affilates”, а затем — пачку записей в “organisations” с ключом, указывающим на запись в “affilates”. По логике работы mysql_dump, первой будет блокирована и сдамплена affilates. Записи в organisations можно вставлять только для уже существующих affilates, целосность данных не нарушается. После того, как affilates закончится и разблокируется, будет заблокирована logs. Как я уже писал, по условиям задачи она у нас большая и копируется, скажем, час (вполне реальный срок для большой таблицы). При этом никто не мешает создать запись в affilates, а потом из organisations сослаться на эту новую запись. Так, как упаковка affilates уже завершена — в дамп новая запись не попадет. После того, как мы упакуем organisations — в organisations образуются записи, ссылающиеся на не существовавшие в момент дампа ключи. И восстановить такой дамп без определенных магических движений будет невозможно. Ну и в качестве бонуса — мы потеряем данные, которые были созданы в процессе дампа, то есть целосность дампа будет на момент начала операции, а не ее окончания. Чтобы бороться со всеми этими проблемами и был придуман xtrabackup.

xtrabackup

Версия Xtrabackup 2.2 ранее включает 4 исполняемых файла: innobackupex: сценарий Perl xtrabackup: скомпилированный двоичный код C / C ++ xbcrypt: шифрование и дешифрование xbstream: формат файла потока, поддерживающий одновременную запись.
xtrabackup используется для резервного копирования таблиц InnoDB. Таблицы, не относящиеся к InnoDB, не могут быть скопированы. Нет взаимодействия с сервером MySQL.
Сценарий innobackupex используется для резервного копирования таблиц, отличных от InnoDB. В то же время он вызывает команду xtrabackup для резервного копирования таблиц InnoDB. Он также взаимодействует с сервером MySQL, отправляя команды, такие как добавление глобальной блокировки чтения (FTWRL), получение местоположения (SHOW SLAVE STATUS) и т. Д. То есть innobackupex реализуется слоем инкапсуляции поверх xtrabackup.
Хотя таблицы MyISAM в настоящее время обычно не используются, но системные таблицы в библиотеке MySQL — это MyISAM, поэтому резервное копирование в основном выполняется с помощью команды innobackupex

Полный бэкап Mysql сервера

Итак, база данных у нас работает, утилиту для бэкапа мы установили. Давайте теперь сделаем полный backup всех баз данных нашего сервера mysql.

# xtrabackup --backup --user=root --password='R(zDXcVUmI[zwx%aNBTN' --target-dir=/root/backupdb/full

backup	инициируем процедуру бэкапа
user=root	пользователь mysql
password=’R(zDXcVUmI[zwx%aNBTN’	пароль пользователя, взятый в одинарные кавычки
target-dir=/root/backupdb/full	директория для создания полного бэкапа mysql

В дальнейших примерах я не буду указывать пользователя и пароль, чтобы упростить команды. Эти данные я указал в файле ~/.my.cnf.

user=root
password='R(zDXcVUmI[zwx%aNBTN'

Мы сделали полный архив всего mysql сервера. В таком виде данные не консистентны, так как они могли меняться во время архивации. Если восстановить их как есть, сервер mysql не запустится. Будет ругаться на поврежденные данные. Чтобы восстановить целостность данных, необходимо выполнить еще одну команду.

# xtrabackup --prepare --target-dir=/root/backupdb/full

После этого бэкап будет полностью работоспособен и готов к восстановлению. Я обычно выполняю эту команду сразу же после бэкапа, но это не всегда возможно. К примеру, если вы захотите его сразу же сжать.

# xtrabackup --backup --compress --target-dir=/root/backupdb/full

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

# xtrabackup --decompress --target-dir=/root/backupdb/full

Для того, чтобы команда decompress отработала без ошибки:

sh: qpress: command not found
cat: write error: Broken pipe
Error: decrypt and decompress thread 0 failed.

Необходимо установить пакет qpress.

# yum install qpress

Он есть в репозитории percona. После этого распаковка пройдет штатно.

Лично я не вижу большого смысла использовать ключи compress и decompress. Можно сделать полный бэкап, подготовить его, а потом сжать тем же gzip.

# tar -czvf /root/backupdb/full.tar.gz -C /root/backupdb full

На выходе получите тот же архив, только сжат лучше и нет необходимости ставить дополнительный софт. Gzip и tar обычно есть во всех дистрибутивах. К тому же архив в виде единого файла проще и быстрее передать на сервер бэкапов и там хранить.

В завершении раздела про полный backup, предлагаю простенький скрипт для автоматизации процесса через cron — mysql-full-backup.sh.

#!/bin/bash

DATA=`date +%Y-%m-%d`

mkdir -p /root/backupdb/$DATA
xtrabackup --backup --target-dir=/root/backupdb/$DATA/full
xtrabackup --prepare --target-dir=/root/backupdb/$DATA/full
tar -czvf /root/backupdb/$DATA/full.tar.gz -C /root/backupdb/$DATA full
rm -rf /root/backupdb/$DATA/full

При выполнении этого скрипта раз в день, вы будете иметь отдельные папки с именем в виде даты, а внутри полный бэкап. Дальше мы в эти же папки будем класть инкрементные бэкапы. Но обо всем по порядку.

Примерение

Простой вариант — резервная копия всего сервера целиком:

Восстановление выглядит еще проще. Нужно просто остановить процесс mysql и положить файлы в datadir (обычно это /var/lib/mysql/), а затем — запустить mysql обратно. Перед запуском — обязательно сменить права доступа на файлы, чтобы файлами владел владелец процесса mysql:

Усложненный вариант — создаем mysql slave от имеющегося мастера:

innobackupex создает специальный файл с информацией о текущем бинлоге и позиции в этом бинлоге. Эта информация необходима для подключения slave — чтобы slave мог знать, с какого точно момента в прошлом была сделана эта копия базы (и начал синхронизацию именно с нужного момента). Файл называется . Содержимое у него выглядит примерно вот так:

Подключим slave-сервер к master-серверу. Для этого остановим mysql и подложим в datadir файлы, которые мы скопировали с master:

Теперь подключим slave к master. Для этого в консоли mysql:

сложный вариант — переносим отдельную таблицу

Искушающе простой способ (остановить mysql, подсунуть файлы с таблицей и запустить обратно) — не сработает, техника немного сложнее. Чтобы восстановить таблицу, нужно подготовить таблицу внутри резеврной копии к экспорту:

Теперь нужно создать таблицу с именем экспортируемой таблицы

Структура и содержимое не важны, важно только имя таблицы (имя базы тоже можно не учитывать):. Кстати, если при вводе второй таблицы выскочит ошибка , то нужно включить в my.cnf настройку

Кстати, если при вводе второй таблицы выскочит ошибка , то нужно включить в my.cnf настройку .

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

После этого мы получим новую таблицу из бэкапа.

Изменения в новой версии Xtrabackup

После обновления версии xtrabackup до 2.4 произошли серьезные изменения по сравнению с предыдущей версией 2.1: все функции innobackupex интегрированы в xtrabackup, есть только одна двоичная программа, и по причинам совместимости innobackupex используется в качестве мягкой ссылки xtrabackup, то есть xtrabackup теперь поддерживает не-Innodb Резервное копирование таблицы, а Innobackupex будет удалено в следующей версии, рекомендуется заменить innobackupex на xtrabackup
установка xtrabackup: yum install percona-xtrabackup в исходном коде EPEL Загрузите и установите последнюю версию:https://www.percona.com/downloads/XtraBackup/LATEST/

Принцип работы GTID

GTID появился с MySQL 5.6 и представляет собой уникальный 128-битный глобальный идентификационный номер (SERVER_UUID), который увеличивается с каждой новой транзакцией. Выглядит GTID примерно так:

Классическая репликация MySQL без GTID использует позицию в бинарном логе. Но благодаря GTID больше не нужно разбираться с вычислениями позиции бинлога. Из преимуществ GTID является согласованность данных, т.е. на сервере (как на мастере, так и на слейве) будет подтверждена одна и только одна транзакция с одним GTID, а любые другие транзакции, имеющие такой же UUID, будут проигнорированы. Подробную теорию можно дополнительно изучить на официальном сайте MySQL.

Использование GTID – это хорошая практика, т.к. данные между мастером и слейвом более консистентные с GTID, настройка ещё быстрее и проще.

В MySQL при использовании GTID есть две глобальные переменные, о которых необходимо знать:

gtid_executed – содержит набор всех транзакций из бинарного лога;
gtid_purged – содержит набор транзакций, которые были зафиксированы на сервере, но не содержащиеся в бинарном логе. gtid_purged является подмножеством gtid_executed.

Вышеописанные переменные получают свои значения при каждом запуске MySQL. На мастер-сервере это выглядит так:

Preparing the Incremental Backups¶

The step for incremental backups is not the same
as for full backups. In full backups, two types of operations are performed to
make the database consistent: committed transactions are replayed from the log
file against the data files, and uncommitted transactions are rolled back. You
must skip the rollback of uncommitted transactions when preparing an
incremental backup, because transactions that were uncommitted at the time of
your backup may be in progress, and it’s likely that they will be committed in
the next incremental backup. You should use the
option to prevent the rollback phase.

Warning

If you do not use the option to
prevent the rollback phase, then your incremental backups will be useless.
After transactions have been rolled back, further incremental backups cannot
be applied.

Beginning with the full backup you created, you can prepare it, and then apply
the incremental differences to it. Recall that you have the following backups:

/data/backups/base
/data/backups/inc1
/data/backups/inc2

To prepare the base backup, you need to run as
usual, but prevent the rollback phase:

$ xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base

The output should end with text similar to the following:

InnoDB: Shutdown completed; log sequence number 1626007
161011 12:41:04 completed OK!

The log sequence number should match the of the base backup, which
you saw previously.

Note

This backup is actually safe to as-is
now, even though the rollback phase has been skipped. If you restore it and
start MySQL, InnoDB will detect that the rollback phase was not
performed, and it will do that in the background, as it usually does for a
crash recovery upon start. It will notify you that the database was not shut
down normally.

To apply the first incremental backup to the full backup, run the following
command:

$ xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base \
--incremental-dir=/data/backups/inc1

This applies the delta files to the files in , which
rolls them forward in time to the time of the incremental backup. It then
applies the redo log as usual to the result. The final data is in
, not in the incremental directory. You should see
an output similar to:

incremental backup from 1626007 is enabled.
xtrabackup: cd to /data/backups/base
xtrabackup: This target seems to be already prepared with --apply-log-only.
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(4124244)
...
xtrabackup: page size for /tmp/backups/inc1/ibdata1.delta is 16384 bytes
Applying /tmp/backups/inc1/ibdata1.delta to ./ibdata1...
...
161011 12:45:56 completed OK!

Again, the should match what you saw from your earlier inspection of the
first incremental backup. If you restore the files from
, you should see the state of the database as of the
first incremental backup.

Warning

PXB does not support using the same incremental backup directory to
prepare two copies of backup. Do not run with the same incremental backup directory (the value of
–incremental-dir) more than once.

Preparing the second incremental backup is a similar process: apply the deltas
to the (modified) base backup, and you will roll its data forward in time to
the point of the second incremental backup:

$ xtrabackup --prepare --target-dir=/data/backups/base \
--incremental-dir=/data/backups/inc2

Note

should be used when merging all
incrementals except the last one. That’s why the previous line doesn’t contain
the option. Even if the
was used on the last step, backup would
still be consistent but in that case server would perform the rollback phase.

Once prepared, incremental backups are the same as the and they can be in the same
way.

Полная горячая резервная копия БД

Подготовив систему, можно приступать к созданию полного горячего бэкапа базы данных MySQL с помощью XtraBackup.

В системе CentOS 7 файлы данных MySQL хранятся в каталоге /var/lib/mysql (который также называется datadir). По умолчанию доступ к этому каталогу заблокирован для всех, кроме пользователя mysql. XtraBackup требует доступа к этому каталогу для создания бэкапа, потому нужно передать созданному для XtraBackup пользователю соответствующие права.

Эти команды открывают группе mysql доступ ко всем каталогам datadir.

Примечание: Если вы добавили пользователя в группу mysql в той же сессии, вам нужно будет войти повторно, чтобы права доступа вступили в силу.

Создание резервной копии

Итак, теперь можно запустить резервное копирование. Чтобы скопировать работающую БД MySQL, используйте утилиту innobackupex.

Примечание: Замените условные данные в команде данными своего пользователя MySQL.

Это создаст резервную копию БД в /data/backups/new_backup:

Также можно пропустить флаг –no-timestamp, чтобы программа XtraBackup создала каталог резервного копирования с текущей временной меткой:

Это создаст резервную копию БД в автоматически сгенерированном подкаталоге:

С флагом или без него, программа должна вернуть «innobackupex: completed OK!» в последней строке результата.

Резервную копию базы данных нужно подготовить, прежде чем её можно будет использовать.

Подготовка БД

Последнее, что нужно сделать, – это подготовить горячую копию БД к использованию; для этого нужно воспроизвести лог транзакций и внести все несовершённые транзакции в резервную копию. Подготовка резервной копии позволяет согласовать и уточнить данные.

Чтобы подготовить полученную копию (/data/backups/new_backup), нужно запустить команду:

В случае успешного выполнения команды программа вернёт «innobackupex: completed OK!».

Теперь резервную копию можно восстановить. Кроме того, если у вас есть система резервного копирования файлов (например, Bacula), эта резервная копия базы данных должна быть добавлена в backup selection.

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

Для восстановления резервной копии XtraBackup нужно остановить БД и очистить datadir.

Остановите сервис MySQL:

Переместите или удалите содержимое каталога данных (/var/lib/mysql). В данном примере данные будут просто временно перемещены:

Теперь можно восстановить резервную копию:

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

Теперь можно запустить MySQL:

Резервная копия БД полностью восстановлена.

Схемы применения

Изначальное копирование базы данных

Для того чтобы сделать полную резервную копию, используйте скрипт с параметрами, необходимыми для соединения с сервером и только один аргумент; путь к директории, где будет храниться резервная копия:

$ innobackupex --user=DBUSER --password=DBUSERPASS /path/to/BACKUP-DIR/

Проверьте последнюю линию вывода для сообщения подтверждения:

$ innobackupex: Backup created in directory '/path/to/BACKUP-DIR/2017-04-20_00-00-09'
$ innobackupex: MySQL binlog position: filename 'mysql-bin.000003', position 1946 111225 00:00:53 innobackupex: completed OK!

Например, 60GB база данных копируется за 19 минут без прерывания службы.
После компрессии (tar -cz), архив занимает 14GB дискового пространства. Также, следует заметить, что сжатый архив XtraBackup занимает в два раза меньше места по сравнению со сжатой резервной копией, созданной инструментом mysqldump.

Копия базы данных, созданная при помощи XtraBackup может применяться для последующих инкрементных резервных копий, или может быть подготовлена как полностью рабочая директория MySQL, достаточная для того, чтобы запустить экземпляр MySQL (для доступа к скопированной информации или для того, чтобы сделать изначальную базу данных для репликации).

Инкрементная копия

Проведение инкрементного резервного копирования:

$ innobackupex --incremental /data/backups --incremental-basedir=BASEDIR

Где BASEDIR является директорией, содержащей полную или инкрементную резервную копию и «/data/backups» это директория для хранения новосозданной инкрементной резервной копии.
Инкрементные резервные копии содержат все изменения, сделанные в базе данных с последней даты резервной копии до текущего времени.

Применение инкрементных копий к изначальной резервной копии (резервная копия в будущее)

Созданные инкрементные копии могут применяться для продвижения вперёд во времени от изначальной резервной копии. В качестве примера, изначальная копия была создана 10 дней назад, применение инкрементных копий, сделанных в последующие 4 дня, доведут базу данных до состояния 6 дней назад.

Для того чтобы применить инкрементные резервные копии к изначальным резервным копиям, запустите innobackupex со следующими параметрами:

$ innobackupex --apply-log BASE-DIR --incremental-dir=INCREMENTAL-DIR-1

Где «INCREMENTAL-DIR-1» является директорией, содержащей инкрементную копию с изменениями после копии, содержащейся в “BASE-DIR”.

Подготовка копии базы данных для работы в рабочем окружении

В случае восстановления базы данных в качестве замены рабочей базы данных или в качестве дополнительной копии MySQL, резервная копия должна подвергнуться подготовке:

$ innobackupex innobackupex --apply-log BASE-DIR

Эта команда применяется для чистки директории резервной копии, применению законченных и откату незаконченных транзакций, и подготовка BASE-DIR в качестве базовой директории MySQL.
Сервер MySQL может быть запущен на этой директории и отвечать на запросы.

Создание копии базы данных для изначальной репликации

Репликация базы данных требует включённого binlog логирования у исходной базы данных. В этом случае, резервная копия содержит информацию о позиции binlog и может применяться для репликации мастера, которым является источник копии. Файл xtrabackup_binlog_po_innodb внутри директории резервной копии содержит информацию о позиции binlog и является источником значений в команде «CHANGE MASTER TO», которая применяется для настройки репликации с мастером.

Например, если файл xtrabackup_binlog_po_innodb содержит «./mysql-bin.000037 941022681», тогда команда должна быть:

$ CHANGE MASTER TO master_log_file=”mysql-bin.000037”,master_log_pos=941022681;

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

Пример: новая версия Xtrabackup полная, инкрементное резервное копирование и восстановление

1 Процесс резервного копирования

1) Полная резервная копия: xtrabackup —backup —target-dir = / backups / base 2) Измените данные в первый раз. 3) Первая инкрементная резервная копия xtrabackup —backup —target-dir=/backups/inc1 —incremental-basedir=/backups/base 4) Измените данные во второй раз. 5) Вторая инкрементная резервная копия xtrabackup —backup —target-dir=/backups/inc2 —incremental-basedir=/backups/inc1 6) scp -r / backups / * целевой хост: / backups /

В процессе резервного копирования создаются три каталога резервных копий. /backups/{base，inc1，inc2}

2 Процесс восстановления

1) Подготовьтесь к завершению резервного копирования заранее, этот параметр –apply-log-only предотвращает откат незавершенных транзакций

xtrabackup —prepare —apply-log-only —target-dir=/backups/base 2) Объедините первую инкрементную резервную копию с полной резервной копией, xtrabackup —prepare —apply-log-only —target-dir=/backups/base —incremental-dir=/backups/inc1 3) Объедините вторую инкрементную резервную копию с полной резервной копией: при последнем восстановлении не нужно добавлять параметр –apply-log-only xtrabackup —prepare —target-dir=/backups/base —incremental-dir=/backups/inc2 4) Скопируйте в каталог базы данных, обратите внимание, что каталог базы данных должен быть пустым и служба MySQL не может быть запущена. xtrabackup —copy-back —target-dir=/data/backups/base 5) Восстановить атрибуты: chown -R mysql: mysql / var / lib / mysql 6) Запустите службу: systemctl start mariadb

Preparing a backup¶

After making a backup with the option, you need need to
prepare it in order to restore it. Data files are not point-in-time consistent
until they are prepared, because they were copied at different times as the
program ran, and they might have been changed while this was happening.

If you try to start InnoDB with these data files, it will detect corruption and
stop working to avoid running on damaged data. The step
makes the files perfectly consistent at a single instant in time, so you can run
InnoDB on them.

You can run the prepare operation on any machine; it does not need to be on the
originating server or the server to which you intend to restore. You can copy
the backup to a utility server and prepare it there.

Note that Percona XtraBackup 8.0 can only prepare backups of MySQL
8.0, Percona Server for MySQL 8.0, and Percona XtraDB Cluster 8.0
databases. Releases prior to 8.0 are not supported.

During the prepare operation, xtrabackup boots up a kind of modified
embedded InnoDB (the libraries xtrabackup was linked against). The
modifications are necessary to disable InnoDB standard safety checks, such as
complaining about the log file not being the right size. This warning is not
appropriate for working with backups. These modifications are only for the
xtrabackup binary; you do not need a modified InnoDB to use xtrabackup for
your backups.

The prepare step uses this “embedded InnoDB” to perform crash recovery on the
copied data files, using the copied log file. The step is very
simple to use: you simply run xtrabackup with the option
and tell it which directory to prepare, for example, to prepare the previously
taken backup run:

$ xtrabackup --prepare --target-dir=/data/backups/

When this finishes, you should see an with a message such
as the following, where again the value of will depend on your
system:

InnoDB: Shutdown completed; log sequence number 137345046
160906 11:21:01 completed OK!

All following prepares will not change the already prepared data files, you’ll
see that output says:

xtrabackup: This target seems to be already prepared.
xtrabackup: notice: xtrabackup_logfile was already used to '--prepare'.

It is not recommended to interrupt xtrabackup process while preparing backup
because it may cause data files corruption and backup will become unusable.
Backup validity is not guaranteed if prepare process was interrupted.