Для того, чтобы резервные копии были полезными, их необходимо регулярно планировать. Полное резервное копирование (снимок данных на определенный момент времени) можно выполнить в MySQL с помощью нескольких инструментов. Например, MySQL Enterprise Backup может выполнить резервное копирование всего экземпляра с оптимизациями для минимизации накладных расходов и предотвращения прерываний при резервном копировании InnoDB файлов данных; mysqldump обеспечивает онлайн резервное копирование. В этом обсуждении используется mysqldump.

Предположим, что мы создаем полное резервное копирование всех наших InnoDB таблиц во всех базах данных, используя следующую команду в воскресенье в 13:00, когда нагрузка низкая:

$> mysqldump --all-databases --source-data --single-transaction > backup_sunday_1_PM.sql

Полученный .sql файл, созданный mysqldump, содержит набор SQL INSERT операторов, которые могут быть использованы для перезагрузки резервных копий таблиц в более позднее время.

Данная операция резервного копирования приобретает глобальную блокировку чтения всех таблиц в начале дампа (используя FLUSH TABLES WITH READ LOCK). Как только эта блокировка приобретена, считываются координаты бинарного лога, и блокировка снимается. Если при выполнении оператора FLUSH выполняются длинные операторы обновления, операция резервного копирования может приостановиться до завершения этих операторов. После этого дамп становится без блокировки и не нарушает чтение и запись в таблицы.

Ранее предполагалось, что таблицы для резервного копирования являются InnoDB таблицами, поэтому --single-transaction использует согласованное чтение и гарантирует, что данные, увиденные mysqldump, не изменятся. (Изменения, внесенные другими клиентами в InnoDB таблицы, не видны процессу mysqldump.) Если операция резервного копирования включает не транзакционные таблицы, для обеспечения согласованности необходимо, чтобы они не менялись во время резервного копирования. Например, для MyISAM таблиц в базе данных mysql не должно быть никаких административных изменений в учетных записях MySQL во время резервного копирования.

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

Для создания инкрементных резервных копий необходимо сохранить инкрементные изменения. В MySQL эти изменения представлены в бинарном журнале, поэтому сервер MySQL всегда должен запускаться с параметром --log-bin для включения этого журнала. При включенном бинарном протоколировании сервер записывает каждое изменение данных в файл во время обновления данных. Рассмотрев каталог данных сервера MySQL, который работал в течение нескольких дней, мы найдем эти файлы бинарного журнала MySQL:

-rw-rw---- 1 guilhem  guilhem   1277324 Nov 10 23:59 gbichot2-bin.000001
-rw-rw---- 1 guilhem  guilhem         4 Nov 10 23:59 gbichot2-bin.000002
-rw-rw---- 1 guilhem  guilhem        79 Nov 11 11:06 gbichot2-bin.000003
-rw-rw---- 1 guilhem  guilhem       508 Nov 11 11:08 gbichot2-bin.000004
-rw-rw---- 1 guilhem  guilhem 220047446 Nov 12 16:47 gbichot2-bin.000005
-rw-rw---- 1 guilhem  guilhem    998412 Nov 14 10:08 gbichot2-bin.000006
-rw-rw---- 1 guilhem  guilhem       361 Nov 14 10:07 gbichot2-bin.index

Каждый раз при перезапуске сервер MySQL создает новый файл бинарного журнала, используя следующее число в последовательности. Пока сервер работает, вы также можете поручить ему закрыть текущий файл бинарного журнала и начать новый вручную, выпустив оператор SQL FLUSH LOGS или с помощью команды mysqladmin flush-logs. mysqldump также имеет опцию для очистки журналов. Файл .index в каталоге данных содержит список всех бинарных журналов MySQL в каталоге.

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

$> mysqldump --single-transaction --flush-logs --source-data=2 \
         --all-databases > backup_sunday_1_PM.sql

После выполнения этой команды в каталоге данных появляется новый файл бинарного журнала, gbichot2-bin.000007, поскольку опция --flush-logs заставляет сервер очистить свои журналы. Опция --source-data заставляет mysqldump записывать информацию из бинарного журнала в свой вывод, поэтому результирующий .sql файл дампа включает эти строки:

-- Position to start replication or point-in-time recovery from
-- CHANGE REPLICATION SOURCE TO SOURCE_LOG_FILE='gbichot2-bin.000007',SOURCE_LOG_POS=4;

Поскольку команда mysqldump создала полную резервную копию, эти строки означают две вещи:

В понедельник в 13:00 мы можем создать инкрементную резервную копию, очистив журналы, чтобы начать новый файл бинарного журнала. Например, выполнение команды mysqladmin flush-logs создает gbichot2-bin.000008. Все изменения между воскресеньем 13:00 и понедельником 13:00 записаны в gbichot2-bin.000007. Эта инкрементная резервная копия важна, поэтому следует скопировать ее в безопасное место. (Например, сохраните ее на ленте или DVD, или скопируйте на другой компьютер.) Во вторник в 13:00 выполните еще одну команду mysqladmin flush-logs. Все изменения между понедельником 13:00 и вторником 13:00 записаны в gbichot2-bin.000008 (которое также следует скопировать в безопасное место).

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

$> mysqldump --single-transaction --flush-logs --source-data=2 \
         --all-databases --delete-source-logs > backup_sunday_1_PM.sql