9.1 Backup and Recovery Types — MySQL 9.2

9.1 Типы резервного копирования и восстановления

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

Физическое (сырое) и логическое резервное копирование

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

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

Методы физического резервного копирования обладают следующими характеристиками:

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

Методы логического резервного копирования обладают следующими характеристиками:

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

Онлайн- и офлайн- резервное копирование

Онлайн-резервное копирование выполняется во время работы сервера MySQL, чтобы информация базы данных могла быть получена с сервера. Офлайн-резервное копирование выполняется при остановленном сервере. Это различие также можно описать как “горячие” и “холодные” резервные копии; “теплые” резервные копии — это те, где сервер остается запущенным, но заблокированным для изменения данных, пока вы получаете доступ к файлам базы данных извне.

Онлайн-методы резервного копирования имеют следующие характеристики:

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

Офлайн-методы резервного копирования имеют следующие характеристики:

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

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

Локальное и удаленное резервное копирование

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

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

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

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

Полное и инкрементное резервное копирование

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

Полное и восстановление на момент времени (инкрементное)

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

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

Техническое обслуживание таблиц

Целостность данных может быть нарушена, если таблицы повреждены. Для таблиц InnoDB это не типичная проблема. Для проверки таблиц MyISAM и их восстановления в случае проблем см. InnoDB. MyISAM таблиц и их восстановление в случае проблем, см. Раздел 9.6, «Техническое обслуживание и восстановление таблиц MyISAM после сбоев».

Планирование резервного копирования, сжатие и шифрование

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