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

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

shell> mysqldump --single-transaction --all-databases
        > 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, который был запущен с --log-bin опция и это работали в течение нескольких дней, мы находим эти двоичные файлы журнала 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 создает новый двоичный файл журнала, используя следующее число в последовательности. В то время как сервер работает, можно также сказать ему закрывать текущий двоичный файл журнала и начинать новый вручную, выходя a FLUSH LOGS SQL-оператор или с mysqladmin командой журналов сброса. у mysqldump также есть опция, чтобы сбросить журналы. .index файл в каталоге данных содержит список всего двоичного файла MySQL, входит в систему каталог.

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

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

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

-- Position to start replication or point-in-time recovery from-- CHANGE MASTER TO MASTER_LOG_FILE='gbichot2-bin.000007',MASTER_LOG_POS=4;

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

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

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

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