Поделиться через

Миграция локальных рабочих нагрузок MySQL в Базу данных Azure для MySQL: базовые показатели производительности

Создание базовых показателей производительности крайне важно при переносе баз данных MySQL из локальных сред в База данных Azure для MySQL. В этой статье подробно рассматривается важность базовых показателей производительности, в котором приведено подробное руководство по измерению и анализу текущей производительности базы данных. Понимая существующие метрики производительности, вы можете задать реалистичные ожидания и определить области улучшения во время процесса миграции. Это руководство поможет вам создать точные базовые показатели производительности, обеспечивая соответствие перенесенных баз данных или превышение текущих уровней производительности в среде Azure. Следует ли оптимизировать производительность запросов, повысить масштабируемость или обеспечить согласованный пользовательский интерфейс, в этой статье содержатся аналитические сведения, необходимые для достижения целей производительности.

Необходимые компоненты

Перенос локальной среды MySQL в База данных Azure для MySQL: планы тестирования

Обзор

Анализ существующей рабочей нагрузки MySQL — одно из лучших вложений, которые можно сделать для обеспечения успешной миграции. Высокая производительность системы зависит от соответствующего оборудования и хорошей архитектуры приложений. Такие элементы, как ЦП, память, диск и сеть, должны быть настроены соответствующим образом для ожидаемой загрузки. Оборудование и конфигурация являются частью уравнения производительности системы. Разработчик должен понимать принципы загрузки запросов к базе данных и знать самые дорогие запросы для выполнения. Фокус на наиболее дорогих запросах может существенно повлиять на общие метрики производительности.

Создание базовых показателей производительности запросов жизненно важно для проекта миграции. Базовые показатели производительности можно использовать для проверки конфигурации целевой зоны Azure для перенесенных рабочих нагрузок данных. Большинство систем выполняются 24/7 и имеют разные пиковые нагрузки. Важно зафиксировать пиковые нагрузки для базового уровня. Метрики собираются несколько раз. Позже в этом документе мы исследуем параметры исходного сервера и их важность для понимания общей картины базового уровня производительности. Параметры сервера не должны игнорироваться во время проекта миграции.

Инструменты

Ниже перечислены средства, используемые для сбора метрик сервера и информации о рабочей нагрузке базы данных. Используйте захваченные метрики, чтобы определить соответствующую базу данных Azure для уровня MySQL и связанные параметры масштабирования.

  • Корпоративный телеметрия MySQL: это несвободное средство корпоративного выпуска может предоставить отсортированный список самых дорогих запросов, метрик сервера, файловых операций ввода-вывода и топологии.

  • Percona Monitoring and Management (PMM). Лучшее в своем классе решение для мониторинга баз данных с открытым исходным кодом. Оно помогает снизить сложность, оптимизировать производительность и повысить безопасность критически важных для бизнеса сред баз данных независимо от расположения развертывания.

Параметры сервера

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

  • innodb_buffer_pool_size. Большое значение гарантирует, что ресурсы в памяти используются сначала перед использованием операций ввода-вывода диска. Типичные значения варьируются от 80% до 90% доступной памяти. Например, система с 8 ГБ памяти должна выделить 5–6 ГБ для размера пула.

  • innodb_log_file_size. Журналы повтора обеспечивают быструю, устойчивую запись. Такое транзакционное резервное копирование полезно во время сбоя системы. Начиная с innodb_log_file_size = 512M (предоставление 1 ГБ журналов повтора) должно дать много места для записи. В приложениях с большим объемом операций записи с использованием MySQL 5.6 и более поздних версий, следует начинать со значения innodb_log_file_size = 4G.

  • max_connections — этот параметр позволяет устранить ошибку Too many connections. По умолчанию поддерживается 151 подключение. Использование пула подключений на уровне приложения предпочтительнее, но может потребоваться увеличить конфигурацию подключения сервера.

  • innodb_file_per_table. Этот параметр сообщает InnoDB, если он должен хранить данные и индексы в общем пространстве таблиц или отдельном файле ibd для каждой таблицы. Наличие файла для каждой таблицы позволяет серверу освобождать пространство, когда таблицы удаляются, усекаются или перестраиваются. Базы данных, содержащие множество таблиц, не должны использовать таблицу для каждой конфигурации файла. Начиная с MySQL 5.6 этот параметр включен по умолчанию. В более ранних версиях базы данных следует вручную включить этот параметр конфигурации перед загрузкой данных. Этот параметр влияет только на вновь созданные таблицы.

  • innodb_flush_log_at_trx_commit: параметр по умолчанию означает, что InnoDB полностью соответствует ACID. Эта конфигурация транзакций с более низким риском может иметь значительные издержки на системы с медленными дисками из-за дополнительных синхронизаций, необходимых для очистки каждого изменения в журналах повторного входа. Установка для параметра значения "2" немного снижает надежность, так как подтвержденные транзакции будут записываться в журналы повтора только раз в секунду. Риск может быть приемлемым в некоторых основных ситуациях, и это хорошее значение для реплики. Значение 0 позволяет повысить производительность системы, но сервер базы данных похож на потерю некоторых данных во время сбоя. В нижней строке используется только значение 0 для реплики.

  • innodb_flush_method — этот параметр определяет, как записываются на диск данные и журналы. Используйте O_DIRECT при наличии аппаратного контроллера RAID с кэшем, защищенным от батареи. Используйте значение по умолчанию fdatasync в других сценариях.

  • innodb_log_buffer_size. Этот параметр — это размер буфера для транзакций, которые еще не зафиксированы. Допустимо значение по умолчанию (1 МБ). Транзакции с большими полями больших двоичных объектов и текста могут быстро заполнить буфер и активировать дополнительную нагрузку ввода-вывода. Просмотрите Innodb_log_waits переменную состояния, и если она не 0, увеличьте значение innodb_log_buffer_size.

  • query_cache_size — кэш запросов традиционно остается самым узким местом в системе при среднем уровне параллелизма. Начальное значение должно иметь значение 0, чтобы отключить кэш, например, query_cache_size = 0. Это значение по умолчанию в MySQL 5.6 и выше.

  • log_bin. Этот параметр включает двоичное ведение журнала. Ведение журнала в двоичном формате является обязательным, если сервер используется как главный сервер репликации.

  • server_id. Этот параметр является уникальным для серверов удостоверений в топологиях репликации.

  • expire_logs_days. Этот параметр определяет, сколько дней двоичные журналы будут автоматически очищаться.

  • skip_name_resolve — разрешение имени узла клиента будет выполнять пользователь. Если DNS медленно, подключение медленно. При отключении разрешения имен инструкции GRANT должны использовать только IP-адреса. Для использования IP-адреса потребуется повторно выполнить все предыдущие инструкции GRANT.

Выполните следующую команду, чтобы экспортировать параметры сервера в файл для проверки. При использовании простого синтаксического анализа выходные данные могут повторно применять те же параметры сервера после миграции при необходимости на сервер База данных Azure для MySQL. Дополнительные сведения см. в статье Настройка параметров сервера в Базе данных Azure для MySQL с помощью портала Azure.

mysql -u root -p -A -e "SHOW GLOBAL VARIABLES;" > settings.txt

Параметры сервера, устанавливаемые по умолчанию в MySQL 5.5.60, см. в приложении.

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

Список параметров сервера, которые не могут быть настроены, ссылаются на неконфигурируемые параметры сервера.

Исходящий и входящий трафик

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

Просмотрите параметры времени ожидания, которые могут повлиять на наборы данных. Например:

Кроме того, просмотрите все параметры, влияющие на максимальные значения:

Примечание.

При миграции часто встречается ошибка MySQL server has gone away. Указанные здесь параметры часто становятся ее причиной, и их настройка обычно позволяет ее устранить.

Сценарий WWI

WWI рассмотрела рабочую нагрузку базы данных конференции и определила, что она имеет небольшую нагрузку. Хотя сервер уровня "базовый" будет работать для них, они не хотели выполнять работу позже, чтобы перейти на другой уровень. Развернутый сервер в конечном итоге будет размещать другие рабочие нагрузки данных MySQL, поэтому они выбрали General Performance уровень.

При проверке базы данных MySQL я обнаружил, что сервер MySQL 5.5 выполняется с параметрами сервера по умолчанию, заданными во время начальной установки.

Следующий шаг

Перенос локальной среды MySQL в База данных Azure для MySQL: миграция данных

  • Last updated on