Глава 13. Исполнительные соображения для MySQL Enterprise Backup

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

13.1. Оптимизация резервной работы

Эта секция описывает исполнительные соображения для поддержки базы данных с MySQL Enterprise Backup. Оптимизируя и настраивая процедуру резервного копирования, измерьте сколько времени берет резервная копия, чтобы закончить и сумму издержек на сервере базы данных. Измеряя производительность, рассмотрите:

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

После взятия полного резервного копирования последующие резервные копии могут быть выполнены более быстро, делая возрастающие резервные копии, где только измененные данные поддерживаются. Для инкрементного резервного копирования определите опцию --incremental или --incremental-with-redo-log-only, см. раздел 20.7. Для инструкций по использованию резервной копии и стадии применения возрастающих резервных копий посмотрите раздел 4.3.3.

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

Сжатие данных резервного копирования прежде, чем передать его к другому серверу включает дополнительные издержки CPU на сервере базы данных, где резервная копия происходит, но меньше сетевого движения и меньше дискового I/O на сервере, который является конечным пунктом назначения для данных резервного копирования. Рассмотрите нагрузки на своем сервере базы данных, пропускную способность вашей сети и относительные мощности базы данных и серверов назначения решая, использовать ли сжатие. Посмотрите разделы 4.3.4 и 20.6 для получения информации о создании сжатых резервных копий.

Сжатие включает компромисс между производительностью резервирования и восстановления. Резервная копия больших размеров (без сжатия) обеспечивает более быстрое восстановление, поскольку не тратит время на распаковку.

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

Как обсуждено позже, есть много причин, почему вы могли бы предпочесть работать с включенной опцией innodb_file_per_table=1.

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

mysqlbackup может использовать в своих интересах современные многоядерные CPU и потоки операционной системы, чтобы выполнить операции резервного копирования параллельно. Посмотрите раздел 20.10 для вариантов того, как управлять, сколько потоков используется для различных аспектов процесса резервного копирования. Если вы видите, что есть неиспользованный системный ресурс во время создания резервных копий, рассмотрите увеличение значений для этих вариантов и тестирование, увеличивает ли выполнение этого производительность резервирования:

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

Соображения о MyISAM

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

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

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

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

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

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

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

Дополнительно: фаза Apply-Log (только для директивных резервных копий)

Если вы храните данные резервного копирования на отдельной машине, и та машина не так занята, можно разгрузить некоторую работу постобработки (фаза apply-log), передав ее той отдельной машине.

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

13.2. Оптимизация работы восстановления

Эта секция описывает исполнительные соображения для восстановления базы данных с MySQL Enterprise Backup. Этот предмет важен потому, что:

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

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

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

Восстановление сжатой резервной копии занимает больше времени, чем восстановление несжатой резервной копии, потому что надо распаковать данные, Посмотрите раздел 20.6 для получения информации о создании сжатых резервных копий.

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

Фаза Apply-Log (только для директивных резервных копий)

См. здесь для исполнительных соображений относительно фазы apply-log.

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

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

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

mysqlbackup может использовать в своих интересах современные многоядерные CPU и потоки операционной системы, чтобы выполнить операции резервного копирования параллельно. Посмотрите раздел 20.10 для вариантов того, как управлять, сколько потоков используется для различных аспектов процесса восстановления. Если вы видите, что есть неиспользованный системный ресурс во время восстановления, рассмотрите увеличивание значений для этих вариантов и тестирование, выросла ли производительность:

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

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