1.2 Overview of Backup Types — MySQL Enterprise Backup 4.1

1.2 Обзор типов резервного копирования

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

Типы резервных копий в зависимости от уровня нарушения обслуживания

В зависимости от того, как операции базы данных будут нарушены во время резервного копирования, резервное копирование классифицируется как «горячее», «теплое» или «холодное»:

Очень низкий или низкий уровень нарушения: Горячее резервное копирование выполняется при работе базы данных. Этот тип резервных копий не блокирует обычные операции базы данных. Он фиксирует даже изменения, происходящие во время выполнения резервного копирования. По сравнению с другими типами резервных копий, он вызывает наименьшее нарушение работы сервера базы данных, и это желательный вариант резервного копирования, когда вы хотите избежать отключения вашего приложения, веб-сайта или веб-сервиса. Однако перед восстановлением горячего резервного копирования необходимо выполнить дополнительный процесс подготовки резервной копии, чтобы сделать ее согласованной (т. е. правильно отражающей состояние базы данных в момент завершения резервного копирования). Более подробные объяснения см. в разделе Раздел 5.1.7 «Дополнительные сведения: Подготовка и восстановление резервной копии каталога».

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

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

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

Типы резервных копий в зависимости от того, резервируются ли все данные или только последние изменения

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

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

Сжатые и несжатые резервные копии

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

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

Более подробные сведения о методах и компромиссах, связанных с производительностью резервного копирования и восстановления, см. в Главе 11 «Учет производительности MySQL Enterprise Backup».