1.2 Overview of Backup Types — MySQL Enterprise Backup 9.2

1.2 Обзор типов резервных копий

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

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

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

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

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

При подключении к работающему серверу MySQL MySQL Enterprise Backup создаёт резервные копии всех таблиц MyISAM и других таблиц, не являющихся InnoDB, используя метод «теплое резервное копирование» после того, как все таблицы InnoDB уже были скопированы с помощью метода «горячее резервное копирование». Поэтому для резервного копирования максимального количества данных во время фазы горячего резервного копирования рекомендуется назначить InnoDB в качестве стандартного движка хранения для новых таблиц (что является стандартным значением для серверов MySQL) или преобразовать существующие таблицы в использование движка хранения InnoDB.
Высокий или очень высокий уровень прерывания: Резервная копия создаётся при остановленной базе данных. Это очень сильно прерывает работу службы базы данных. MySQL Enterprise Backup 9.2 не поддерживает это.

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

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

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

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

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

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

Дополнительную информацию о методах и компромиссах, связанных с производительностью резервного копирования и восстановления, см. в главе 13 «Учет производительности для MySQL Enterprise Backup».