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

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, включенное в завершенное инкрементальное резервное копирование.

Приведенные выше шаги предполагают, что сеанс подключения, который инициировал DO innodb_redo_log_consumer_register(); UDF, остается открытым между базовым резервным копированием или последним инкрементальным резервным копированием и последним инкрементальным резервным копированием только с использованием журнала переигрывания. Один из способов помочь в этом — запустить на том же компьютере специальный клиент, который подключается к серверу, например, через 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 8.4, выполнив эту команду в клиенте 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 или таблиц non-InnoDB, которые являются только для чтения или редко обновляются. Инкрементальные бэкапы обнаруживают изменения на уровне страниц в InnoDB, а не строк таблиц; каждый изменённая страница бэкапится. Таким образом, экономия места и времени не прямо пропорциональна проценту изменённых строк или столбцов InnoDB.

Для файлов non-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 «Восстановление инкрементального бэкапа»