7.1 Backup and Recovery Types — MySQL 5.7

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

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

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

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

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

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

Резервное копирование состоит из точных копий каталогов и файлов базы данных. Обычно это копия всего или части каталога данных MySQL.
Методы физического резервного копирования быстрее, чем логические, так как они включают только копирование файлов без преобразования.
Выходные данные более компактны, чем при логическом резервном копировании.
Поскольку скорость и компактность резервного копирования важны для загруженных и важных баз данных, продукт MySQL Enterprise Backup выполняет физическое резервное копирование. Обзор продукта MySQL Enterprise Backup см. в Раздел 28.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 и их восстановления в случае проблем, см. Раздел 7.6, «Техническое обслуживание и восстановление после сбоя таблиц MyISAM».

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

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