4.3.6 Making an Optimistic Backup — MySQL Enterprise Backup 8.4

4.3.6 Создание оптимистичного бэкапа

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

При горячем бэкапе огромной базы данных (скажем, порядка терабайт) на сервере могут генерироваться огромные файлы журнала редопераций во время выполнения бэкапа. Поскольку файлы журнала редопераций растут быстрее, чем могут быть обработаны командой mysqlbackup, операция бэкапа может завершиться неудачей, когда mysqlbackup не успевает за циклами журнала редопераций, а LSN перезаписываются сервером до того, как их прочитает mysqlbackup. Более того, этап apply-log для подготовки бэкапа для восстановления может занять очень много времени, так как mysqlbackup имеет огромные ibbackup_logfile файлы (созданные из больших файлов журнала редопераций) для применения к бэкапу. Проблемы усугубляются, когда доступные ресурсы ввода-вывода для чтения и записи журналов редопераций ограничены во время процессов бэкапа и восстановления.

Оптимистичный бэкап устраняет эти проблемы, разделив процесс бэкапа на два внутренних этапа, прозрачных для пользователей:

Оптимистическая фаза: На этом первом этапе таблицы, которые, скорее всего, не будут изменены во время процесса бэкапа (ниже упоминаемые как «неактивные таблицы», определённые пользователем с помощью опции optimistic-time или, путём исключения, с помощью опции optimistic-busy-tables), бэкапятся без каких-либо блокировок на экземпляре MySQL. И поскольку ожидается, что эти таблицы не будут изменены до завершения бэкапа, журналы редопераций, журналы отката и пространства системных таблиц не бэкапятся mysqlbackup на этом этапе.
Нормальная фаза: На этом втором этапе таблицы, которые не были бэкапнуты на первом этапе (ниже упоминаемые как «занятые таблицы»), бэкапятся так же, как и в обычном бэкапе: сначала копируются файлы InnoDB, а затем другие соответствующие файлы копируются или обрабатываются с различными блокировками, применяемыми к базе данных в разное время. Также на этом этапе бэкапятся журналы редопераций, журналы отката и пространство системных таблиц.

Оптимистичный бэкап выполняется всякий раз, когда используется опция optimistic-time или optimistic-busy-tables. Более подробное описание использования опций можно найти в разделе 20.10 «Performance / Scalability / Capacity Options». Если, как ожидается, список неактивных таблиц, определённых опциями оптимистичного бэкапа, не меняется во время бэкапа (или даже если он меняется незначительно), большинство пользователей обнаружат, что общее время бэкапа значительно сокращается по сравнению с обычным бэкапом, так как размер данных журнала редопераций, которые необходимо бэкапнуть, будет значительно меньше. Кроме того, время восстановления бэкапа также сократится, так как операция apply-log будет значительно быстрее из-за меньшего журнала редопераций. Однако, если окажется, что список неактивных таблиц, определённых опциями, изменился существенно во время процесса бэкапа, преимущества от выполнения оптимистичного бэкапа будут ограничены, а в худшем случае оптимистичный бэкап может занять больше времени, и в случае бэкапа одного файла размер бэкапа будет больше по сравнению с обычным бэкапом. Поэтому пользователи должны быть внимательны при определении, какие таблицы «неактивные», а какие «занятые», при попытке выполнить оптимистичный бэкап.

Примечания

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

Следующие примеры иллюстрируют, как сделать оптимистичный бэкап.

Пример 4.24 Оптимистичный бэкап с использованием опции optimistic-time=YYMMDDHHMMSS

В этом примере таблицы, изменённые после полудня 16 мая 2011 года, рассматриваются как занятые таблицы и бэкапятся в нормальной фазе оптимистичного бэкапа, а все остальные таблицы бэкапятся в оптимистической фазе:

mysqlbackup --defaults-file=/home/dbadmin/my.cnf --optimistic-time=110516120000 \
  --backup-image=<image-name> --backup-dir=<temp-dir>  backup-to-image

Пример 4.25 Оптимистичный бэкап с использованием опции optimistic-time=now

В этом примере все таблицы рассматриваются как неактивные и бэкапятся в оптимистической фазе оптимистичного бэкапа:

mysqlbackup --defaults-file=/home/dbadmin/my.cnf --optimistic-time=now \
 --backup-image=<image-name> --backup-dir=<temp-dir> backup-to-image

Пример 4.26 Оптимистичный бэкап с использованием опции optimistic-busy-tables

В этом примере таблицы в mydatabase, имена которых начинаются с mytables-, рассматриваются как занятые таблицы и бэкапятся в нормальной фазе оптимистичного бэкапа, а все остальные таблицы бэкапятся в оптимистической фазе:

mysqlbackup --defaults-file=/home/dbadmin/my.cnf --optimistic-busy-tables="^mydatabase\.mytables-.*" \
 --backup-image=<image-name> --backup-dir=<temp-dir> backup

Когда используются опции optimistic-time и optimistic-busy-tables, и они вступают в конфликт при определении, какие таблицы должны быть занятыми, optimistic-busy-tables имеет приоритет над optimistic-time. Например:

Пример 4.27 Оптимистичный и частичный бэкап с использованием опций optimistic-busy-tables и optimistic-time

В этом примере таблицы в mydatabase, имена которых начинаются с mytables-, рассматриваются как занятые и бэкапятся в нормальной фазе, даже если они не были изменены с 16 мая 2010 года, времени, указанного в optimistic-time:

mysqlbackup --defaults-file=/home/dbadmin/my.cnf --optimistic-busy-tables="^mydatabase\.mytables-.*" \
  --optimistic-time=100516  --backup-image=<image-name> --backup-dir=<temp-dir>  backup

Использование оптимистичных бэкапов и оптимистичных инкрементных бэкапов вместе

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

# A full optimistic backup performed on 2017/02/04, Sat, at 1130 PM.
# The --optimistic-time option is used to specify an optimistic time of 2016/08/16, 0800 PM

mysqlbackup --defaults-file=/home/admin/my.cnf --optimistic-time=160816200000 \
  --backup-dir=/home/admin/temp_dir --backup-image=/home/admin/backups/mydb_full_201702042330.bi \
  --with-timestamp \
  backup-to-image

# A sequence of optimistic incremental backups are then performed on each the following six days at 1130 PM
# On Sunday, 2017/02/05
mysqlbackup --defaults-file=/home/admin/my.cnf \
  --incremental=optimistic --incremental-base=history:last_backup \
  --backup-dir=/home/admin/temp_dir \
  --backup-image=/home/admin/backups/mydb_incremental__201702052330.bi \
  --with-timestamp \
  backup-to-image
# On Monday, 2017/02/06
mysqlbackup --defaults-file=/home/admin/my.cnf \
  --incremental=optimistic --incremental-base=history:last_backup \
  --backup-dir=/home/admin/temp_dir \
  --backup-image=/home/admin/backups/mydb_incremental__201702062330.bi \
  --with-timestamp \
  backup-to-image
# On Tuesday, 2017/02/07
mysqlbackup --defaults-file=/home/admin/my.cnf \
  --incremental=optimistic --incremental-base=history:last_backup \
  --backup-dir=/home/admin/temp_dir \
  --backup-image=/home/admin/backups/mydb_incremental__201702072330.bi \
  --with-timestamp \
  backup-to-image
# On Wednesday, 2017/02/08
mysqlbackup --defaults-file=/home/admin/my.cnf \
  --incremental=optimistic --incremental-base=history:last_backup \
  --backup-dir=/home/admin/temp_dir \
  --backup-image=/home/admin/backups/mydb_incremental__201702082330.bi \
  --with-timestamp backup-to-image
# On Thursday, 2017/02/09
mysqlbackup --defaults-file=/home/admin/my.cnf \
  --incremental=optimistic --incremental-base=history:last_backup \
  --backup-dir=/home/admin/temp_dir \
  --backup-image=/home/admin/backups/mydb_incremental__201702092330.bi \
  --with-timestamp \
  backup-to-image
# On Friday, 2017/02/10
mysqlbackup --defaults-file=/home/admin/my.cnf \
  --incremental=optimistic --incremental-base=history:last_backup \
  --backup-dir=/home/admin/temp_dir \
  --backup-image=/home/admin/backups/mydb_incremental__201702102330.bi \
  --with-timestamp \
  backup-to-image

# Another full optimistic backup is performed on Saturday, 2017/02/11
mysqlbackup --defaults-file=/home/dbadmin/my.cnf --optimistic-time=110516200000 \
 --backup-dir=/home/admin/temp_dir --backup-image=/home/admin/backups/mydb_full_201702112330.bi \
  --with-timestamp \
  backup-to-image

# Restore the database to its state at Tuesday, 2017/02/07, at 11:30 PM
# First, restore the full optimistic backup taken on the Saturday before, which was 2017/02/04:
mysqlbackup --defaults-file=/etc/my.cnf --backup-image=/home/admin/backups/mydb_full_201702042330.bi \
  --backup-dir=/home/admin/temp_dir --datadir=/var/lib/mysql \
  --with-timestamp \
  copy-back-and-apply-log
# Next, restore the optimistic incremental taken on the Sunday, Monday, and Tuesday that follow:
mysqlbackup --defaults-file=/etc/my.cnf --backup-image=/home/admin/backups/mydb_incremental__201702052330.bi \
  --backup-dir=/home/admin/temp_dir --datadir=/var/lib/mysql --incremental \
  --with-timestamp \
  copy-back-and-apply-log
mysqlbackup --defaults-file=/etc/my.cnf --backup-image=/home/admin/backups/mydb_incremental__201702062330.bi \
  --backup-dir=/home/admin/temp_dir --datadir=/var/lib/mysql --incremental \
  --with-timestamp \
  copy-back-and-apply-log
mysqlbackup --defaults-file=/etc/my.cnf --backup-image=/home/admin/backups/mydb_incremental__201702072330.bi \
  --backup-dir=/home/admin/temp_dir --datadir=/var/lib/mysql --incremental \
  --with-timestamp \
  copy-back-and-apply-log