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.При увеличении значений любых из 3 параметров “потоков” также увеличьте значение параметра
--limit-memory, чтобы предоставить дополнительным потокам достаточную память для их работы.Если ЦП не слишком загружен (менее 80% загрузки ЦП), увеличьте значение параметра
--process-threads.Если устройство хранения, из которого вы восстанавливаете (исходный диск), может обработать больше запросов ввода-вывода, увеличьте значение параметра
--read-threads(не относится к восстановлению резервных копий в формате одного файла, которые всегда используют один поток чтения).Если устройство хранения, на которое вы восстанавливаете (диск назначения), может обработать больше запросов ввода-вывода, увеличьте значение параметра
--write-threads.
Для операции применения журнала параметр --process-threads управляет количеством потоков, которые читают и записывают измененные страницы файлов данных параллельно; эти потоки обычно ограничены вводом-выводом, даже если они также выполняют некоторую обработку в памяти.
В зависимости от вашей операционной системы, вы можете измерить использование ресурсов с помощью команд, таких как top, iostat, sar, dtrace или графического монитора производительности. Не увеличивайте число потоков чтения или записи iowait, пока значение системы iowait не достигнет примерно 20%.
© 2025 Oracle
Licensed under the GPLv2 License.
