13.2 Optimizing Restore Performance — MySQL Enterprise Backup 8.4

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

В этом разделе рассматриваются аспекты производительности при восстановлении сервера базы данных с помощью MySQL Enterprise Backup. Данная тема важна по следующим причинам:

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

Для комбинации параметров, которые можно указать для задания восстановления, см. раздел 19.3 «Операции восстановления».

Восстановление данных разных типов резервных копий

Восстановление частичной резервной копии занимает меньше времени, чем восстановление полной резервной копии, поскольку для физического копирования данных требуется меньше времени. Подробнее о частичных резервных копиях см. раздел 4.3.5 «Создание частичной резервной копии».

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

Процесс распаковки для восстановления резервной копии в виде одного файла, как правило, не является затратным ни с точки зрения скорости, ни с точки зрения дополнительного хранилища. Каждый файл распаковывается непосредственно в свое конечное место назначения, как если бы он копировался индивидуально. Таким образом, если вы можете существенно ускорить резервное копирование или уменьшить его требования к хранилищу, используя резервные копии в виде одного файла, это обычно не влечет за собой компромиссов с временем восстановления. Подробности о создании резервных копий в виде одного файла см. в разделе 19.5 «Другие операции резервного копирования в виде одного файла».

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

См. раздел «Дополнительная информация: фаза применения журнала (только для резервных копий каталогов)» для рекомендаций по производительности, связанных с фазой применения журнала.

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

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

Параллельное восстановление

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.

Для операции применения журнала параметр --process-threads управляет количеством потоков, которые параллельно читают и записывают страницы файлов измененных данных; эти потоки обычно ограничены вводом/выводом, хотя они также выполняют некоторую обработку в памяти.

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