В этом разделе описываются некоторые общие методы создания резервных копий.

Создание горячей резервной копии с помощью MySQL Enterprise Backup

Клиенты MySQL Enterprise Edition могут использовать этот продукт для резервного копирования целых экземпляров или выбранных баз данных, таблиц или того и другого. Этот продукт включает функции для и резервных копий. Резервное копирование физических файлов базы данных делает восстановление намного быстрее, чем логические методы, такие как команда mysqldump. InnoDB таблицы копируются с помощью механизма. (В идеале, InnoDB таблицы должны представлять значительную часть данных.) Таблицы из других движков хранения копируются с помощью механизма. Для обзора продукта MySQL Enterprise Backup см. Раздел 28.1, «Обзор MySQL Enterprise Backup».

Создание резервных копий с помощью mysqldump

Программа mysqldump может создавать резервные копии. Она может создавать резервные копии всех типов таблиц. (См. Раздел 7.4, «Использование mysqldump для резервного копирования».)

Для 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».

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

Создание резервных копий в формате файлов с разделителями

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

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

Для загрузки файла данных с разделителями используйте LOAD DATA или mysqlimport.

Создание инкрементных резервных копий, включив двоичный журнал

MySQL поддерживает инкрементные резервные копии: вам необходимо запустить сервер с параметром --log-bin, чтобы включить двоичное протоколирование; см. Раздел 5.4.4, «Двоичный журнал». Файлы двоичного журнала предоставляют вам информацию, необходимую для репликации изменений в базе данных, внесенных после того, как вы выполнили резервное копирование. В момент, когда вы хотите создать инкрементную резервную копию (содержащую все изменения, произошедшие с момента последней полной или инкрементной резервной копии), вам необходимо переключить двоичный журнал, используя FLUSH LOGS. После этого вам нужно скопировать в место резервной копии все двоичные журналы, начиная с журнала момента последней полной или инкрементной резервной копии и заканчивая предпоследним. Эти двоичные журналы являются инкрементной резервной копией; при восстановлении вы применяете их, как описано в Разделе 7.5, «Восстановление в определённое время (инкрементное)». В следующий раз, когда вы создадите полную резервную копию, вам следует также переключить двоичный журнал, используя FLUSH LOGS или mysqldump --flush-logs. См. Раздел 4.5.4, «mysqldump — программа для резервного копирования базы данных».

Создание резервных копий с использованием реплик

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

Если вы создаете резервную копию реплики сервера, вы должны создать резервную копию ее информации о источнике и релейных журналов (см. Раздел 16.2.4, «Релейный журнал и репозитории метаданных репликации») при резервном копировании баз данных реплики, независимо от выбранного метода резервного копирования. Эти файлы информации всегда необходимы для возобновления репликации после восстановления данных реплики. Если ваша реплика дублирует LOAD DATA операторы, вы также должны создать резервную копию любых SQL_LOAD-* файлов, которые существуют в каталоге, используемом репликой для этой цели. Реплике эти файлы необходимы для возобновления репликации любых прерванных LOAD DATA операций. Расположение этого каталога — значение системной переменной slave_load_tmpdir. Если сервер не был запущен с установленным этим параметром, расположение каталога — значение системной переменной tmpdir.

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

Если вам необходимо восстановить MyISAM поврежденные таблицы, попробуйте сначала восстановить их с помощью REPAIR TABLE или myisamchk -r. Это должно сработать в 99,9% всех случаев. Если myisamchk завершается неудачно, см. Раздел 7.6, «Управление и восстановление после сбоев таблиц MyISAM».

Создание резервных копий с помощью снимка файловой системы

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

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