База данных Azure для MySQL — функции производительности гибкого сервера
Вы можете создавать гибкие серверы База данных Azure для MySQL на основе одного из трех уровней служб: с возможностью ускорения, общего назначения и критически важный для бизнеса. Уровни служб обеспечивают увеличение размера вычислительных ресурсов и хранилища, а также поддерживаемое количество максимальных подключений и операций ввода-вывода в секунду (IOPS). Один гибкий сервер MySQL может размещать несколько баз данных. Вы можете отслеживать метрики производительности гибкого сервера MySQL, такие как использование ЦП и памяти, производительность ввода-вывода, метрики запросов и многое другое, чтобы принимать обоснованные решения о емкости.
Размер вычислительных ресурсов: ОЗУ и ядра
Каждый из трех уровней служб предоставляет разные базовые номера SKU виртуальных машин. На уровне "Ускорение" используются виртуальные машины серии B, уровень общего назначения использует виртуальные машины серии D, а уровень критически важный для бизнеса использует виртуальные машины серии E. Серия виртуальных машин, используемая, определяет количество виртуальных ядер и ОЗУ, доступных на сервере.
Вы можете изменить уровень вычислений, размер вычислительных ресурсов и размер хранилища после создания сервера. Для изменения уровня вычислений или размера вычислительных ресурсов требуется перезагрузка, которая обычно занимает от одного до двух минут. Изменение размера хранилища не требует перезагрузки.
Для непроизводственных рабочих нагрузок (разработки, промежуточного тестирования, тестирования и т. д.) рекомендуется использовать серверы на основе уровня "Ускорение", что обеспечивает экономичное решение для рабочих нагрузок, которые не используют полный ЦП. В периоды низкого использования серверы, использующие виртуальные машины серии B, накапливают кредиты ЦП, которые можно использовать в периоды высокой загрузки для повышения производительности выше базового плана. Если базовый план слишком велик или слишком много всплесков использования, рассмотрите возможность обновления до уровней общего назначения или критически важный для бизнеса, чтобы избежать снижения производительности.
Размеры вычислительных ресурсов уровня служб
Каждый из трех уровней служб предоставляет различные уровни вычислительной мощности. Хотя уровень "Ускорение" может поддерживать до 20 виртуальных ядер, а уровень общего назначения может поддерживать до 64 виртуальных ядер с поддержкой до 96vCore, уровень критически важный для бизнеса обеспечивает самый высокий уровень вычислительной мощности. Уровень критически важный для бизнеса также предоставляет виртуальные машины серии Ev5, которые до 30% больше QPS и 50% ниже задержки, чем виртуальные машины серии Ev4.
Операции ввода-вывода в секунду: предварительная подготовка и автомасштабирование
Количество операций чтения и записи, которые можно выполнять в секунду, называется операций ввода-вывода хранилища (операции ввода-вывода в секунду). Более высокие параметры операций ввода-вывода в секунду обеспечивают более высокую производительность хранилища: более одновременные операции чтения и записи приводят к более быстрому получению данных, сохраняемости данных, обновлению индекса и общей эффективности базы данных. Если параметры ввода-вывода в секунду слишком низки, база данных может столкнуться с задержками обработки и снижением производительности. Если параметры ввода-вывода в секунду слишком высоки, затраты могут увеличиться без каких-либо улучшений производительности.
С помощью База данных Azure для MySQL — гибкий сервер можно предварительно подготовить операции ввода-вывода в секунду или использовать функцию автомасштабирования операций ввода-вывода в секунду.
При подготовке операций ввода-вывода выделяется определенное количество операций ввода-вывода для обеспечения согласованной и прогнозируемой производительности, которая хорошо работает, если загрузка не приближается к порогу, с которыми операции ввода-вывода становятся регулированием. Хотя вы всегда можете выделить дополнительные операции ввода-вывода в секунду по мере увеличения требований рабочей нагрузки, это требует ручного вмешательства.
Если включена функция автомасштабирования операций ввода-вывода в секунду, масштаб операций ввода-вывода в секунду по требованию на основе действия рабочей нагрузки и оплата на основе потребления. По мере увеличения рабочей нагрузки производительность сервера масштабирует производительность ввода-вывода, позволяя экземпляру обрабатывать пики рабочей нагрузки без оплаты неиспользуемой емкости при низком трафике.
В любом случае число операций ввода-вывода в секунду не может превышать максимальное количество операций ввода-вывода сервера. Сведения о максимальном объеме операций ввода-вывода в секунду по размеру вычислительных ресурсов см. в статье "Вычисления и хранилище".
Реплики чтения
По мере увеличения трафика базы данных можно масштабировать емкость горизонтально или "вне" (количество вычислительных узлов) или вертикально или "вверх" (размер вычислительных узлов). Реплики чтения обеспечивают горизонтальное масштабирование.
Реплика чтения — это копия базы данных, которая остается в синхронизации с помощью репликации двоичного журнала MySQL (binlog). По мере роста приложений необходимо масштабировать вычислительные ресурсы и ресурсы хранилища (например, базу данных). Масштабирование компонентов приложения упрощается путем подготовки новых виртуальных машин с помощью Служба Azure Kubernetes (AKS), Масштабируемые наборы виртуальных машин и Служба приложений. Так как эти вычислительные ресурсы масштабируются и хранятся, они увеличивают нагрузку на базу данных, которая часто становится узким местом в архитектуре приложения.
Использование реплики чтения позволяет перенаправить операции только для чтения в базы данных-получатели, чтобы сервер-источник поддерживал операции чтения и записи. База данных Azure для MySQL предоставляет управляемые реплики чтения. Исходный сервер можно реплицировать до 10 реплик. Это может помочь в таких случаях, как отчеты и аналитика, которые часто запрашивают большие объемы данных.
Использование реплики чтения особенно полезно, если по одной причине или другим запросам не удается использовать индексы. Он может быть непрактичным или даже разрушительным для добавления индексов для всех шаблонов запросов, так как он помещает дополнительную нагрузку на сервер (обработка, операции ввода-вывода, хранилище, время транзакции и т. д.). Если хранилище данных недоступно или вам нужны данные, которые более поздние, чем его цикл обновления, использование реплики чтения — отличный способ запуска "больших" запросов без нарушения критических операций чтения и записи.
Реплики чтения не сразу синхронны так же, как и конфигурация высокой доступности. Реплики чтения не вводят задержку транзакций, связанную с решением высокого уровня доступности, но при достижении реплики из базы данных-источника может возникнуть небольшая задержка.