4.3.3 Making a Differential or Incremental Backup — MySQL Enterprise Backup 4.1

4.3.3 Создание дифференциальной или инкрементной резервной копии

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

Выполнение серии дифференциальных резервных копий. Каждая из них включает все изменения, внесенные в данные с момента последнего создания полной резервной копии. Чтобы восстановить данные до, например, времени t, просто восстановите сначала полную резервную копию, а затем поверх нее дифференциальную резервную копию, созданную для времени t.
Выполнение серии инкрементных резервных копий. Каждая включает только изменения с момента предыдущей резервной копии, которая сама может быть полной или инкрементной. Первая резервная копия в серии инкрементных копий всегда является дифференциальной резервной копией; но после этого каждая инкрементная резервная копия содержит только изменения, внесенные с момента последней инкрементной резервной копии. Каждая последующая инкрементная резервная копия обычно меньше по размеру, чем дифференциальная резервная копия, и создается быстрее; это позволяет создавать очень частые инкрементные резервные копии и позволяет восстановить базу данных до более точной точки времени при необходимости. Однако восстановление данных с помощью инкрементных резервных копий может занять больше времени и усилий: как правило, чтобы восстановить данные до, например, времени t, вы начинаете с восстановления полной резервной копии, а затем восстанавливаете инкрементные резервные копии по одной, пока не закончите с инкрементной резервной копией, созданной для времени t.

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

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

Примечание

Для MySQL Enterprise Backup 4.1.5 и более поздних версий вы можете легко создать дифференциальную резервную копию, используя опцию --incremental-base=history:last_full_backup.

См. Раздел 16.7, «Опции инкрементного резервного копирования» для описаний опций mysqlbackup, используемых для инкрементных резервных копий. Инкрементная резервная копия включается с помощью одной из двух опций: --incremental и --incremental-with-redo-log-only опция. См. Создание инкрементных резервных копий, используя только журнал обратных записей для их различий.

При создании инкрементной резервной копии вы должны указать mysqlbackup момент времени предыдущей полной или инкрементной резервной копии. Для удобства вы можете использовать опцию --incremental-base для автоматического получения необходимых данных (LSN) из метаданных, хранящихся в каталоге предыдущей резервной копии или на сервере. Или вы можете указать явное значение LSN, используя опцию --start-lsn, предоставив mysqlbackup конечное LSN из предыдущей полной или инкрементной резервной копии (см. Другие соображения для инкрементных резервных копий о некоторых ограничениях, которые применяются при использовании опции --start-lsn).

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

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

Опция --incremental-with-redo-log-only может предоставить некоторые преимущества по сравнению с опцией --incremental для создания инкрементной резервной копии:

Изменения в таблицах InnoDB определяются на основе содержимого InnoDB. Поскольку файлы журнала обратных записей имеют фиксированный размер, который вы знаете заранее, чтение изменений из них может потребовать меньше операций ввода-вывода, чем сканирование файлов табличного пространства InnoDB для поиска измененных страниц, в зависимости от размера вашей базы данных, количества операций DML и размера файлов журнала обратных записей.
Поскольку файлы журнала обратных записей действуют как циклический буфер, записи о более старых изменениях перезаписываются по мере выполнения новых операций, вы должны создавать новые инкрементные резервные копии с предсказуемым графиком, диктуемым размером файлов журнала и объемом данных обратных записей, генерируемых для вашей рабочей нагрузки. В противном случае журнал обратных записей может не доставать достаточно далеко, чтобы записать все изменения с момента предыдущей инкрементной резервной копии, в этом случае mysqlbackup быстро определит, что не может продолжить, и вернет ошибку. Ваш скрипт резервного копирования должен уметь ловить эту ошибку и затем выполнять инкрементную резервную копию с помощью опции --incremental вместо этого.

Например:
- Для расчета размера журнала обратных записей выполните команду и, исходя из вывода, умножьте начение на значение . Чтобы вычислить размер журнала обратных записей на физическом уровне, обратитесь к каталогу datadir экземпляра MySQL и суммируйте размеры файлов, соответствующие шаблону ib_logfile*.
- Значение InnoDB соответствует количеству байтов, записанных в журнал обратных записей. Чтобы проверить LSN в определенный момент времени, выполните команду и посмотрите заголовком LOG. При планировании стратегии резервного копирования периодически записывайте значения LSN и вычитайте предыдущее значение из текущего, чтобы рассчитать, сколько данных обратных записей генерируется каждый час, день и т. д.
Этот тип инкрементной резервной копии не так терпим к слишком низким значениям --start-lsn, как стандартная опция --incremental. Например, вы не можете создать полную резервную копию, а затем создать серию --incremental-with-redo-log-only резервных копий, все используя одно и то же значение --start-lsn. Убедитесь, что вы указываете точное конечное значение LSN предыдущей резервной копии как начальное значение LSN следующей инкрементной резервной копии; не используйте произвольные значения.

Примечание

Чтобы гарантировать, что значения LSN точно совпадают между последующими инкрементными резервными копиями, рекомендуется всегда использовать опцию --incremental-base при использовании опции --incremental-with-redo-log-only.
Чтобы оценить, практичен ли и эффективен ли этот тип инкрементной резервной копии для конкретного экземпляра MySQL:
- Измерьте скорость изменения данных в файлах журнала обратных записей InnoDB. Периодически проверяйте , чтобы определить, сколько данных обратных записей накапливается в течение нескольких часов или дней.
- Сравните скорость накопления журнала обратных записей с размером файлов журнала обратных записей. Используйте это соотношение, чтобы увидеть, как часто нужно создавать инкрементные резервные копии, чтобы избежать вероятности сбоя резервной копии из-за отсутствия исторических данных в журнале обратных записей. Например, если вы производите 1 ГБ данных обратных записей в день, а общий размер файлов журнала обратных записей составляет 7 ГБ, вы будете планировать инкрементные резервные копии чаще, чем раз в неделю. Вы можете выполнять инкрементные резервные копии каждый день или два, чтобы избежать возможной проблемы, когда внезапный всплеск обновлений генерирует больше данных обратных записей, чем обычно.
- Проведите бенчмаркинг времени инкрементного резервного копирования, используя как опции --incremental, так и --incremental-with-redo-log-only, чтобы подтвердить, работает ли техника резервного копирования журнала обратных записей быстрее и с меньшей нагрузкой, чем традиционный метод инкрементного резервного копирования. Результат может зависеть от размера ваших данных, количества операций DML и размера файлов журнала обратных записей. Проводите тестирование на сервере с реалистичным объемом данных и рабочей нагрузкой. Например, если у вас есть огромные файлы журнала обратных записей, чтение их в процессе инкрементного резервного копирования может занять столько же времени, сколько и чтение файлов данных InnoDB с помощью традиционного инкрементного метода. И наоборот, если объем ваших данных большой, чтение всех файлов данных для поиска нескольких измененных страниц может быть менее эффективным, чем обработка значительно меньших файлов журнала обратных записей.

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

Функция инкрементного резервного копирования предназначена в первую очередь для таблиц InnoDB или таблиц, не являющихся InnoDB, которые являются только для чтения или редко обновляются. Инкрементные резервные копии обнаруживают изменения на уровне в InnoDB, а не строк таблиц; каждая измененная страница резервируется. Таким образом, экономия места и времени не пропорциональна проценту измененных строк или столбцов InnoDB.

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

Вы не можете выполнять инкрементные резервные копии с опцией --compress.

Файлы журнала бинарных логов не копируются в инкрементальную резервную копию, если используется опция --start-lsn. Для включения файлов журнала бинарных логов за период, охватываемый инкрементальной резервной копией, используйте вместо этого опцию --incremental-base, которая предоставляет необходимую информацию для mysqlbackup, чтобы гарантировать отсутствие разрывов между данными бинарного журнала, включенными в предыдущую резервную копию, и текущей инкрементальной резервной копией.

Полное сканирование против оптимистичной инкрементальной резервной копии

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

Оптимистичную инкрементальную резервную копию можно выполнить, указав --incremental=optimistic. Хотя оптимистичное инкрементальное резервное копирование может сократить время резервного копирования, оно имеет следующие ограничения:

Поскольку эта функция использует время изменения файлов в каталоге данных сервера, две вещи должны оставаться неизменными с момента предыдущего резервного копирования: (1) системное время на сервере и (2) расположение каталога данных. В противном случае резервное копирование может завершиться сбоем или может быть создана несогласованная инкрементальная резервная копия.
Оптимистичные инкрементальные резервные копии не могут быть выполнены с --incremental-with-redo-log-only, для которой mysqlbackup считывает файлы журнала повтора, а не сканирует файлы в каталоге данных.
Если используется опция --start-lsn, выполняется полное сканирование, даже если указана опция --incremental=optimistic, так как в этом случае mysqlbackup не может определить момент времени, для которого предыдущая резервная копия согласована, и, следовательно, не имеет временного интервала для определения, какие файлы были изменены недавно.

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

См. Раздел 4.1.2, «Назначение прав MySQL администратору резервного копирования» о правах, необходимых для mysqlbackup для выполнения оптимистичного инкрементального резервного копирования. Также см. Использование оптимистичных резервных копий и оптимистичных инкрементальных резервных копий вместе о том, как использовать две функции вместе в расписании резервного копирования.

Примеры инкрементальных резервных копий

В этих примерах используется mysqlbackup для создания инкрементальной резервной копии сервера MySQL, включая все базы данных и таблицы. Мы показываем два варианта, один с использованием опции --incremental-base, а другой с использованием опции --start-lsn.

С помощью опции --incremental-base вам не нужно отслеживать значения LSN между одной резервной копией и следующей. Вместо этого можно сделать следующее:

Указать mysqlbackup на запрос значения end_lsn из последней успешной резервной копии, как записано в таблице backup_history на сервере, используя --incremental-base=history:last_backup или history:last_full_backup (для релизов 4.1.5 и более поздних).
Дополнительно: Для резервных копий каталогов укажите каталог предыдущей резервной копии (полной или инкрементальной) с помощью --incremental-base=dir:directory_path, и mysqlbackup определит начальную точку для этой резервной копии на основе метаданных более ранней резервной копии. Поскольку вам нужен известный набор имён каталогов, вы можете использовать жёстко заданные имена или генерировать последовательность имён в своём скрипте резервного копирования, а не использовать опцию --with-timestamp. Если ваша последняя резервная копия была файлом единого образца, вы всё ещё можете использовать --incremental-base=dir:directory_path для указания местоположения временного каталога, который вы предоставили с опцией --backup-dir во время последнего резервного копирования.

В следующем примере используется опция --incremental-base=history:last_backup, при которой mysqlbackup извлекает LSN последней успешной (не TTS) полной или частичной резервной копии из таблицы mysql.backup_history и выполняет инкрементальное резервное копирование на основе этого значения.

mysqlbackup --defaults-file=/home/dbadmin/my.cnf \
  --incremental --incremental-base=history:last_backup \
  --backup-dir=/home/dbadmin/temp_dir \
  --backup-image=incremental_image1.bi \
   backup-to-image

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

mysqlbackup --defaults-file=/home/dbadmin/my.cnf \
  --incremental=optimistic --incremental-base=history:last_backup \
  --backup-dir=/home/dbadmin/temp_dir \
  --backup-image=incremental_image1.bi \
   backup-to-image

Дополнительно: Используйте следующую команду для создания инкрементальной резервной копии каталога, используя опцию --incremental-base=dir:directory_path; резервная копия сохраняется в указанном местоположении --incremental-backup-dir:

mysqlbackup --defaults-file=/home/dbadmin/my.cnf --incremental \
  --incremental-base=dir:/incr-backup/wednesday \
  --incremental-backup-dir=/incr-backup/thursday \
  backup

Вы также можете использовать опцию --start-lsn для указания точки начала инкрементального резервного копирования. Вы должны записать LSN предыдущего резервного копирования, сообщённого mysqlbackup в конце резервного копирования:

mysqlbackup: Was able to parse the log up to lsn 2654255716

Это число также записывается в файл meta/backup_variables.txt в папке, указанной в --backup-dir во время резервного копирования. Затем передайте это число в mysqlbackup с помощью опции --start-lsn. Инкрементальное резервное копирование затем включает все изменения, произошедшие после указанного LSN.

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

mysqlbackup --defaults-file=/home/dbadmin/my.cnf --incremental \
  --start-lsn=2654255716 \
  --with-timestamp \
  --backup-dir=/incr-tmp \
  --backup-image=/incr-backup/incremental_image.bi \
  backup-to-image

В следующем примере, поскольку --backup-image не предоставляет полный путь к файлу образа, который будет создан, образ инкрементальной резервной копии создается в папке, указанной в --backup-dir:

mysqlbackup --defaults-file=/home/dbadmin/my.cnf --incremental \
  --start-lsn=2654255716 \
  --with-timestamp \
  --backup-dir=/incr-images \
  --backup-image=incremental_image1.bi \
  backup-to-image

Поддержание графика резервного копирования:

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

Как восстановить базу данных с использованием инкрементальных резервных копий, см. в Разделе 5.1.3, «Восстановление инкрементальной резервной копии»