Этот раздел суммирует некоторые общие методы для того, чтобы сделать резервные копии.

Создание Горячего Резервного копирования с Резервным копированием MySQL Enterprise

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

Создание Резервных копий с mysqldump или mysqlhotcopy

mysqldump программа и mysqlhotcopy сценарий могут сделать резервные копии. mysqldump является более общим, потому что он может поддержать все виды таблиц. mysqlhotcopy работает только с некоторыми механизмами хранения. (См. Раздел 7.4, "Используя mysqldump для Резервных копий", и Раздел 4.6.10, "mysqlhotcopy — Программа Резервного копирования базы данных".)

Для InnoDB таблицы, возможно выполнить онлайновое резервное копирование, которое берет, не соединяет таблицы, используя --single-transaction опция к mysqldump. См. Раздел 7.3.1, "Устанавливая Резервную Политику".

Создание Резервных копий Копированием Табличных Файлов

Для механизмов хранения, которые представляют каждую таблицу, используя ее собственные файлы, таблицы могут быть поддержаны, копируя те файлы. Например, MyISAM таблицы сохранены как файлы, таким образом, легко сделать резервное копирование, копируя файлы (*.frm, *.MYD, и *.MYI файлы). Чтобы получить непротиворечивое резервное копирование, остановите сервер или заблокируйте и сбросьте соответствующие таблицы:

FLUSH TABLES tbl_list WITH READ LOCK;

Вы нуждаетесь в только блокировке чтения; это позволяет другим клиентам продолжать запрашивать таблицы, в то время как Вы делаете копию файлов в каталоге базы данных. Сброс необходим, чтобы гарантировать, что все активные индексные страницы пишутся диску прежде, чем Вы запустите резервное копирование. См. Раздел 13.3.5,"LOCK TABLES и UNLOCK TABLES Синтаксис" , и Раздел 13.7.6.3,"FLUSH Синтаксис".

Можно также создать двоичное резервное копирование просто, копируя все табличные файлы, пока сервер ничего не обновляет. mysqlhotcopy сценарий использует этот метод. (Но отметьте, что табличные методы копирования файла не работают, если Ваша база данных содержит InnoDB таблицы. mysqlhotcopy не работает на InnoDB таблицы, потому что InnoDB делает не обязательно содержание таблицы store в каталогах базы данных. Кроме того, даже если сервер активно не обновляет данные, InnoDB май все еще изменил данные, кэшируемые в памяти, и не сбросил к диску.)

Создание Резервных копий Разграниченного текстового файла

Чтобы создать текстовый файл, содержащий данные таблицы, можно использовать SELECT * INTO OUTFILE 'file_name' FROM tbl_name. Файл создается на узле сервера MySQL, не хосте клиента. Для этого оператора не может уже существовать выходной файл, потому что разрешение файлов быть перезаписанным составляет угрозу безопасности. См. Раздел 13.2.9,"SELECT Синтаксис". Этот метод работает на любой вид файла данных, но сохраняет только табличные данные, не структуру таблицы.

Другой способ создать текстовые файлы данных (наряду с файлами, содержащими CREATE TABLE операторы для поддержанных таблиц), должен использовать mysqldump с --tab опция. См. Раздел 7.4.3, "Выводя Данные в Формате разграниченного текста с mysqldump".

Чтобы перезагрузить файл данных разграниченного текста, использовать LOAD DATA INFILE или mysqlimport.

Создание Инкрементных Резервных копий, Включая Двоичному Журналу

MySQL поддерживает инкрементные резервные копии: следует запустить сервер с --log-bin опция, чтобы включить двоичному журналированию; см. Раздел 5.2.4, "Двоичный Журнал". Двоичные файлы журнала предоставляют Вам информацию, Вы должны тиражировать изменения в базу данных, которые делаются последующими за точкой, в которой Вы выполняли резервное копирование. В настоящее время Вы хотите сделать инкрементное резервное копирование (содержащий все изменения, которые произошли начиная с последнего полного или инкрементного резервного копирования), следует повернуть двоичный журнал при использовании FLUSH LOGS. Сделанное, Вы должны скопировать в резервное расположение все двоичные журналы, которые колеблются от того момента последнего полного или инкрементного резервного копирования в предпоследнее. Эти двоичные журналы являются инкрементным резервным копированием; во время восстановления Вы применяете их как объяснено в Разделе 7.5, "Момент времени (Инкрементное) Восстановление Используя Двоичный Журнал". В следующий раз, когда Вы делаете полное резервное копирование, следует также повернуть двоичное использование журнала FLUSH LOGS, mysqldump - журналы сброса, или mysqlhotcopy - flushlog. См. Раздел 4.5.4, "mysqldump — Программа Резервного копирования базы данных", и Раздел 4.6.10, "mysqlhotcopy — Программа Резервного копирования базы данных" .

Создание Резервных копий Используя Ведомые устройства Репликации

Если у Вас есть проблемы производительности с Вашим главным сервером, делая резервные копии, одна стратегия, которая может помочь, состоит в том, чтобы установить репликацию и выполнить резервные копии на ведомом устройстве, а не на ведущем устройстве. См. Раздел 16.3.1, "Используя Репликацию для Резервных копий".

Если Вы поддерживаете ведомый сервер репликации, следует поддержать его основную информацию и релейные репозитарии информации журнала (см. Раздел 16.2.2, "Реле репликации и Журналы Состояния"), когда Вы поддерживаете базы данных ведомого устройства, независимо от резервного метода Вы выбираете. Эти информационные файлы всегда необходимы, чтобы возобновить репликацию после того, как Вы восстанавливаете данные ведомого устройства. Если Ваше ведомое устройство тиражируется LOAD DATA INFILE операторы, следует также поддержать любого SQL_LOAD-* файлы, которые существуют в каталоге, который ведомое устройство использует с этой целью. Ведомое устройство нуждается в этих файлах, чтобы возобновить репликацию любого прерванного LOAD DATA INFILE операции. Расположение этого каталога является значением --slave-load-tmpdir опция. Если сервер не был запущен с той опции, расположение каталога является значением tmpdir системная переменная.

Восстановление Поврежденных Таблиц

Если необходимо восстановить MyISAM таблицы, которые стали поврежденными, пытаются восстановить их использование REPAIR TABLE или myisamchk-r сначала. Это должно работать в 99.9 % всех случаев. Если myisamchk перестал работать, см. Раздел 7.6,"MyISAM Табличное Обслуживание и Восстановление Катастрофического отказа".

Создание Резервных копий Используя Снимок Файловой системы

Если Вы используете файловую систему Veritas, можно сделать резервное копирование как это:

Подобные возможности снимка могут быть доступными в других файловых системах, такими как LVM или ZF.