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

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

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

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

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

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

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

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

FLUSH TABLES tbl_list WITH READ LOCK;

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

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

Пример этого метода резервного копирования см. в примере экспорта и импорта в Разделе 15.2.6, «Оператор IMPORT TABLE».

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

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

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

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

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

MySQL поддерживает инкрементные резервные копии с помощью двоичного журнала. Файлы двоичного журнала предоставляют информацию, необходимую для репликации изменений в базе данных, внесенных после момента создания резервной копии. Таким образом, для восстановления сервера до определенного момента во времени необходимо включить двоичное протоколирование, что является значением по умолчанию для MySQL 9.2; см. Раздел 7.4.4, «Двоичный журнал».

В момент, когда вы хотите создать инкрементную резервную копию (содержащую все изменения, произошедшие с момента последней полной или инкрементной резервной копии), вам следует переключить двоичный журнал, используя FLUSH LOGS. После этого необходимо скопировать на место резервной копии все двоичные журналы, начиная с журнала на момент последней полной или инкрементной резервной копии и до предпоследнего. Эти двоичные журналы и есть инкрементная резервная копия; при восстановлении их применяют, как описано в Разделе 9.5, «Восстановление до определенного момента (инкрементное)». В следующий раз, когда вы делаете полное резервное копирование, вы также должны переключить двоичный журнал, используя FLUSH LOGS или mysqldump --flush-logs. См. Раздел 6.5.4, «mysqldump — Программа резервного копирования базы данных».

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

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

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

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

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

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

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

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