Spec-Zone .ru
спецификации, руководства, описания, API
|
Чтобы быть полезными, резервные копии должны регулярно планироваться. Полное резервное копирование (снимок
данных в моменте времени) может быть сделано в 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 команда, сделанная полным резервным копированием, те строки означают две вещи:
Файл дампа содержит все изменения, произведенные перед любыми изменениями,
записанными gbichot2-bin.000007
двоичный файл журнала или более новый.
Все изменения данных, зарегистрированные после резервного копирования, не
присутствуют в файле дампа, но присутствуют в gbichot2-bin.000007
двоичный
файл журнала или более новый.
В понедельник в 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
Удаление двоичных журналов MySQL с mysqldump - "удаляет основные журналы", может быть
опасным, если Ваш сервер является главным сервером репликации, потому что ведомые серверы еще, возможно, не
полностью обработали содержание двоичного журнала. Описание для PURGE BINARY LOGS
оператор объясняет, что должно быть проверено прежде,
чем удалить двоичные журналы MySQL. См. Раздел 13.4.1.1,"PURGE BINARY LOGS
Синтаксис".