WebMoney:  WMZ Z294115950220  WMR R409981405661  WME E134003968233	Visa  4274 3200 2453 6495

Глава 13. Исполнительные соображения для MySQL Enterprise Backup В этой главе описываются исполнительные соображения для поддержки и восстановления баз данных с использованием MySQL Enterprise Backup. 13.1. Оптимизация резервной работы Эта секция описывает исполнительные соображения для поддержки базы данных с MySQL Enterprise Backup. Оптимизируя и настраивая процедуру резервного копирования, измерьте сколько времени берет резервная копия, чтобы закончить и сумму издержек на сервере базы данных. Измеряя производительность, рассмотрите: Ограничения, наложенные вашими процедурами резервного копирования. Например, если вы берете резервную копию каждые 8 часов, резервная копия должна занять меньше, чем 8 часов, чтобы закончиться. Ограничения, наложенные вашей сетевой и инфраструктурой хранения. Например, если необходимо соответствовать многим резервным копиям на конкретном устройстве хранения данных, вы могли бы использовать сжатые резервные копии, даже если бы это сделало процесс резервного копирования медленнее. Компромисс между временем резервного копирования и восстановления. Вы могли бы выбрать ряд вариантов, приводящих к немного более медленной резервной копии, если те варианты позволяют восстанавливать намного быстрее. Посмотрите раздел 13.2 для получения информации о работе процесса восстановления. Полное резервное копирование или инкрементное резервное копирование После взятия полного резервного копирования последующие резервные копии могут быть выполнены более быстро, делая возрастающие резервные копии, где только измененные данные поддерживаются. Для инкрементного резервного копирования определите опцию --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 для вариантов того, как управлять, сколько потоков используется для различных аспектов процесса резервного копирования. Если вы видите, что есть неиспользованный системный ресурс во время создания резервных копий, рассмотрите увеличение значений для этих вариантов и тестирование, увеличивает ли выполнение этого производительность резервирования: Настраивая и проверяя резервную работу, используя конфигурацию хранения 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 опций threads, также увеличьте значение опции --limit-memory , чтобы дать дополнительным потокам достаточно памяти, чтобы сделать их работу. Если CPU не слишком занят (меньше чем 80%), увеличьте значение опции --process-threads. Если устройство хранения данных, с которого вы резервируете может обработать больше запросов I/O, стоит увеличить значение --read-threads . Если устройство хранения данных, на которое вы пишете может обработать больше запросов I/O, стоит увеличить значение value of the --write-threads. В зависимости от вашей операционной системы можно измерить использование ресурса такими командами, как top, iostat, sar, dtrace или применив графический монитор производительности. Не увеличивайте число потоков чтения или записи iowait, когда системное значение iowait достигает приблизительно 20%. Соображения о MyISAM Хотя mysqlbackup поддерживает таблицы InnoDB не прерывая использование базы данных, заключительный этап, который копирует не-InnoDB файлы (такие как таблицы MyISAM и файлы .sdi) временно помещает те таблицы в состояние только для чтения, используя запрос FLUSH TABLES tbl_name [, tbl_name] ... WITH READ LOCK. Для лучшей резервной работы и минимального воздействия на обработку базы данных: Не выполняйте длительные запросы INSERT, UPDATE или DELETE во время резервного копирования. Сохраняйте свои таблицы MyISAM относительно маленькими и прежде всего для только для чтения или главным образом для чтения. Тогда время, когда не-InnoDB таблицы заблокированы для чтения, будет коротким, а нормальная обработка mysqld будет не очень нарушена. Если предыдущие условия не соблюдаются в вашем приложении базы данных, используйте опцию --only-innodb, чтобы поддержать только таблицы InnoDB или попробуйте использовать --no-locking. Обратите внимание на то, что файлы скопированные при --no-locking не будут гарантировать последовательных данных. Для большой базы данных резервное копирование могло бы занять много времени. Всегда проверяйте, что mysqlbackup закончил успешно, проверяя код возврата 0 или что mysqlbackup вывел текст mysqlbackup completed OK!. Делайте копию по графику в периоды, когда никакие операции DDL, включающие таблицы, не выполняются, см. приложение B для ограничений на резервные копии в то же время, что и операции DDL. Производительность сети Для операций по обработке данных вы могли бы знать обычный совет, что сокеты Unix быстрее, чем TCP/IP для связи с базой данных. Хотя команда mysqlbackup поддерживает варианты --protocol=tcp, --protocol=socket и --protocol=pipe, они не имеют значительного эффекта на резервную копию или восстановление. Эти процессы включают операции копирования файла, а не сетевой трафик клиент-сервер. Коммуникация базы данных, которой управляет опция --protocol, низкоуровневая. Например, mysqlbackup получает информацию о параметрах базы данных посредством соединения с базой данных, но не данные об индексе или таблице. Размер данных Если определенные таблицы или базы данных содержат некритическую информацию или редко обновляются, можно убрать их из самых частых резервных копий и поддержать их по менее частому графику. Посмотрите раздел 20.8 для получения информации о соответствующих вариантах и раздел 4.3.5 для инструкций об игнорировании данных из определенных таблиц, баз данных или механизмов хранения. Частичные резервные копии быстрее, потому что они копируют, сжимают и передают меньший объем данных. Чтобы минимизировать полный размер файлов данных InnoDB, рассмотрите предоставление возможности параметра конфигурации MySQL innodb_file_per_table. Этот выбор может минимизировать размер данных для таблиц InnoDB несколькими способами: Это не дает системному табличному пространству InnoDB вырастать в размере, ассигнуя дисковое пространство, которое может впоследствии только использоваться MySQL. Например, иногда огромные объемы данных необходимы только временно или загружаются по ошибке или во время экспериментирования. Без опции innodb_file_per_table системное табличное пространство расширяется, чтобы сохранить все эти данные, и никогда не сжимается позже. Это немедленно освобождает дисковое пространство, занятое таблицей InnoDB и индексами, когда таблица удалена или усечена. Каждая таблица и связанные индексы представляются файлом .ibd, который удален или освобожден этими операциями DDL. Это предоставляет неиспользуемое пространство в файле .ibd, которое будет очищено OPTIMIZE TABLE, когда значительное количество данных удалено или удалены индексы. Это позволяет частичные резервные копии, где вы поддерживаете некоторые таблицы InnoDB, но не все, как обсуждено в разделе 4.3.5. Это позволяет использование сжатия для таблиц 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. Этот предмет важен потому, что: Восстановление это фаза цикла резервирования-восстановления, который имеет тенденцию существенно варьироваться между различными резервными методами. Например, резервная работа могла бы быть приемлемым использованием mysqldump, но mysqldump, как правило, работает намного дольше, чем MySQL Enterprise Backup при восстановлении. Восстановление часто выполняется во время чрезвычайной ситуации, где очень важно минимизировать время простоя приложения или веб-сайта. Восстановление (за исключением табличного уровня восстановления) всегда выполняется с закрытием сервера базы данных. Восстановление главным образом зависит от соображений низкого уровня, таких как I/O и сетевая скорость для передачи файлов, скорости CPU, ядер процессора и так далее. Для комбинации вариантов, которые можно определить для задачи восстановления, см. раздел 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 для вариантов того, как управлять, сколько потоков используется для различных аспектов процесса восстановления. Если вы видите, что есть неиспользованный системный ресурс во время восстановления, рассмотрите увеличивание значений для этих вариантов и тестирование, выросла ли производительность: Настраивая и проверяя работу, используя конфигурацию хранения 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 опций threads, также увеличиваете значение опции --limit-memory , чтобы дать дополнительным потокам достаточно памяти, чтобы сделать их работу. Если CPU не слишком занят (меньше чем 80%), увеличьте значение --process-threads. Если устройство хранения данных, с которого вы восстанавливаете может обработать больше запросов I/O, имет смысл увеличить --read-threads . Если устройство хранения данных, на которое вы восстанавливаете может обработать больше запросов I/O, стоит увеличить значение --write-threads. Для фазы apply-log operation опция --process-threads управляет количеством потоков, которые читают и пишут измененные страницы файла данных параллельно, эти потоки обычно ограничены I/O даже при том, что они также выполняют некоторую обработку в памяти. В зависимости от вашей операционной системы можно измерить использование ресурса такими командами, как top, iostat, sar, dtrace или применив графический монитор производительности. Не увеличивайте число потоков чтения или записи iowait, когда системное значение iowait достигает приблизительно 20%.

Поиск На сайте В Яндексе

Вы можете направить письмо администратору этой странички, Алексею Паутову.