13.1 Optimizing Backup Performance — MySQL Enterprise Backup 9.2

13.1 Оптимизация производительности резервного копирования

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

Ограничения, налагаемые процедурами резервного копирования. Например, если вы делаете резервное копирование каждые 8 часов, резервное копирование должно выполняться менее 8 часов.
Ограничения, налагаемые вашей сетевой и хранилищной инфраструктурой. Например, если вам нужно поместить много резервных копий на определенное хранилище, вы можете использовать сжатые резервные копии, даже если это замедлит процесс резервного копирования.
Компромисс между временем резервного копирования и временем восстановления. Вы можете выбрать набор параметров, который приведет к немного более медленному резервному копированию, если эти параметры позволят значительно ускорить восстановление. Сведения о производительности процесса восстановления см. в разделе 13.2, «Оптимизация производительности восстановления».

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

После создания полной резервной копии последующие резервные копии можно создать быстрее, выполнив инкрементное резервное копирование, где копируются только измененные данные. Для инкрементного резервного копирования укажите параметр --incremental или --incremental-with-redo-log-only для команды mysqlbackup. Сведения об этих параметрах см. в разделе 20.7, «Параметры инкрементного резервного копирования». Инструкции по использованию этапов резервного копирования и применения инкрементных резервных копий см. в разделе 4.3.3, «Создание дифференциального или инкрементного резервного копирования».

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

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

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

Настройки параметров конфигурации InnoDB

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

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

mysqlbackup может использовать современные многоядерные процессоры и потоки операционной системы для выполнения операций резервного копирования параллельно. Сведения о параметрах управления количеством потоков для различных аспектов процесса резервного копирования см. в разделе 20.10, «Параметры производительности/масштабируемости/емкости». Если вы обнаружите, что во время резервного копирования есть неиспользованные ресурсы системы, попробуйте увеличить значения этих параметров и протестировать, улучшится ли производительность резервного копирования:

При настройке и тестировании производительности резервного копирования с использованием конфигурации RAID хранилища рассмотрите сочетание параметров --read-threads=3 --process-threads=6 --write-threads=3. Сравните с сочетанием --read-threads=1 --process-threads=6 --write-threads=1.
При настройке и тестировании производительности резервного копирования с использованием конфигурации хранилища без RAID рассмотрите сочетание параметров --read-threads=1 --process-threads=6 --write-threads=1.
При увеличении значений любого из трех параметров «“потоков”» также увеличьте значение параметра --limit-memory, чтобы предоставить дополнительным потокам достаточно памяти для работы.
Если ЦП не слишком загружен (менее 80% загрузки ЦП), увеличьте значение параметра --process-threads.
Если устройство хранения, с которого вы выполняете резервное копирование (исходный диск), может обрабатывать больше запросов ввода-вывода, увеличьте значение параметра --read-threads.
Если устройство хранения, на которое вы выполняете резервное копирование (диск назначения), может обрабатывать больше запросов ввода-вывода, увеличьте значение параметра --write-threads (не относится к резервным копиям одного файла, которые всегда используют один поток записи).

В зависимости от вашей операционной системы вы можете измерить использование ресурсов с помощью таких команд, как top, iostat, sar, dtrace или графического монитора производительности. Не увеличивайте количество потоков чтения или записи, пока значение системы iowait не достигнет примерно 20%.

Соображения по MyISAM

Важно

Хотя mysqlbackup создает резервные копии таблиц InnoDB без прерывания использования базы данных, конечный этап, который копирует файлы, не относящиеся к InnoDB (такие как таблицы MyISAM и .sdi файлы), временно переводит эти таблицы в состояние только для чтения, используя оператор FLUSH TABLES tbl_name [, tbl_name] ... WITH READ LOCK. Для достижения наилучшей производительности резервного копирования и минимального влияния на обработку базы данных:
1. Не запускайте длинных , , или запросов во время выполнения резервного копирования.
2. Поддерживайте таблицы MyISAM относительно небольшими и используйте их в основном для чтения или для задач, где чтение преобладает над записью.
Тогда время блокировки таблиц MyISAM будет коротким, и нормальная обработка mysqld будет практически не нарушена. Если перечисленные условия не выполняются в вашем приложении базы данных, используйте параметр --only-innodb для резервного копирования только таблиц InnoDB или параметр --no-locking. Обратите внимание, что файлы, скопированные с использованием настройки --no-locking, не гарантируют непротиворечивость данных.
На большом сервере базы данных процесс резервного копирования может занять много времени. Всегда проверяйте, что mysqlbackup завершился успешно, либо убедитесь, что mysqlbackup возвращает код выхода 0, либо проверьте, что mysqlbackup напечатал текст “mysqlbackup completed OK!”.
Планируйте резервное копирование в периоды, когда не выполняются операции DDL, связанные с таблицами. Сведения о ограничениях резервного копирования одновременно с операциями DDL см. в приложении Приложение B, Ограничения MySQL Enterprise Backup.

Производительность сети

Для операций обработки данных, возможно, вы знаете стандартное рекомендации, что сокеты Unix быстрее, чем TCP/IP для связи с сервером базы данных. Хотя команда mysqlbackup поддерживает параметры --protocol=tcp, --protocol=socket и --protocol=pipe, эти параметры не оказывают существенного влияния на производительность резервного копирования или восстановления. Эти процессы включают в себя операции копирования файлов, а не трафик клиент/сервер по сети. Связь с сервером базы данных, управляемая параметром --protocol, имеет небольшой объем. Например, mysqlbackup получает информацию о параметрах сервера базы данных через подключение к серверу базы данных, но не данные о таблицах или индексах.

Размер данных

Если некоторые таблицы или базы данных содержат некритическую информацию или обновляются редко, вы можете исключить их из частых резервных копий и резервировать их реже. Сведения о соответствующих параметрах см. в разделе 20.8, «Параметры частичного резервного копирования и восстановления», а инструкции по исключению данных из определенных таблиц, баз данных или движков хранилища см. в разделе 4.3.5, «Создание частичного резервного копирования». Частичные резервные копии быстрее, потому что копируют, сжимают и передают меньший объем данных.

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

Это предотвращает раздувание табличного пространства InnoDB системы, выделяя дисковое пространство, которое впоследствии может использоваться только MySQL. Например, иногда огромные объёмы данных необходимы только временно или загружаются по ошибке или во время экспериментов. Без этого параметра системное табличное пространство расширяется, чтобы вместить все эти данные, и никогда после этого не уменьшается.
Оно немедленно освобождает дисковое пространство, занимаемое таблицей InnoDB и её индексами, когда таблица удаляется или обрезается. Каждая таблица и её связанные индексы представлены объектом, который удаляется или очищается этими операциями DDL.
Оно позволяет повторно использовать неиспользуемое пространство в файле .ibd с помощью оператора, когда удаляются существенные объемы данных или падают индексы.
Оно позволяет выполнять частичные резервные копии, где вы создаёте резервную копию некоторых таблиц InnoDB, а не других, как обсуждается в Разделе 4.3.5, «Создание частичной резервной копии».
Оно позволяет использовать сжатие таблиц для таблиц InnoDB.

В общем случае, использование сжатия таблиц, имея ROW_FORMAT=COMPRESSED, уменьшает размер таблиц и увеличивает производительность резервного копирования и восстановления. Однако в качестве компромисса сжатие таблиц может потенциально увеличить размер журнала redo и, следовательно, замедлить создание инкрементных резервных копий и восстановление, а также операции apply-log. См. для получения подробной информации.

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

Расширенное: Фаза применения журнала (только для резервного копирования каталога)

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

Всегда существует компромисс в производительности между выполнением фазы применения журнала сразу после первоначального резервного копирования (что делает восстановление быстрее) или откладыванием её до непосредственной подготовки к восстановлению (что делает резервное копирование быстрее). В случае чрезвычайной ситуации производительность восстановления является самым важным фактором. Таким образом, чем важнее данные, тем важнее выполнить фазу применения журнала сразу после резервного копирования. Либо объедините фазы резервного копирования и применения журнала на одном сервере, указав параметр backup-and-apply-log, либо выполните быстрое начальное резервное копирование, передайте данные резервной копии на другой сервер, а затем выполните фазу применения журнала, используя один из вариантов из Операции применения журнала.