Определение потребностей масштабирования сервера База данных Azure для MySQL

Завершено

Когда речь идет о размерах вычислительных ресурсов, рассмотрите возможность наличия и прогнозируемого использования в пределах емкости. Вы можете получить необходимые сведения, отслеживая базовые метрики производительности, такие как использование ЦП и ОЗУ. Возможно, можно использовать журнал медленных запросов для выявления и оптимизации плохо выполняемых запросов и устранения проблемы с производительностью без масштабирования размера вычислительных ресурсов. Вы также должны отслеживать производительность ввода-вывода, чтобы убедиться, что операции чтения и записи базы данных не являются узким местом производительности. Другим вариантом эффективного увеличения доступной емкости в основной базе данных является подготовка реплики чтения для смены нагрузки запросов.

Мониторинг метрик производительности базы данных

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

Снимок экрана: метрики, показывающие использование ЦП.

Так как загрузка ЦП почти на 100%, производительность базы данных значительно снижается. В результате, если использование ЦП на гибком сервере постоянно превышает 50%, рассмотрите возможность увеличения размера вычислительных ресурсов.

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

  1. В портал Azure на левой панели в разделе "Мониторинг для База данных Azure для MySQL гибкий экземпляр сервера" выберите книги.

    Снимок экрана: раздел мониторинга с списком книг.

  2. Выберите книгу обзора. Вы увидите графики, показывающие подключения, использование ЦП и памяти, а также другие метрики, как показано на следующем снимке экрана.

    Снимок экрана: книга обзора мониторинга.

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

Снимок экрана: панель журналов с селектором запросов.

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

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

Снимок экрана: страница портал Azure для включения журналов сервера медленных запросов.

После включения ведения журнала медленных запросов можно просмотреть аналитические сведения о производительности запросов с помощью log analytics или книг визуализации. Чтобы получить доступ к аналитическим сведениям о производительности запросов, выполните те же действия, что и выше, но выберите " Аналитика производительности запросов" вместо "Обзор".

Вы увидите несколько визуализаций, включая пять самых длинных запросов или сводку медленных запросов, как показано на следующем снимке экрана.

Снимок экрана: пять самых длинных запросов и сводка медленных запросов.

Настройка параметров производительности сервера

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

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

Чтобы изменить параметры сервера, перейдите к портал Azure гибкого сервера MySQL и перейдите к разделу "Параметры сервера". Введите имя параметра в строку поиска или просмотрите параметры сервера верхнего или всех поддерживаемых.

Изучение и включение функции автомасштабирования операций ввода-вывода в секунду

База данных Azure для MySQL имеет два способа выделения емкости операций ввода-вывода на диск: предварительно подготовленных и автомасштабированных операций ввода-вывода (операции ввода-вывода в секунду).

Предварительно подготовленные операции ввода-вывода в секунду могут быть предпочтительнее, если загрузка базы данных предсказуема и не пиковая. Сервер получает базовое число подготовленных операций ввода-вывода в секунду, и вы можете выделить дополнительные операции ввода-вывода в секунду (до максимального размера вычислительных ресурсов), перейдя в службу вычислений и хранилища:

Снимок экрана: панель параметров для добавления дополнительных предварительно подготовленных операций ввода-вывода в секунду.

Если возникает пик, производительность сервера может временно снизиться, если операции ввода-вывода превышают выделенное значение. Однако емкость и затраты прогнозируются.

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

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

Снимок экрана: параметры создания для автомасштабирования операций ввода-вывода в секунду.

Примечание.

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

Мониторинг операций ввода-вывода в секунду

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

Чтобы отслеживать производительность операций ввода-вывода в секунду, перейдите в колонку "Метрики " в разделе "Мониторинг " или в колонку "Обзор ", если вы хотите просмотреть производительность операций ввода-вывода в секунду вместе с другими общими метриками.

Снимок экрана: мониторинг колонки обзора.

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

Подготовка реплики чтения

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

Чтобы подготовить реплику чтения, в портал Azure на странице, связанной с гибким сервером, выберите "Репликация" и нажмите кнопку "Добавить реплику".

Снимок экрана: кнопка добавления реплики.

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

Снимок экрана: добавление реплики.

В Wingtip Toys команда по обработке и анализу данных и средства отчетности теперь могут запрашивать сервер реплик чтения, уменьшая нагрузку на базу данных основного приложения и удаляя необходимость регулирования аналитики или ограничения запросов в нерабочее время.