7.1. Резервное копирование и Типы Восстановления

Этот раздел описывает характеристики различных типов резервных копий.

Физический (Сырые данные) Против Логических Резервных копий

Физические резервные копии состоят из необработанных копий каталогов и файлов та база данных хранилища содержание. Этот тип резервного копирования является подходящим для больших, важных баз данных, которые должны быть восстановлены быстро, когда проблемы происходят.

Логические резервные копии сохраняют информацию, представленную как логическая структура базы данных (CREATE DATABASE, CREATE TABLE операторы) и контент (INSERT операторы или разграниченные текстовые файлы). Этот тип резервного копирования является подходящим для меньших объемов данных, где Вы могли бы отредактировать значения данных или структуру таблицы, или воссоздать данные на различной машинной архитектуре.

У физических резервных методов есть эти характеристики:

Резервное копирование состоит из точных копий каталогов базы данных и файлов. Обычно это - копия всех или часть каталога данных MySQL.
Физические резервные методы быстрее чем логичный, потому что они включают только копирование файла без преобразования.
Вывод более компактен чем для логического резервного копирования.
Поскольку резервная скорость и компактность важны для занятых, важных баз данных, Резервный продукт MySQL Enterprise выполняет физические резервные копии. Для краткого обзора Резервного продукта MySQL Enterprise см. Раздел 24.2, "Резервное копирование MySQL Enterprise".
Гранулярность резервного копирования и восстановления колеблется от уровня всего каталога данных вниз к уровню отдельных файлов. Это может или, возможно, не предусматривает гранулярность на уровне таблицы, в зависимости от механизма хранения. Например, InnoDB таблицы могут каждый быть в отдельном файле, или совместно использовать хранилище файлов с другим InnoDB таблицы; каждый MyISAM таблица соответствует уникально ряду файлов.
В дополнение к базам данных резервное копирование может включать любые связанные файлы, такие как журнал или конфигурационные файлы.
Данные от MEMORY таблицы хитры, чтобы поддержать этот путь, потому что их содержание не сохранено на диске. (У Резервного продукта MySQL Enterprise есть функция, откуда можно получить данные MEMORY таблицы во время резервного копирования.)
Резервные копии переносимы только на другие машины, у которых есть идентичные или подобные аппаратные характеристики.
Резервные копии могут быть выполнены, в то время как сервер MySQL не работает. Если сервер работает, необходимо выполнить соответствующую блокировку так, чтобы сервер не изменил содержание базы данных во время резервного копирования. Резервное копирование MySQL Enterprise делает эту блокировку автоматически для таблиц, которые требуют этого.
Физические резервные инструменты включают mysqlbackup Резервного копирования MySQL Enterprise для InnoDB или любые другие таблицы, системные команды файла (такие как cp, scp, tar, rsync), или mysqlhotcopy для MyISAM таблицы.
Для восстановления:
- Резервные восстановления MySQL Enterprise InnoDB и другие таблицы, которые это поддержало.
- восстановления ndb_restore NDB таблицы.
- Файлы, скопированные на уровне файловой системы или с mysqlhotcopy, могут быть скопированы назад в их исходные расположения с командами файловой системы.

У логических резервных методов есть эти характеристики:

Резервное копирование делается, запрашивая сервер MySQL, чтобы получить информация о контенте и структура базы данных.
Резервное копирование медленнее чем физические методы, потому что сервер должен получить доступ к информации о базе данных и преобразовать ее в логический формат. Если вывод пишется на стороне клиента, сервер должен также отправить это резервной программе.
Вывод больше чем для физического резервного копирования, особенно когда текстовый формат, в котором сохраняют.
Гранулярность резервного копирования и восстановления доступна на уровне сервера (все базы данных), уровень базы данных (все таблицы в определенной базе данных), или табличный уровень. Это - истина независимо от механизма хранения.
Резервное копирование не включает журнал или конфигурационные файлы, или другие связанные с базой данных файлы, которые не являются частью баз данных.
Резервные копии, сохраненные в логическом формате, независимы от машины и очень переносимы.
Логические резервные копии выполняются с выполнением сервера MySQL. Сервер не берется офлайн.
Логические резервные инструменты включают mysqldump программу и SELECT ... INTO OUTFILE оператор. Они работают на любой механизм хранения, даже MEMORY.
Чтобы восстановить логические резервные копии, файлы дампа формата SQL могут быть обработаны, используя mysql клиент. Чтобы загрузить разграниченные текстовые файлы, используйте LOAD DATA INFILE оператор или mysqlimport клиент.

Онлайн Против Офлайновых Резервных копий

Онлайновые резервные копии имеют место, в то время как сервер MySQL работает так, чтобы информация о базе данных могла быть получена из сервера. Офлайновые резервные копии имеют место, в то время как сервер останавливается. Это различие может также быть описано как "горячее" против "холодных" резервных копий; "теплое" резервное копирование является тем, где сервер остается работать, но заблокированный против изменения данных, в то время как Вы получаете доступ к файлам базы данных внешне.

У онлайновых резервных методов есть эти характеристики:

Резервное копирование менее навязчиво другим клиентам, которые могут соединиться с сервером MySQL во время резервного копирования и могут быть в состоянии получить доступ к данным в зависимости от того, какие операции они должны выполнить.
Забота должна быть проявлена, чтобы наложить соответствующую блокировку так, чтобы модификации данных не имели место, который поставил бы под угрозу резервную целостность. Резервный продукт MySQL Enterprise делает такую блокировку автоматически.

У офлайновых резервных методов есть эти характеристики:

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

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

Локальный Против Удаленных Резервных копий

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

mysqldump может соединиться с локальными или удаленными серверами. Для вывода SQL (CREATE и INSERT операторы), локальные или удаленные дампы могут быть сделаны и генерировать вывод на клиенте. Для вывода разграниченного текста (с --tab опция), файлы данных создаются на узле сервера.
mysqlhotcopy выполняет только локальные резервные копии: Это соединяется с сервером, чтобы заблокировать это против модификаций данных и затем копирует локальные табличные файлы.
SELECT ... INTO OUTFILE может инициироваться от локального или удаленного хоста клиента, но выходной файл создается на узле сервера.
Физические резервные методы обычно инициируются локально на узле сервера MySQL так, чтобы сервер мог быть взят офлайн, хотя место назначения для скопированных файлов могло бы быть удаленным.

Резервные копии снимка

Некоторые реализации файловой системы позволяют "снимкам" быть взятыми. Они обеспечивают логические копии файловой системы в данный момент времени, не требуя физической копии всей файловой системы. (Например, реализация может использовать методы копии на записи так, чтобы только части файловой системы, измененной после времени снимка должны были быть скопированными.) сам MySQL не обеспечивает возможность взятия снимков файловой системы. Это доступно через сторонние решения, такие как Veritas, LVM, или ZF.

Полный Против Инкрементных Резервных копий

Полное резервное копирование включает все данные, которыми управляет сервер MySQL в данный момент времени. Инкрементное резервное копирование состоит из изменений, произведенных в данных во время данного отрезка времени (от одного момента времени до другого). У MySQL есть различные способы выполнить полные резервные копии, такие как описанные ранее в этом разделе. Инкрементные резервные копии делаются возможными, включая двоичному журналу сервера, который использование сервера записать изменения данных.

Полный Против Момента времени (Инкрементное) Восстановление

Полное восстановление восстанавливает все данные от полного резервного копирования. Это восстанавливает экземпляр сервера к состоянию, которое он имел, когда резервное копирование было сделано. Если то состояние не является достаточно текущим, полное восстановление может сопровождаться восстановлением инкрементных резервных копий, сделанных начиная с полного резервного копирования, чтобы принести сервер к более актуальному состоянию.

Инкрементное восстановление является восстановлением изменений, произведенных во время данного отрезка времени. Это также вызывают восстановлением момента времени, потому что оно делает ток состояния сервера до данного времени. Восстановление момента времени основано на двоичном журнале и обычно следует за полным восстановлением после файлов резервных копий, которое восстанавливает сервер к его состоянию, когда резервное копирование было сделано. Затем изменения данных, записанные в двоичных файлах журнала, применяются как инкрементное восстановление, чтобы восстановить модификации данных и принести серверу до требуемого момента времени.

Табличное Обслуживание

Целостность данных может поставиться под угрозу, если таблицы становятся поврежденными. Для InnoDB таблицы, это не типичная проблема. Для программ, чтобы проверить MyISAM таблицы и восстанавливают их, если проблемы находятся, см. Раздел 7.6,"MyISAM Табличное Обслуживание и Восстановление Катастрофического отказа" .

Резервное Планирование, Сжатие, и Шифрование

Резервное планирование ценно для того, чтобы автоматизировать процедуры резервного копирования. Сжатие резервного вывода уменьшает требования пространства, и шифрование вывода обеспечивает лучшую безопасность против несанкционированного доступа поддержанных данных. Сам MySQL не обеспечивает эти возможности. Резервный продукт MySQL Enterprise может сжаться InnoDB резервные копии, и сжатие или шифрование резервного вывода могут быть достигнуты, используя утилиты файловой системы. Другие сторонние решения могут быть доступными.