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

Создание горячей резервной копии с помощью 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 Statement».

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

Пример этого метода резервного копирования см. в примере экспорта и импорта в разделе 15.2.6 «Управление импортом данных».

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

Чтобы создать текстовый файл с данными таблицы, можно использовать 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 8.4; см. раздел 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.