13.1 Optimizing Backup Performance — MySQL Enterprise Backup 8.4

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.
При увеличении значений любого из 3 параметров «“потоки”» также увеличьте значение параметра --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, связанные с таблицами. См. Приложение B, Ограничения MySQL Enterprise Backup для ограничений на резервное копирование одновременно с операциями DDL.

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

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