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

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

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

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

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

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

Примечание

Вы можете легко создать дифференциальную резервную копию, используя параметр --incremental-base=history:last_full_backup.

См. раздел 20.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. Поскольку журнал переигрывания имеет максимальный размер, известный заранее, в зависимости от размера базы данных, количества операций DML и размера журнала переигрывания, обычно требуется меньше операций ввода-вывода для чтения изменений из журнала переигрывания, чем для сканирования файлов табличного пространства InnoDB, чтобы найти изменённые страницы.
Системная переменная контролирует объем дискового пространства, занимаемого файлами журнала переигрывания. Если файлы журнала переигрывания занимают меньше места, чем значение , грязные страницы сбрасываются из буфера пула в файлы данных табличного пространства менее агрессивно, что позволяет дисковому пространству, занимаемому файлами журнала переигрывания, расти быстрее. Если занимаемое пространством место приближается к указанному значению, грязные страницы сбрасываются более агрессивно, чтобы занимаемое дисковое пространство журнала переигрывания оставалось в заданных пределах. Подробности см. в .

В связи с тем, как теперь ведётся журнал переигрывания, возрастает вероятность того, что при запуске инкрементного резервного копирования, использующего только журнал переигрывания, файлы журнала переигрывания, хранящие изменения в базе данных с момента последнего резервного копирования, уже обработаны и больше недоступны. Чтобы предотвратить эту ситуацию, необходимо зарегистрировать mysqlbackup (пользователь MySQL, создающий резервные копии) в сервере как внешнего потребителя журнала переигрывания с помощью следующей команды UDF, до создания любых данных, которые должны быть включены в инкрементное резервное копирование, использующее только журнал переигрывания:
```
DO innodb_redo_log_consumer_register();
```
Это предотвращает удаление или переиспользование InnoDB файлов журнала переигрывания, которые содержат транзакции, ещё не резервируемые mysqlbackup. После каждого инкрементного резервного копирования, использующего только журнал переигрывания, выполните следующую UDF, чтобы перейти к новой контрольной точке LSN, чтобы сервер мог теперь обрабатывать файлы журнала переигрывания, которые больше не требуются mysqlbackup:
```
DO innodb_redo_log_consumer_advance($lsn);
```
$lsn — это наибольшее значение LSN, включённое в завершённое инкрементное резервное копирование.

Вышеуказанные шаги предполагают, что сессия подключения, которая инициировала UDF DO innodb_redo_log_consumer_register();, поддерживается открытой между базовым резервным копированием или последним инкрементным резервным копированием и последним инкрементным резервным копированием, использующим только журнал переигрывания. Один из способов помочь в этом — запустить на том же компьютере сервера специального клиента, который подключается к серверу, например, через Unix-сокет (если это Unix-машина) через сеанс подключения, который инициирует UDF и затем остаётся открытым до тех пор, пока это необходимо. Такая настройка обеспечит стабильный сеанс подключения для поддержания mysqlbackup как потребителя журнала переигрывания.
Этот тип инкрементного резервного копирования менее терпим к слишком низким значениям --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 с использованием традиционного инкрементного метода. И наоборот, если объём данных большой, чтение всех файлов данных для поиска немногих изменённых страниц может быть менее эффективным, чем обработка намного меньших файлов журнала переигрывания.
- Сжатие резервных копий (т. е. использование параметров сжатия) не поддерживается при выполнении инкрементных резервных копий только с журналом переигрывания. Если сжатие резервных копий важно для вас, не используйте параметр --incremental-with-redo-log-only.

Инкрементное резервное копирование с отслеживанием страниц

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

Установите компонент mysqlbackup, который входит в установку MySQL Enterprise Server 9.2, выполнив эту команду в клиенте mysql, подключенном к серверу:
```
INSTALL COMPONENT "file://component_mysqlbackup"; 
```
Запустите отслеживание страниц с помощью следующей функции:
```
SELECT mysqlbackup_page_track_set(true);
```
Значение LSN, начиная с которого отслеживаются изменённые страницы, возвращается этой функцией:
```
SELECT mysqlbackup_page_track_get_start_lsn(); 
```
Вы можете остановить отслеживание страниц с помощью следующей функции:
```
SELECT mysqlbackup_page_track_set(false);
```

Примечание

Перечисленные выше функции, связанные с отслеживанием страниц, требуют привилегии BACKUP_ADMIN для выполнения.

Когда используется параметр --incremental без указания значения, mysqlbackup выполняет инкрементное резервное копирование с помощью функциональности отслеживания страниц. Пользователь также может указать --incremental=page-track, чтобы mysqlbackup использовал функциональность отслеживания страниц. Однако, предварительные условия для использования функциональности отслеживания страниц для инкрементных резервных копий следующие:

Функциональность отслеживания страниц работает должным образом на сервере и была включена (с SELECT mysqlbackup_page_track_set(true)) до создания базового резервного копирования; если это не так, mysqlbackup выдаёт ошибку, когда --incremental=page-track, или он выполняет инкрементное резервное копирование с полным сканированием вместо этого, когда --incremental не указано.
Количество изменённых страниц меньше 50% от общего количества страниц; если это не так, mysqlbackup выдаёт ошибку, когда --incremental=page-track, или он выполняет инкрементное резервное копирование с полным сканированием вместо этого, когда --incremental не указано.

Примечание

mysqlbackup необходимо запускать с достаточным объёмом памяти для обработки всех отслеживаемых страниц в оперативной памяти. Если памяти недостаточно, mysqlbackup выдаст ошибку и завершит работу. Ниже приведены рекомендации по обеспечению достаточного объёма памяти для операции:

Значение по умолчанию 400 [МБ] для параметра --limit-memory позволяет mysqlbackup обрабатывать около 800 ГБ изменённых данных. Настройте значение параметра в соответствии с размером ваших данных.
Функция отслеживания страниц использует буферы памяти, настроенные для mysqlbackup, для сортировки страниц. Определите необходимое количество буферов для сортировки страниц, выполнив следующие шаги:
- Перед запуском инкрементального бэкапа выполните следующий запрос на сервере, чтобы определить end_lsn для базового бэкапа:
```
SELECT end_lsn FROM mysql.backup_history WHERE exit_state = 'SUCCESS'
AND backup_type != 'TTS' AND server_uuid = @@server_uuid
ORDER BY end_time DESC, end_lsn DESC LIMIT 0,1;
```
- Выполните следующий запрос на сервере, чтобы получить количество изменённых страниц с момента создания базового бэкапа (повторите запрос, если он возвращает отрицательное значение):
```
SELECT mysqlbackup_page_track_get_changed_page_count(<the above end_lsn>, 0);
```
- Каждая изменённая страница требует 8 байт в буфере сортировки. Умножьте значение changed_page_count, полученное на последнем шаге, на 8, чтобы получить количество байт, необходимых для буфера сортировки.
- Каждый буфер имеет размер 16 мегабайт (16777216 байт). Разделите количество байт, необходимых для буферов сортировки, рассчитанное на предыдущем шаге, на 16777216 и округлите результат до ближайшего целого числа, чтобы получить количество буферов, необходимых для сортировки.
- Убедитесь, что значение параметра --number-of-buffers не меньше, чем рассчитанное количество буферов сортировки. Имейте в виду, что в процессе вычисления могут быть созданы дополнительные изменённые страницы, поэтому вы можете предоставить mysqlbackup несколько дополнительных буферов.
Предельное значение памяти по умолчанию 400 МБ должно поддерживать до 25 буферов (только до 18 буферов для облачных бэкапов); увеличьте предельное значение памяти, если вам необходимо больше буферов, изменив значение параметра --limit-memory.

Отслеживание страниц создаёт файл в каталоге данных сервера для сбора информации об изменённых страницах. Этот файл продолжает расти до тех пор, пока отслеживание страниц не будет остановлено. Если сервер остановлен и перезапущен, создаётся новый файл отслеживания страниц, но старый файл сохраняется и продолжает расти до явного отключения отслеживания страниц. С помощью последовательности SQL-команд, подобной следующей, можно очистить любые устаревшие данные отслеживания страниц, которые больше не нужны:

SELECT mysqlbackup_page_track_set(false);
SELECT mysqlbackup_page_track_purge_up_to(9223372036854775807);
/* Supply to the loadable function the LSN up to which you want to
purge page tracking data. 9223372036854775807 is the highest possible LSN,
which causes all page tracking files to be purged.*/
SELECT mysqlbackup_page_track_set(true);

Это можно выполнить, например, перед каждым полным бэкапом.

Полный сканирование против оптимистичного инкрементального бэкапа

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

С другой стороны, оптимистичный инкрементальный бэкап сканирует только изменённые страницы в файлах данных InnoDB, которые были изменены с момента последнего бэкапа, тем самым экономя время на ненужном сканировании. Оптимистичный инкрементальный бэкап можно выполнить, указав --incremental=optimistic. Хотя оптимистичный инкрементальный бэкап может сократить время бэкапа, он имеет следующие ограничения:

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

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

Другие соображения по инкрементальным бэкапам

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

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

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

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

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

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

Указать mysqlbackup на запрос значения end_lsn из последнего успешно выполненного бэкапа, как записано в таблице backup_history на сервере, используя --incremental-base=history:last_backup или history:last_full_backup.
Дополнительно: Для бэкапов каталогов укажите каталог предыдущего бэкапа (полного или инкрементального) с помощью --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, “Восстановление инкрементной резервной копии”