Перенос локальных рабочих нагрузок MySQL в Базу данных Azure для MySQL — оптимизация
Оптимизация баз данных MySQL после миграции из локальных сред в База данных Azure для MySQL необходима для повышения производительности и эффективности. В этой статье рассматриваются основные стратегии и рекомендации по оптимизации баз данных в среде Azure. Вы можете убедиться, что базы данных работают в их пиковом потенциале, фокусируясь на производительности запросов, индексировании, выделении ресурсов и настройке конфигурации. В этом руководстве содержатся аналитические сведения и методы, необходимые для выявления и устранения узких мест производительности, использования расширенных функций Azure и достижения оптимальной производительности базы данных. Независимо от того, стремитесь ли вы повысить время отклика, повысить масштабируемость или сократить эксплуатационные затраты, эта статья поможет вам использовать знания для оптимизации баз данных MySQL в Azure.
Необходимые компоненты
Перенос локальной среды MySQL в База данных Azure для MySQL: управление миграцией после миграции
Мониторинг производительности оборудования и запросов
Помимо журналов аудита и действий, производительность сервера можно также отслеживать с помощью метрик Azure. Метрики Azure предоставляются с частотой в одну минуту, и на их основе можно настроить оповещения. Дополнительные сведения о видах отслеживаемых метрик см. в статье Мониторинг в базе данных Azure для MySQL.
Как упоминалось ранее, при принятии решения об обновлении уровня базы данных может быть важно отслеживать такие метрики, как cpu_percent или memory_percent. Постоянно высокие значения могут означать необходимость перехода на другую категорию.
Кроме того, если значения загрузки ЦП или использования памяти не представляют проблему, администраторы могут исследовать параметры на основе базы данных, такие как индексирование и изменения запросов, для запросов с низкой производительностью.
Чтобы определить запросы с низкой производительностью, выполните следующую команду:
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.DBFORMYSQL"
| where Category == 'MySqlSlowLogs'
| project TimeGenerated, LogicalServerName\_s,
event\_class\_s, start\_time\_t , q uery\_time\_d,
sql\_text\_s| top 5 by query\_time\_d desc
Анализ производительности процессов
В дополнение к основным аспектам мониторинга сервера Azure предоставляет средства для мониторинга производительности запросов приложений. Исправление или улучшение запросов может привести к значительному увеличению их пропускной способности. С помощью средства анализа производительности запросов можно анализировать самые длительные запросы и определять возможность кэширования этих элементов, если они детерминированы в течение заданного периода, или изменять запросы для повышения производительности.
Для отображения медленных запросов в файлах журнала MySQL можно задать параметр slow\_query\_log (по умолчанию параметр отключен). Параметр сервера long\_query\_time может оповещать пользователей о длительных запросах (значение по умолчанию — 10 секунд).
Обновление уровня
Портал Azure можно использовать для масштабирования между категориями General Purpose и Memory Optimized. Basic Если выбран уровень, нет возможности обновить уровень до General Purpose более Memory Optimized поздней версии. Однако существуют другие способы миграции или перехода на новый экземпляр Базы данных Azure для MySQL.
Пример скрипта для перехода с цен. категории "Базовый" на сервер другой категории см. в статье о переходе с цен. категории "Базовый" на категории "Общего назначения" или "Оптимизированная для операций в памяти" в Базе данных Azure для MySQL.
Масштабирование сервера
В рамках категории можно масштабировать ядра и память до минимального и максимального допустимых предельных значений. Если мониторинг показывает постоянное максимальное использование процессора или памяти, выполните действия по вертикальному увеличению масштаба в соответствии с имеющимися потребностями.
Перемещение регионов
Перемещение базы данных в другой регион Azure зависит от подхода и архитектуры. Определенный подход может привести к простою системы.
Рекомендуемый процесс аналогичен использованию реплик чтения для отработки отказа обслуживания. Однако по сравнению с описанным выше методом планового обслуживания скорость отработки отказа ускоряется при реализации уровня отработки отказа в приложении. Во время процесса отработки отказа реплики чтения приложение должно простаивать всего несколько мгновений. Дополнительные сведения см. в разделе о непрерывности бизнес-процессов и аварийном восстановлении.
Сценарий WWI
Бизнес-пользователи и пользователи приложений компании WWI с большим воодушевлением отнеслись к возможности масштабирования базы данных по требованию. Они были также заинтересованы в использовании анализа производительности запросов для определения необходимости решения проблем с производительностью длительных запросов.
Было решено использовать сервер реплики чтения для любых возможных сценариев отработки отказа или сценариев только для чтения.
Команда по миграции, работающая с инженерами Azure, настроила запросы KQL для отслеживания потенциальных проблем, связанных с производительностью сервера MySQL. Запросы KQL были настроены с оповещениями для отправки сообщений о событиях в базу данных и команде по работе с конференциями.
Компания решила пока отслеживать любые потенциальные проблемы и позже, если потребуется, внедрить модули runbook службы автоматизации Azure для повышения эффективности работы.
Контрольный список оптимизации
Отслеживайте медленные запросы.
Периодически просматривайте данные на панели мониторинга "Аналитика производительности".
Используйте мониторинг для принятия решений по масштабированию и переходу на другую категорию.
Рассмотрите возможность перемещения требующих изменений регионов пользователей или приложений.