9.1 Backup and Recovery Types — MySQL 8.4

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, а удаленное резервное копирование выполняется с другого хоста. Для некоторых типов резервных копий резервное копирование может быть инициировано с удаленного хоста, даже если вывод записывается локально на сервере. host.

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

Резервные копии-снимки

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

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

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

Полное и восстановление по состоянию на определенный момент времени (инкрементное)

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

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

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

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

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

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