11.2 Optimizing Restore Performance — MySQL Enterprise Backup 4.1

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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