11.1 Optimizing Backup Performance — MySQL Enterprise Backup 4.1

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

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

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

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

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

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

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

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

Резервные копии в одном файле

Резервное копирование в одном файле само по себе не обязательно быстрее, чем традиционный тип резервного копирования, создающий древовидную структуру выходных файлов. Его преимущество в производительности обусловлено объединением различных этапов, которые вы, возможно, должны выполнять последовательно, таких как объединение данных резервной копии в один выходной файл и их передача на другой сервер. См. Раздел 15.5, «Другие операции резервного копирования в одном файле» для параметров резервного копирования в одном файле и Раздел 4.3.1, «Создание резервной копии в одном файле» для инструкций по использованию.

Параметры конфигурации InnoDB

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

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

mysqlbackup может использовать современные многоядерные ЦП и потоки операционной системы для выполнения операций резервного копирования параллельно. См. Раздел 16.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 и файлы .frm), база данных временно переводится в состояние только для чтения с использованием оператора FLUSH TABLES WITH READ LOCK. Для достижения наилучшей производительности резервного копирования и минимального влияния на обработку базы данных:
1. Не запускайте длительные SELECT запросы или другие SQL-запросы во время выполнения резервного копирования.
2. Сохраняйте таблицы MyISAM относительно небольшими и используйте их в основном для чтения или чтения в основном.
Тогда завершающая фаза блокировки после выполнения mysqlbackup будет короткой (возможно, несколько секунд) и не сильно повлияет на обычную обработку mysqld. Если в вашей базе данных не выполнены вышеуказанные условия, используйте параметр --only-innodb или --only-innodb-with-frm для резервного копирования только таблиц InnoDB или используйте параметр --no-locking для резервного копирования файлов, отличных от InnoDB. Обратите внимание, что таблицы MyISAM, .frm и другие файлы, скопированные при значении --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 получает информацию о параметрах базы данных через подключение к базе данных, но не данные о таблицах или индексах.

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

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

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

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

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

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

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

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

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