Настройка инкрементальных резервных копий MySQL с помощью Percona XtraBackup

Освойте искусство высокоэффективного резервного копирования MySQL, используя инкрементальные снимки Percona XtraBackup (PXB). Это всеобъемлющее руководство подробно описывает ключевые шаги для настройки, выполнения и восстановления последовательных инкрементальных резервных копий на основе отслеживания LSN. Узнайте, как выполнить первоначальную полную базовую резервную копию, правильно связать последующие инкременты с помощью `--incremental-basedir` и пройти многофазный процесс восстановления, обеспечивая минимальное время простоя и оптимальное управление хранилищем для больших баз данных.

42 просмотров

Настройка инкрементного резервного копирования MySQL с помощью Percona XtraBackup

Percona XtraBackup (PXB) является отраслевым стандартом для выполнения неблокирующего, "горячего" резервного копирования экземпляров MySQL, MariaDB и Percona Server. Хотя полные резервные копии необходимы, большие базы данных требуют эффективной стратегии для минимизации времени простоя и использования хранилища. Инкрементные резервные копии обеспечивают эту эффективность, захватывая только те изменения данных, которые произошли с момента последнего успешного резервного копирования.

В этом руководстве рассматривается, как использовать PXB для реализации надежной стратегии инкрементного резервного копирования. Мы рассмотрим основные концепции, необходимые команды для выполнения последовательных инкрементных снимков и многоэтапный процесс, необходимый для успешного восстановления.

Понимание механизма инкрементного резервного копирования Percona XtraBackup

PXB полагается на внутреннюю работу механизма хранения InnoDB, в частности, отслеживая изменения с помощью номера последовательности журнала (Log Sequence Number, LSN). Каждая страница InnoDB помечена LSN. Когда PXB выполняет инкрементное резервное копирование, он записывает только те страницы, LSN которых больше LSN, записанного во время предыдущего резервного копирования.

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

Ключевые файлы и концепции

  • LSN (Log Sequence Number): Маркер, используемый для определения начала и конца изменений.
  • xtrabackup_checkpoints: Файл, создаваемый при каждом резервном копировании, содержащий to_lsn (LSN, достигнутый к концу резервного копирования) и, для инкрементных резервных копий, from_lsn (начальный LSN).
  • --incremental-basedir: Важный флаг, используемый во время инкрементных запусков, указывающий PXB на каталог предыдущей резервной копии (который определяет начальный LSN).

Шаг 1: Выполнение полной базовой резервной копии

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

Сначала определим нашу структуру каталогов:

# Определяем базовый каталог для полной резервной копии
BASE_DIR="/data/backups/2023-10-01_FULL"

# Создаем каталог
mkdir -p $BASE_DIR

# Выполняем полное резервное копирование
xtrabackup --backup \n  --target-dir=$BASE_DIR \n  --user=root --password=secret_password \n  --datadir=/var/lib/mysql

# Проверяем LSN полной резервной копии
cat $BASE_DIR/xtrabackup_checkpoints | grep 'to_lsn'

Примечание: target-dir должен быть пустым или несуществующим при начале процесса резервного копирования. Всегда используйте учетные данные с соответствующими разрешениями (например, RELOAD, LOCK TABLES, PROCESS, SUPER).

Шаг 2: Создание первой инкрементной резервной копии

Для выполнения первой инкрементной резервной копии мы должны сослаться на каталог полной базовой резервной копии, используя флаг --incremental-basedir. PXB прочитает to_lsn из базовой резервной копии и скопирует только те страницы, которые изменились с этого момента.

# Определяем каталог для первой инкрементной резервной копии
INCREMENTAL_1_DIR="/data/backups/2023-10-02_INC1"

# Выполняем инкрементное резервное копирование, ссылаясь на полную базовую копию
xtrabackup --backup \n  --target-dir=$INCREMENTAL_1_DIR \n  --incremental-basedir=/data/backups/2023-10-01_FULL \n  --user=root --password=secret_password

Шаг 3: Объединение последующих инкрементных резервных копий в цепочку

Для любой последующей инкрементной резервной копии (INC2, INC3 и т. д.) --incremental-basedir должен указывать на непосредственно предшествующий каталог инкрементной резервной копии.

Если мы хотим создать INC2 на основе изменений с момента INC1:

# Определяем каталог для второй инкрементной резервной копии
INCREMENTAL_2_DIR="/data/backups/2023-10-03_INC2"

# Выполняем инкрементное резервное копирование, ссылаясь на предыдущую инкрементную (INC1)
xtrabackup --backup \n  --target-dir=$INCREMENTAL_2_DIR \n  --incremental-basedir=/data/backups/2023-10-02_INC1 \n  --user=root --password=secret_password

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

Восстановление: Применение инкрементных изменений

Восстановление набора инкрементных резервных копий — это многоэтапный процесс, включающий последовательное применение изменений к базовой резервной копии. В отличие от полной резервной копии, инкрементные резервные копии нельзя скопировать непосредственно в каталог данных.

Фаза восстановления 1: Подготовка базовой резервной копии

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

При подготовке базовой резервной копии PXB выполняет два важных действия:
1. Применяет зафиксированные транзакции (журнал повторов).
2. Откатывает незафиксированные транзакции.

Мы используем флаг --prepare, но, что критически важно, мы добавляем флаг --apply-log-only. Это предотвращает откат незафиксированных транзакций PXB, что необходимо, поскольку последующим инкрементным журналам требуются эти фрагменты транзакций для завершения восстановления.

# Определяем промежуточный каталог
RESTORE_TARGET="/data/restore_staging"

# Копируем файлы полной базовой резервной копии в промежуточную область
rsync -avr /data/backups/2023-10-01_FULL/ $RESTORE_TARGET

# Подготавливаем базовую резервную копию, сохраняя ее готовой для инкрементов
xtrabackup --prepare --target-dir=$RESTORE_TARGET --apply-log-only

# Ищем подтверждение: 'completed OK!'

Фаза восстановления 2: Последовательное применение инкрементных резервных копий

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

# Применяем инкрементную 1
xtrabackup --prepare --target-dir=$RESTORE_TARGET \n  --incremental-dir=/data/backups/2023-10-02_INC1 \n  --apply-log-only

# Применяем инкрементную 2
xtrabackup --prepare --target-dir=$RESTORE_TARGET \n  --incremental-dir=/data/backups/2023-10-03_INC2 \n  --apply-log-only

# ... продолжаем для всех необходимых инкрементов ...

Фаза восстановления 3: Завершение подготовки

После применения последнего желаемого инкрементного снимка выполните заключительный шаг подготовки без флага --apply-log-only. Это позволяет PXB выполнить окончательную очистку, откатав все транзакции, которые все еще были незафиксированными на протяжении всей последовательности резервного копирования, что приводит к согласованному состоянию.

# Завершаем подготовку (без --apply-log-only)
xtrabackup --prepare --target-dir=$RESTORE_TARGET

# ВАЖНО: Ищите окончательное подтверждение, указывающее на 'xtrabackup: Recovery completed OK!'

Фаза восстановления 4: Копирование данных обратно в MySQL

После успешной подготовки данные в промежуточном каталоге ($RESTORE_TARGET) являются согласованными и готовыми для использования сервером MySQL.

  1. Остановите службу MySQL.
  2. Убедитесь, что каталог данных MySQL пуст или зарезервирован (необязательно: используйте опцию --move-back, если разрешено, но --copy-back безопаснее для восстановления).
  3. Используйте xtrabackup --copy-back для перемещения файлов.
  4. Исправьте разрешения.
  5. Перезапустите MySQL.
# Останавливаем службу MySQL
service mysql stop

# Копируем подготовленные файлы обратно в каталог данных MySQL
xtrabackup --copy-back --target-dir=$RESTORE_TARGET

# Обеспечиваем правильное владение файлами
chown -R mysql:mysql /var/lib/mysql

# Запускаем MySQL
service mysql start

Рекомендации по управлению инкрементными резервными копиями

Автоматизация и создание сценариев

Стратегии инкрементного резервного копирования наиболее эффективны при полной автоматизации. Сценарии должны автоматически управлять цепочкой LSN, динамически определяя самый последний каталог резервных копий для использования с флагом --incremental-basedir.

Политика хранения

Инкрементные цепочки могут стать очень длинными, что замедляет восстановление. Распространенной лучшей практикой является стратегия "Дед-Отец-Сын" (GFS) или дифференциальные инкрементные резервные копии (где все инкременты ссылаются на полную базовую копию). Периодически обновляйте цепочку, выполняя новую полную резервную копию, чтобы начать свежую, короткую цепочку.

Сжатие и регулирование

Для очень загруженных серверов рассмотрите возможность использования опции --throttle на этапе резервного копирования для ограничения операций ввода-вывода. Используйте --compress для уменьшения размера резервной копии, что очень полезно для меньших объемов данных, генерируемых инкрементными резервными копиями.

# Пример со сжатием и регулированием
xtrabackup --backup \n  --target-dir=$INCREMENTAL_3_DIR \n  --incremental-basedir=$INCREMENTAL_2_DIR \n  --compress \n  --throttle=100

Проверка и мониторинг

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