4.3.6 Создание оптимистичной резервной копии
Оптимистичная резервная копия — это функция, улучшающая производительность при создании резервных копий и восстановлении огромных баз данных, в которых лишь небольшое число таблиц часто изменяется.
Во время горячей резервной копии огромной базы данных (скажем, порядка терабайтов) на сервере могут быть сгенерированы огромные файлы журналов перегенерации, когда резервная копия находится в процессе создания. Поскольку файлы журналов перегенерации растут быстрее, чем могут быть обработаны командой mysqlbackup, операция резервного копирования может фактически завершиться неудачей, когда mysqlbackup не может угнаться за циклами журнала перегенерации, а LSN перезаписываются сервером до того, как их прочитает mysqlbackup. Кроме того, шаг apply-log для подготовки резервной копии для восстановления может занять очень много времени, так как mysqlbackup имеет огромные ibbackup_logfile файлы (созданные из больших файлов журнала перегенерации) для применения к резервной копии. Проблемы усугубляются, когда ресурсы ввода-вывода, доступные для чтения и записи журналов перегенерации, ограничены во время процессов резервного копирования и восстановления.
Оптимистичная резервная копия снимает эти проблемы, разделив процесс резервного копирования на два внутренних этапа, которые прозрачны для пользователей:
Оптимистичная фаза: На этом первом этапе таблицы, которые вряд ли будут изменены во время процесса резервного копирования (называемые ниже «неактивными таблицами», определяемые пользователем с помощью опции
optimistic-timeили, исключая, опцииoptimistic-busy-tables) резервируются без блокировки экземпляра MySQL. И поскольку не ожидается, что эти таблицы будут изменены до завершения резервного копирования, журналы перегенерации, журналы отмены и пространства таблиц системы не резервируются mysqlbackup на этом этапе.Нормальная фаза: На этом втором этапе таблицы, которые не были резервированы на первом этапе (называемые ниже «активными таблицами»), резервируются аналогично тому, как они обрабатываются в обычной резервной копии: сначала копируются файлы InnoDB, а затем другие соответствующие файлы и копируются или обрабатываются с заблокированным экземпляром MySQL. На этом этапе также резервируются журналы перегенерации, журналы отмены и пространство таблиц системы.
Оптимистичная резервная копия создается всякий раз, когда используется опция optimistic-time или optimistic-busy-tables. Описание использования опций см. в подробных описаниях в разделе Раздел 16.10, «Параметры производительности, масштабируемости и емкости». Если, как ожидается, список неактивных таблиц, определенных оптимистическими опциями, не изменится во время резервного копирования (или, даже если он изменится на небольшой процент), большинство пользователей обнаружат, что общее время резервного копирования значительно сокращается по сравнению с обычным резервным копированием, поскольку размер данных журнала перегенерации, подлежащих резервированию, будет значительно меньше. Кроме того, время восстановления резервной копии также сократится, так как операция apply-log будет намного быстрее из-за меньшего журнала перегенерации. Однако, если окажется, что список неактивных таблиц, определенных в процессе резервного копирования, изменился существенно, преимущества выполнения оптимистичной резервной копии ограничатся, а в худшем случае оптимистичная резервная копия может фактически занять больше времени для выполнения, и в случае резервного копирования одного файла размер резервной копии будет больше по сравнению с обычной резервной копией. Поэтому пользователи должны быть осторожны при определении, какие таблицы являются «неактивными», а какие — «активными», когда они пытаются выполнить оптимистичную резервную копию.
Оптимистичная резервная копия не может быть выполнена для инкрементальной резервной копии или резервной копии, использующей .
Следующие примеры иллюстрируют, как создать оптимистичную резервную копию.
Пример 4.25 Оптимистичная резервная копия с использованием опции optimistic-time=YYMMDDHHMMSS
В этом примере таблицы, измененные после полудня 16 мая 2011 года, считаются активными таблицами и резервируются в нормальной фазе оптимистичной резервной копии, а все остальные таблицы резервируются в оптимистической фазе:
mysqlbackup --defaults-file=/etc/my.cnf --optimistic-time=110516120000 backup-to-image
Пример 4.26 Оптимистичная резервная копия с использованием опции optimistic-time=now
В этом примере все таблицы считаются неактивными таблицами и резервируются в оптимистической фазе оптимистичной резервной копии:
mysqlbackup --defaults-file=/etc/my.cnf --optimistic-time=now backup-to-image
Пример 4.27 Оптимистичная резервная копия с использованием опции optimistic-busy-tables
В этом примере таблицы в mydatabase, имена которых начинаются с mytables-, считаются активными таблицами и резервируются в нормальной фазе оптимистичной резервной копии, а все остальные таблицы резервируются в оптимистической фазе:
mysqlbackup --defaults-file=/etc/my.cnf --optimistic-busy-tables="^mydatabase\.mytables-.*" backup
Когда вы используете как опцию optimistic-time, так и опцию optimistic-busy-tables, и они вступают в конфликт при определении того, какие таблицы должны быть активными, optimistic-busy-tables имеет приоритет над optimistic-time. Например:
Пример 4.28 Оптимистичная и частичная резервная копия с использованием опций optimistic-busy-tables и optimistic-time
В этом примере таблицы в mydatabase, имена которых начинаются с mytables-, считаются активными таблицами и резервируются в нормальной фазе, даже если они не изменялись с 16 мая 2010 года, времени, указанного в опции optimistic-time:
mysqlbackup --defaults-file=/etc/my.cnf --optimistic-busy-tables="^mydatabase\.mytables-.*" \
--optimistic-time=100516 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=/etc/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
© 2025 Oracle
Licensed under the GPLv2 License.
