База данных Azure для MySQL — уровни служб гибкого сервера
ОБЛАСТЬ ПРИМЕНЕНИЯ: 
База данных Azure для MySQL — гибкий сервер
Вы можете создать База данных Azure для MySQL гибкий экземпляр сервера в одном из трех уровней служб: "Ускорение", "Общее назначение" и критически важный для бизнеса. Базовый номер SKU виртуальной машины отличает уровни служб, используемые серии B, D-серии и серии E. Выбор уровня вычислений и размера определяет объем памяти и виртуальных ядер, доступных на сервере. Точную технологию хранения используются на всех уровнях служб. Все ресурсы подготавливаются на уровне гибкого экземпляра сервера База данных Azure для MySQL. У сервера может быть одна или несколько баз данных.
| Ресурс/уровень | С увеличивающейся производительностью | Общего назначения | Критически важный для бизнеса |
|---|---|---|---|
| Серия виртуальной машины | Размеры вычислительных машин серии B с увеличивающейся производительностью | Dadsv5-series Ddsv4-series | Серия Edsv4/Edsv5 серии*/Eadsv5 |
| Количество виртуальных ядер | 1, 2, 4, 8, 12, 16, 20 | 2, 4, 8, 16, 32, 48, 64 | 2, 4, 8, 16, 32, 48, 64, 80, 96 |
| Объем памяти на виртуальное ядро | «Переменная» | 4 ГиБ | 8 ГиБ ** |
| Объем памяти | От 20 ГиБ до 16 ТиБ | От 20 ГиБ до 16 ТиБ | 20 ГиБ до 32 ТиБ |
| Срок хранения резервной копии | 1–35 дней | 1–35 дней | 1–35 дней |
** Кроме 64.80 и 96 виртуальных ядер, которые имеют 504 ГиБ, 504 ГиБ и 672 ГиБ памяти соответственно.
* Вычисления Ev5 лучше всего выполняются среди других рядов виртуальных машин, касающихся QPS и задержки. Дополнительные сведения о доступности вычислительных ресурсов Ev5 и производительности региона см. здесь.
Гибкие уровни служб сервера
Чтобы выбрать уровень вычислений, в качестве отправной точки используйте следующую таблицу.
| Уровень вычислений | Целевые рабочие нагрузки |
|---|---|
| С увеличивающейся производительностью | Лучше всего подходит для рабочих нагрузок, которые постоянно не требуют полного ЦП. |
| Общего назначения | Для большинства бизнес-рабочих нагрузок требуются сбалансированные вычисления и память с масштабируемой пропускной способностью ввода-вывода. Это могут быть серверы для размещения веб-и мобильных приложений и других корпоративных приложений. |
| Критически важный для бизнеса | Рабочие нагрузки с высокой производительностью базы данных, требующие эффективной обработки данных в памяти для быстрого выполнения транзакций и повышения уровня параллелизма. Это могут быть серверы для обработки данных в режиме реального времени и высокопроизводительные транзакционные или аналитические приложения. |
После создания сервера можно изменить уровень вычислений, размер вычислительных ресурсов и размер хранилища. Масштабирование вычислений требует перезагрузки и занимает 60–120 секунд, а масштабирование хранилища не выполняется. Вы также можете самостоятельно настроить период хранения резервных копий вверх или вниз. Дополнительные сведения см. в разделе "Масштабируемые ресурсы ".
Уровни служб, размер и типы серверов
Вычислительные ресурсы можно выбирать на основе уровня и размера. Они определяют число виртуальных ядер и объем памяти. Виртуальные ядра представляют собой логический ЦП базового оборудования.
С увеличивающейся производительностью
Подробные спецификации доступных типов серверов приведены ниже для уровня службы с возможностью ускорения.
| Объем вычислительных ресурсов | Количество виртуальных ядер | Размер физической памяти (ГиБ) | Общий размер памяти (ГиБ) | Максимальное число поддерживаемых операций ввода-вывода в секунду | Максимальное число подключений | Temp Storage (SSD) GiB |
|---|---|---|---|---|---|---|
| Standard_B1ms | 1 | 2 | 2,2 | 640 | 341 | 0 |
| Standard_B2s | 2 | 4 | 4.4. | 1280 | 683 | 0 |
| Standard_B2ms | 2 | 8 | 8.8 | 1700 | 1365 | 0 |
| Standard_B4ms | 4 | 16 | 17.6 | 2400 | 2731 | 0 |
| Standard_B8ms | 8 | 32 | 35,2 | 3100 | 5461 | 0 |
| Standard_B12ms | 12 | 48 | 52,8 | 3800 | 8193 | 0 |
| Standard_B16ms | 16 | 64 | 70.4 | 4300 | 10923 | 0 |
| Standard_B20ms | 20 | 80 | 88 | 5000 | 13653 | 0 |
Общего назначения
Подробные спецификации доступных типов серверов приведены ниже для уровня служб общего назначения.
| Объем вычислительных ресурсов | Количество виртуальных ядер | Размер физической памяти (ГиБ) | Общий размер памяти (ГиБ) | Максимальное число поддерживаемых операций ввода-вывода в секунду | Максимальное число подключений | Temp Storage (SSD) GiB |
|---|---|---|---|---|---|---|
| Standard_D2ads_v5 | 2 | 8 | 11 | 3200 | 1365 | 53 |
| Standard_D2ds_v4 | 2 | 8 | 11 | 3200 | 1365 | 53 |
| Standard_D4ads_v5 | 4 | 16 | 22 | 6400 | 2731 | 107 |
| Standard_D4ds_v4 | 4 | 16 | 22 | 6400 | 2731 | 107 |
| Standard_D8ads_v5 | 8 | 32 | 44 | 12 800 | 5461 | 215 |
| Standard_D8ds_v4 | 8 | 32 | 44 | 12 800 | 5461 | 215 |
| Standard_D16ads_v5 | 16 | 64 | 88 | 20000 | 10923 | 430 |
| Standard_D16ds_v4 | 16 | 64 | 88 | 20000 | 10923 | 430 |
| Standard_D32ads_v5 | 32 | 128 | 176 | 20000 | 21845 | 860 |
| Standard_D32ds_v4 | 32 | 128 | 176 | 20000 | 21845 | 860 |
| Standard_D48ads_v5 | 48 | 192 | 264 | 20000 | 32768 | 1290 |
| Standard_D48ds_v4 | 48 | 192 | 264 | 20000 | 32768 | 1290 |
| Standard_D64ads_v5 | 64 | 256 | 352 | 20000 | 43691 | 1720 |
| Standard_D64ds_v4 | 64 | 256 | 352 | 20000 | 43691 | 1720 |
Критически важный для бизнеса
Подробные спецификации доступных типов серверов приведены ниже для уровня служб критически важный для бизнеса.
| Объем вычислительных ресурсов | Количество виртуальных ядер | Размер физической памяти (ГиБ) | Общий размер памяти (ГиБ) | Максимальное число поддерживаемых операций ввода-вывода в секунду | Максимальное число подключений | Temp Storage (SSD) GiB |
|---|---|---|---|---|---|---|
| Standard_E2ds_v4 | 2 | 16 | 22 | 5000 | 2731 | 37 |
| Standard_E2ads_v5 | 2 | 16 | 22 | 5000 | 2731 | 37 |
| Standard_E4ds_v4 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E4ads_v5 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E8ds_v4 | 8 | 64 | 88 | 18 000 | 10923 | 151 |
| Standard_E8ads_v5 | 8 | 64 | 88 | 18 000 | 10923 | 151 |
| Standard_E16ds_v4 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E16ads_v5 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E20ds_v4 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E20ads_v5 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E32ds_v4 | 32 | 256 | 352 | 38000 | 43691 | 604 |
| Standard_E32ads_v5 | 32 | 256 | 352 | 38000 | 43691 | 604 |
| Standard_E48ds_v4 | 48 | 384 | 528 | 48000 | 65536 | 906 |
| Standard_E48ads_v5 | 48 | 384 | 528 | 48000 | 65536 | 906 |
| Standard_E64ds_v4 | 64 | 504 | 693 | 64 000 | 86016 | 1224 |
| Standard_E64ads_v5 | 64 | 504 | 693 | 64 000 | 86016 | 1224 |
| Standard_E80ds_v4 | 80 | 504 | 693 | 72 000 | 86016 | 1224 |
| Standard_E2ds_v5 | 2 | 16 | 22 | 5000 | 2731 | 37 |
| Standard_E4ds_v5 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E8ds_v5 | 8 | 64 | 88 | 18 000 | 10923 | 151 |
| Standard_E16ds_v5 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E20ds_v5 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E32ds_v5 | 32 | 256 | 352 | 38000 | 43691 | 604 |
| Standard_E48ds_v5 | 48 | 384 | 528 | 48000 | 65536 | 906 |
| Standard_E64ds_v5 | 64 | 512 | 704 | 64 000 | 87383 | 120 Б |
| Standard_E96ds_v5 | 96 | 672 | 924 | 80 000 | 100000 | 2004 |
Устойчивость зоны по умолчанию в База данных Azure для MySQL — гибкий уровень критически важный для бизнеса сервера: начиная с середины декабря 2024 года все новые серверы, подготовленные в База данных Azure для MySQL — гибкий сервер критически важный для бизнеса уровень будет оснащен встроенной устойчивостью зоны без дополнительных затрат! Это означает, что файлы данных и журналов будут автоматически храниться в хранилище, избыточном между зонами, обеспечивая быстрое восстановление от зональных сбоев. Даже без поддержки высокой доступности вы сможете воспользоваться простой защитой с резервными копиями, избыточными по зонам. Подробнее.
Управление памятью на гибком сервере База данных Azure для MySQL
В MySQL память играет важную роль во всех различных операциях, включая обработку запросов и кэширование. База данных Azure для MySQL гибкий сервер оптимизирует выделение памяти для процесса сервера MySQL (mysqld), обеспечивая получение достаточного объема памяти для эффективной обработки запросов, кэширования, управления подключениями клиента и обработки потоков. Узнайте больше о том, как MySQL использует память.
Размер физической памяти (ГБ)
Размер физической памяти (ГБ) в таблице ниже представляет доступную память случайного доступа (ОЗУ) в гигабайтах (ГБ) на гибком сервере База данных Azure для MySQL.
Общий размер памяти (ГБ)
База данных Azure для MySQL гибкий сервер предоставляет общий размер памяти (ГБ). Это представляет общую память, доступную вашему серверу, которая представляет собой сочетание физической памяти и определенного объема временного компонента SSD хранилища. Это единое представление предназначено для упрощения управления ресурсами, что позволяет сосредоточиться только на общей памяти, доступной для процесса Azure MySQL Server (mysqld). Метрика "Процент памяти" (memory_percent) представляет процент памяти, занятой процессом сервера Azure MySQL (mysqld). Эта метрика вычисляется из общего размера памяти (ГБ). Например, если метрика "Процент памяти" отображает значение 60, это означает, что процесс Azure MySQL Server использует 60 % общего объема памяти (ГБ), доступного на База данных Azure для MySQL гибком сервере.
Сервер MySQL (mysqld)
Серверный процесс Azure MySQL, mysqld, является основным ядром операций субД. При запуске он инициализирует общие компоненты, такие как буферный пул InnoDB и кэш потоков, используя память на основе требований конфигурации и рабочей нагрузки. Например, пул буферов InnoDB кэширует часто доступ к данным и индексам для повышения скорости выполнения запросов, а кэш потоков управляет потоками подключения клиента. Подробнее.
Подсистема хранилища InnoDB
В качестве обработчика хранилища MySQL по умолчанию InnoDB использует память для кэширования часто доступ к данным и управления внутренними структурами, такими как пул буферов innodb и буфер журнала. Пул буферов InnoDB содержит табличные данные и индексы в памяти, чтобы свести к минимуму объем операций ввода-вывода диска, повышая производительность. Параметр размера буферного пула InnoDB вычисляется на основе размера физической памяти (ГБ), доступного на сервере. Дополнительные сведения о размерах буферного пула InnoDB, доступных на База данных Azure для MySQL гибком сервере.
Потоки
Клиентские подключения управляются с помощью выделенных потоков, обрабатываемых диспетчером соединений. Эти потоки обрабатывают проверку подлинности, выполнение запросов и получение результатов для взаимодействия с клиентом. Подробнее.
Дополнительные сведения о доступных сериях вычислений см. в документации по виртуальным машинам Azure для размеров виртуальных машин серии B, dadsv5серии Ddsv4 и критически важный для бизнеса серии Edsv4/Edsv5/серии Eadsv5.
Ограничения производительности экземпляров временных рядов
Примечание.
Если виртуальная машина запущена или остановлена или перезапущена, то кредиты могут быть потеряны для масштабируемых размеров виртуальных машин серии B. Дополнительные сведения см. в статье Размеры виртуальных машин Azure серии B с накапливаемыми ресурсами.
Ресурсоемкие вычислительные уровни предназначены для обеспечения экономичного решения для рабочих нагрузок, которые не требуют непрерывного полного ЦП. Этот уровень идеально подходит для непроизводственных рабочих нагрузок, таких как разработка, промежуточные или тестовые среды. Уникальная особенность высокопроизводительного вычислительного уровня — это возможность "ускорить", т. е. использовать более чем базовую производительность ЦП, используя до 100% виртуального ЦП, если рабочая нагрузка требует ее. Это возможно с помощью кредитной модели ЦП, которая позволяет экземплярам серии B накапливать "кредиты ЦП" в периоды низкой загрузки ЦП. Затем эти кредиты можно потратить в периоды высокой загрузки ЦП, что позволяет экземпляру повысить производительность ЦП выше базовой производительности ЦП.
Однако важно отметить, что после того, как экземпляр с ускорением исчерпывает свои кредиты ЦП, он работает на базовой производительности ЦП. Например, базовая производительность ЦП Standard_B1ms составляет 20 %, то есть 0,2 виртуального ядра. Предположим, что сервер с возможностью ускорения выполняет рабочую нагрузку, требующую больше производительности ЦП, чем базовый уровень и исчерпал свои кредиты ЦП. В этом случае сервер может столкнуться с ограничениями производительности и в конечном итоге может повлиять на различные системные операции, такие как Stop/Start/Restart для вашего сервера.
Примечание.
Для серверов в размерах виртуальных машин серии B, таких как Standard_B1s/Standard_B1ms/Standard_B2s, их относительно меньший размер памяти узла может привести к сбоям (вне памяти) в условиях непрерывной рабочей нагрузки, даже если метрика memory_percent не достигла 100 %.
Из-за этого регулирования сервер может столкнуться с проблемами подключения и системные операции могут быть затронуты. В таких ситуациях рекомендуется приостановить рабочую нагрузку на сервере, чтобы накапливать кредиты в соответствии с моделью банковского банка серии B, или рассмотреть возможность масштабирования сервера до более высоких уровней, таких как общего назначения или критически важный для бизнеса уровней.
Таким образом, в то время как уровень вычислительных ресурсов с высокой скоростью и гибкостью обеспечивает значительные преимущества для определенных типов рабочих нагрузок, не рекомендуется для рабочих нагрузок, требующих согласованной производительности ЦП. Уровень "Ускорение" не поддерживает функциональные возможности создания реплик чтения в База данных Azure для MySQL — гибкий сервер и основные понятия высокой доступности в База данных Azure для MySQL — гибкий сервер. Другие уровни вычислений, такие как общего назначения или критически важный для бизнеса, более подходящи для таких рабочих нагрузок и функций.
Дополнительные сведения о модели кредита ЦП серии B в Azure см. в статье о размерах виртуальных машин серии B и кредитной модели ЦП серии B.
Мониторинг кредитов ЦП на уровне с возможностью ускорения
Мониторинг кредитного баланса ЦП имеет решающее значение для обеспечения оптимальной производительности на уровне вычислительных ресурсов с возможностью ускорения. База данных Azure для MySQL Гибкий сервер предоставляет две ключевые метрики, связанные с кредитами ЦП. Идеальное пороговое значение для активации оповещения зависит от требований к рабочей нагрузке и производительности.
Мониторинг База данных Azure для MySQL — гибкий сервер: эта метрика указывает количество кредитов ЦП, потребляемых экземпляром. Мониторинг этой метрики поможет вам понять шаблоны использования ЦП экземпляра и эффективно управлять его производительностью.
Мониторинг База данных Azure для MySQL — гибкий сервер: эта метрика показывает количество кредитов ЦП, оставшихся для вашего экземпляра. Мониторинг этой метрики может помочь предотвратить снижение производительности экземпляра из-за исчерпания кредитов ЦП. Если метрика кредита ЦП остается ниже определенного уровня (например, менее 30% от общего доступного кредита), это означает, что экземпляр рискует исчерпать свои кредиты ЦП, если текущая загрузка ЦП продолжается.
Дополнительные сведения о настройке оповещений о метриках см. в этом руководстве.
Хранилище
Подготовленное хранилище — это емкость хранилища, доступная для гибкого сервера. Хранилище используется для файлов базы данных, временных файлов, журналов транзакций и журналов сервера MySQL. Для уровней служб с возможностью ускорения и общего назначения диапазон хранилища охватывает не менее 20 ГиБ до максимум 16 ТиБ. И наоборот, поддержка хранилища расширяется до 32 ТиБ для уровня служб критически важный для бизнеса. Во всех уровнях служб хранилище масштабируется в 1-ГиБ и может увеличиваться после создания сервера.
Примечание.
Масштаб хранилища можно только увеличить вертикально, но не уменьшить.
Вы можете отслеживать потребление хранилища на портале Azure (с Azure Monitor), используя метрики лимита хранилища, процент хранилища и объем использованного хранилища. Дополнительные сведения о метриках см. в статье о мониторинге.
Достичь предельного объема хранилища
Если хранилище, используемое на сервере, близко к достижению подготовленного ограничения, сервер помещается в режим только для чтения, чтобы защитить все потерянные записи на сервере. Серверы с подготовленным хранилищем объемом менее 100 ГиБ помечаются как доступные только для чтения, если объем свободного хранилища составляет меньше 5 % от размера подготовленного хранилища. Серверы с более чем 100 ГиБ подготовленным хранилищем помечаются только для чтения, если свободное хранилище меньше 5 ГиБ.
Например, если вы подготовили 110 ГиБ хранилища, а фактическое использование превышает 105 ГиБ, сервер помечается только для чтения. Еще пример: если подготовлено хранилище объемом 5 ГиБ, то сервер помечается как доступный только для чтения, когда остается менее 256 МБ свободного хранилища.
Хотя служба пытается сделать сервер доступной только для чтения, все новые запросы транзакций записи блокируются, а существующие активные транзакции продолжают выполняться. Если для сервера задано значение только для чтения, все последующие операции записи и фиксации транзакций завершаются ошибкой, но запросы чтения продолжают работать непрерывно.
Чтобы вывести сервер из режима "только для чтения", необходимо увеличить подготовленное хранилище на сервере. Это можно сделать с помощью портала Azure или Azure CLI. После увеличения сервер готов принять транзакции записи снова.
Мы рекомендуем настроить оповещение, чтобы уведомить вас о приближении порогового значения хранилища сервера, чтобы избежать попадания в состояние только для чтения. Дополнительные сведения см. в документации о том, как настроить оповещение.
Автоматическое увеличение хранилища
Автоматическое увеличение хранилища предотвращает работу сервера из хранилища и становится доступной только для чтения. Если автоматическое увеличение хранилища включено, хранилище автоматически растет, не влияя на рабочую нагрузку. Функция автоматического увеличения хранилища включена по умолчанию для всех новых создания серверов. Для серверов с подготовленным хранилищем менее 100 ГБ размер подготовленного хранилища увеличивается на 5 ГБ, если свободное хранилище меньше 10 % подготовленного хранилища. Для серверов с подготовленным хранилищем объемом более 100 ГБ размер подготовленного хранилища увеличивается на 5 %, когда свободный объем хранилища опускается ниже 10 ГБ. Применяются максимальные ограничения хранилища, указанные выше. Обновите экземпляр сервера, чтобы просмотреть обновленное хранилище, подготовленное в разделе Параметры на странице Вычисления и хранилище.
Например, если вы подготовили 1000 ГБ хранилища, а фактическое использование превышает 990 ГБ, размер хранилища сервера увеличивается до 1050 ГБ. Кроме того, если вы подготовили 20 ГБ хранилища, размер хранилища увеличивается до 25 ГБ, если не более 2 ГБ хранилища является бесплатным.
Помните, что после автомасштабирования хранилище не может быть уменьшено.
Примечание.
Функция автоматического увеличения хранилища включена по умолчанию для настроенного сервера с высоким уровнем доступности и не может быть отключена.
ОПЕРАЦИЙ ВВОДА-ВЫВОДА
База данных Azure для MySQL гибкий сервер поддерживает предварительно подготовленные операции ввода-вывода в секунду и автомасштабирование операций ввода-вывода в секунду. Операции ввода-вывода в секунду хранилища в База данных Azure для MySQL — гибкий сервер, минимальный объем операций ввода-вывода в секунду составляет 360 для всех вычислительных ресурсов, а максимальное количество операций ввода-вывода в секунду определяется выбранным размером вычислительных ресурсов. Дополнительные сведения о максимальном объеме операций ввода-вывода в секунду на вычислительные ресурсы см. в таблице.
Внимание
**Минимальное число операций ввода-вывода в секунду составляет 360 для всех размеров вычислительных ресурсов.
**Максимальное число операций ввода-вывода в секунду определяется выбранным размером вычислительных ресурсов.
Вы можете отслеживать потребление операций ввода-вывода в портал Azure (с Помощью Azure Monitor) с помощью монитора База данных Azure для MySQL — метрики гибкого сервера. Необходимо масштабировать вычислительные ресурсы сервера, если требуется больше операций ввода-вывода в секунду, чем максимальное число операций ввода-вывода в секунду на основе вычислений.
Предварительно подготовленные операции ввода-вывода в секунду
База данных Azure для MySQL гибкий сервер предлагает предварительно подготовленные операции ввода-вывода в секунду, что позволяет выделить определенное количество операций ввода-вывода в секунду для База данных Azure для MySQL гибкого экземпляра сервера. Этот параметр обеспечивает согласованную и прогнозируемую производительность для рабочих нагрузок. При подготовке операций ввода-вывода в секунду можно определить определенное ограничение операций ввода-вывода в секунду для тома хранилища, гарантируя возможность обработки некоторых запросов в секунду. Это приводит к надежному и гарантированному уровню производительности. Предварительно подготовленные операции ввода-вывода в секунду позволяют подготавливать дополнительные операции ввода-вывода в секунду , превышающие ограничение операций ввода-вывода в секунду. С помощью этой функции можно в любое время увеличить или уменьшить число подготовленных операций ввода-вывода в секунду в зависимости от требований рабочей нагрузки.
Автомасштабирование операций ввода-вывода в секунду
Краеугольным камнем База данных Azure для MySQL гибкий сервер является его способность достичь оптимальной производительности для рабочих нагрузок уровня 1. Это можно улучшить, позволяя серверу автоматически масштабировать производительность серверов баз данных (IO) в зависимости от потребностей рабочей нагрузки. Эта функция согласия позволяет пользователям масштабировать операции ввода-вывода по запросу без предварительной подготовки определенного количества операций ввода-вывода в секунду. Благодаря включенной включенной функции автомасштабирования операций ввода-вывода в секунду вы можете воспользоваться функцией управления беспокойными ввода-выводами в База данных Azure для MySQL гибком сервере, так как сервер автоматически масштабирует операции ввода-вывода в секунду в зависимости от потребностей рабочей нагрузки. Автомасштабирование операций ввода-вывода в секунду автоматически масштабируется до максимального размера операций ввода-вывода в секунду для каждого уровня служб и размера вычислительных ресурсов, как указано в документации по уровням служб. Это обеспечивает оптимальную производительность без необходимости выполнять масштабирование вручную.
При использовании автомасштабирования операций ввода-вывода вы платите только за использование сервера ввода-вывода и больше не требуется подготавливать и платить за ресурсы, которые они не полностью используют, экономя время и деньги. Кроме того, критически важные приложения уровня 1 могут обеспечить согласованную производительность, делая дополнительные операции ввода-вывода доступными для рабочей нагрузки в любое время. Автомасштабирование операций ввода-вывода в секунду устраняет администрирование, необходимое для обеспечения максимальной производительности по крайней мере затрат на База данных Azure для MySQL гибких клиентов сервера.
Динамическое масштабирование. Автоматическое масштабирование операций ввода-вывода в секунду динамически настраивает ограничение операций ввода-вывода сервера базы данных на основе фактического спроса рабочей нагрузки. Это обеспечивает оптимальную производительность без вмешательства вручную или настройки.
Обработка пиков рабочей нагрузки. Автомасштабирование операций ввода-вывода в секунду позволяет базе данных легко обрабатывать пики рабочей нагрузки или колебания без ущерба для производительности приложений. Эта функция обеспечивает согласованную скорость реагирования даже во время пиковых периодов использования.
Экономия затрат. В отличие от предварительно подготовленного ограничения операций ввода-вывода, указывающего фиксированный предел операций ввода-вывода и оплачиваемых операций ввода-вывода независимо от использования, автомасштабирование операций ввода-вывода позволяет платить только за количество операций ввода-вывода, которые вы используете.
Резервное копирование
Служба автоматически выполняет резервное копирование сервера. Вы можете выбрать период хранения от 1 до 35 дней. Дополнительные сведения о резервном копировании см. в статье об основных понятиях резервного копирования и восстановления.
Масштабирование ресурсов
После создания сервера можно независимо изменить уровень вычислений, размер вычислительных ресурсов (виртуальные ядра и память), объем хранилища и период хранения резервных копий. Размер вычислительных ресурсов можно масштабировать вверх или вниз, а период хранения резервных копий можно масштабировать с 1 до 35 дней. Размер хранилища можно только увеличить. Масштабирование ресурсов можно выполнить с помощью портала или Azure CLI.
Примечание.
Размер хранилища можно только увеличить. После увеличения возвращение к меньшему размеру хранилища невозможно.
При изменении уровня вычислений или размера вычислительных ресурсов сервер должен быть перезапущен для того, чтобы новый тип сервера вступил в силу. Когда система переключается на новый сервер, новые подключения не могут быть установлены, а все незафиксированные транзакции откатываются. В большинстве случаев это окно зависит от 60 до 120 секунд.
Масштабирование хранилища и изменение периода хранения резервных копий — это операции в сети и не требуют перезапуска сервера.
Цена,
Наиболее актуальные сведения о стоимости см. в статье Цены на Базу данных Azure для PostgreSQL. Расходы на вашу конфигурацию можно посмотреть на портале Azure. На вкладке Вычисления + хранение отображается ежемесячная стоимость для выбранных вариантов. Если у вас нет подписки Azure, для расчета цены можно воспользоваться калькулятором цен Azure. На сайте с калькулятором цен Azure нажмите кнопку Добавить элементы, разверните категорию Базы данных и выберите База данных Azure для MySQL и Гибкий сервер в качестве типа развертывания, чтобы настроить параметры.
Если вы хотите оптимизировать затраты на сервер, вы можете рассмотреть следующие советы.
- Если вычислительные ресурсы используются недостаточно, сократите уровень вычислений или объем вычислительных ресурсов (виртуальных ядер).
- Если ваша рабочая нагрузка не всегда использует полную емкость вычислительных ресурсов на уровнях "Общего назначения" и "Критически важный для бизнеса", перейдите на уровень "С увеличивающейся производительностью".
- Останавливайте сервер, когда он не используется.
- Уменьшите период хранения резервных копий, если длительное хранение резервного копирования не требуется.