База данных 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 ГиБ до 16 ТиБ |
| Срок хранения резервной копии | 1–35 дней | 1–35 дней | 1–35 дней |
** За исключением 64 80 и 96 виртуальных ядер, которые имеют 504 ГиБ, 504 ГиБ и 672 ГиБ памяти соответственно.
* Вычисление Ev5 обеспечивает лучшую производительность по сравнению с другими сериями виртуальных машин с точки зрения QPS и задержки. Дополнительные сведения о доступности вычислений Ev5 и производительности региона см. здесь.
Чтобы выбрать уровень вычислений, в качестве отправной точки используйте следующую таблицу.
| Уровень вычислений | Целевые рабочие нагрузки |
|---|---|
| С увеличивающейся производительностью | Лучше всего подходит для рабочих нагрузок, которые не требуют непрерывной полной загрузки ЦП. |
| Общего назначения | Для решения большинства бизнес-задач требуются сбалансированные вычислительные ресурсы и память с масштабируемой пропускной способностью операций ввода-вывода. Это могут быть серверы для размещения веб-и мобильных приложений и других корпоративных приложений. |
| Критически важный для бизнеса | Рабочие нагрузки с высокой производительностью базы данных, требующие эффективной обработки данных в памяти для быстрого выполнения транзакций и повышения уровня параллелизма. Это могут быть серверы для обработки данных в режиме реального времени и высокопроизводительные транзакционные или аналитические приложения. |
После создания сервера уровень вычислений, объем вычислительных ресурсов и размер хранилища можно изменить. Для масштабирования вычислений требуется перезапуск и занимает от 60 до 120 секунд, а масштабирование хранилища не требует перезагрузки. Вы также можете независимо увеличивать или уменьшать период хранения резервных копий. Дополнительные сведения см. в разделе Масштабирование ресурсов.
Уровни служб, размер и типы серверов
Вычислительные ресурсы можно выбирать на основе уровня и размера. Они определяют число виртуальных ядер и объем памяти. Виртуальные ядра представляют собой логический ЦП базового оборудования.
Подробные спецификации доступных типов серверов приведены следующим образом:
| Объем вычислительных ресурсов | Количество виртуальных ядер | Размер физической памяти (ГиБ) | Общий размер памяти (ГиБ) | Максимальное число поддерживаемых операций ввода-вывода в секунду | Максимальное число подключений | Temp служба хранилища (SSD) GiB |
|---|---|---|---|---|---|---|
| Standard_B1s | 1 | 1 | 1,1 | 320 | 171 | 0 |
| 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 служба хранилища (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 служба хранилища (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_E80ids_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
В 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) при запуске, остановке или перезапуске виртуальной машины могут быть потеряны кредиты. Дополнительные сведения см. в статье Вопросы и ответы об уровне "С увеличивающейся производительностью" (серия B).
Ресурсоемкие вычислительные уровни предназначены для обеспечения экономичного решения для рабочих нагрузок, которые не требуют непрерывного полного ЦП. Этот уровень идеально подходит для непроизводственных рабочих нагрузок, таких как разработка, промежуточные или тестовые среды. Уникальная особенность высокопроизводительного вычислительного уровня — это возможность "ускорить", т. е. использовать более чем базовую производительность ЦП, используя до 100% виртуального ЦП, если рабочая нагрузка требует ее. Это возможно с помощью кредитной модели ЦП, которая позволяет экземплярам серии B накапливать "кредиты ЦП" в периоды низкой загрузки ЦП. Затем эти кредиты можно потратить в периоды высокой загрузки ЦП, что позволяет экземпляру повысить производительность ЦП выше базовой производительности ЦП.
Однако важно отметить, что после того, как экземпляр с ускорением исчерпывает свои кредиты ЦП, он работает на базовой производительности ЦП. Например, базовая производительность ЦП Standard_B1ms составляет 20 %, то есть 0,2 виртуального ядра. Если сервер с расширенным уровнем выполняет рабочую нагрузку, требующую больше производительности ЦП, чем базовый уровень, и он исчерпал свои кредиты ЦП, сервер может столкнуться с ограничениями производительности и в конечном итоге может повлиять на различные системные операции, такие как Stop/Start/Restart для вашего сервера.
Примечание.
Для серверов на уровне вычислительных ресурсов с возможностью ускорения (серии B), таких как Standard_B1s/Standard_B1ms/Standard_B2s, их относительно меньший размер памяти узла может привести к сбоям (вне памяти) в неуместной рабочей нагрузке, даже если метрика memory_percent не достигла 100 %.
В связи с этим регулированием сервер может столкнуться с проблемами подключения, а системные операции могут быть затронуты. В таких ситуациях рекомендуется приостановить рабочую нагрузку на сервере, чтобы накапливать кредиты в соответствии с моделью банковского банка серии B, или рассмотреть возможность масштабирования сервера до более высоких уровней, таких как общего назначения или критически важный для бизнеса уровней.
Таким образом, в то время как уровень вычислительных ресурсов с высокой скоростью и гибкостью обеспечивает значительные преимущества для определенных типов рабочих нагрузок, не рекомендуется для рабочих нагрузок, требующих согласованной производительности ЦП. Уровень "Ускорение" не поддерживает функциональные возможности создания реплик чтения и высокой доступности . Для таких рабочих нагрузок и функций другие уровни вычислений, такие как общего назначения или критически важный для бизнеса, более подходящи.
Дополнительные сведения о модели кредитоспособности ЦП серии B Azure см . в экземплярах с возможностью ускорения серии B и кредитной модели ЦП серии B.
Мониторинг кредитов ЦП на уровне с возможностью ускорения
Мониторинг кредитного баланса ЦП имеет решающее значение для обеспечения оптимальной производительности на уровне вычислительных ресурсов с возможностью ускорения. База данных Azure для MySQL Гибкий сервер предоставляет две ключевые метрики, связанные с кредитами ЦП. Идеальное пороговое значение для активации оповещения зависит от конкретных требований к рабочей нагрузке и производительности.
Использование кредита ЦП: эта метрика указывает количество кредитов ЦП, потребляемых вашим экземпляром. Мониторинг этой метрики поможет вам понять шаблоны использования ЦП экземпляра и эффективно управлять его производительностью.
Оставшийся кредит ЦП: эта метрика показывает количество кредитов ЦП, оставшихся для вашего экземпляра. Следить за этой метрикой может помочь предотвратить снижение производительности экземпляра из-за исчерпания кредитов ЦП. Если метрика кредита ЦП остается ниже определенного уровня (например, менее 30% от общего доступного кредита), это означает, что экземпляр рискует исчерпать свои кредиты ЦП, если текущая загрузка ЦП продолжается.
Дополнительные сведения о настройке оповещений о метриках см. в этом руководстве.
Хранилище
Хранилище, которое вы подготавливаете, определяет объем доступной емкости хранилища для гибкого сервера. Хранилище используется для файлов базы данных, временных файлов, журналов транзакций и журналов сервера MySQL. На всех уровнях служб минимальный поддерживаемый объем хранилища составляет 20 ГиБ, а максимальный — 16 ТиБ. служба хранилища масштабируется в 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 гибкий сервер поддерживает предварительно подготовленные операции ввода-вывода в секунду и автомасштабирование операций ввода-вывода в секунду. Подробнее. Минимальное число операций ввода-вывода в секунду составляет 360 для всех размеров вычислительных ресурсов, а максимальное число операций ввода-вывода в секунду определяется выбранным размером вычислений. Дополнительные сведения о максимальном объеме операций ввода-вывода в секунду на вычислительные ресурсы см. в таблице.
Внимание
**Минимальное число операций ввода-вывода в секунду составляет 360 для всех размеров вычислительных ресурсов.
**Максимальное число операций ввода-вывода в секунду определяется выбранным размером вычислительных ресурсов.
Вы можете отслеживать потребление операций ввода-вывода на портале Azure (с Azure Monitor), используя метрику Процент ввода-вывода. Если требуется больше операций ввода-вывода в секунду, чем максимальное число операций ввода-вывода в секунду на основе вычислений, необходимо масштабировать вычислительные ресурсы сервера.
Предварительно подготовленные операции ввода-вывода в секунду
База данных Azure для MySQL гибкий сервер предлагает предварительно подготовленные операции ввода-вывода в секунду, что позволяет выделить определенное количество операций ввода-вывода в секунду для База данных Azure для MySQL гибкого экземпляра сервера. Этот параметр обеспечивает согласованную и прогнозируемую производительность для рабочих нагрузок. При подготовке операций ввода-вывода в секунду можно определить определенное ограничение операций ввода-вывода в секунду для тома хранилища, гарантируя возможность обработки некоторых запросов в секунду. Это приводит к надежному и гарантированному уровню производительности. Предварительно подготовленные операции ввода-вывода в секунду позволяют подготавливать дополнительные операции ввода-вывода в секунду , превышающие ограничение операций ввода-вывода в секунду. С помощью этой функции можно в любое время увеличить или уменьшить число подготовленных операций ввода-вывода в секунду в зависимости от требований рабочей нагрузки.
Автомасштабирование операций ввода-вывода в секунду
Краеугольным камнем База данных Azure для MySQL гибкий сервер является его способность достичь оптимальной производительности для рабочих нагрузок уровня 1, что может быть улучшено путем автоматического масштабирования сервера производительности сервера базы данных в зависимости от потребностей рабочей нагрузки. Это функция согласия, которая позволяет пользователям масштабировать операции ввода-вывода по запросу без предварительной подготовки определенного количества операций ввода-вывода в секунду. Благодаря включенной функции автомасштабирования операций ввода-вывода в секунду теперь вы можете наслаждаться бесплатным управлением операций ввода-вывода в База данных Azure для MySQL гибком сервере, так как сервер масштабирует операции ввода-вывода вверх или вниз автоматически в зависимости от потребностей рабочей нагрузки.
При автомасштабировании операций ввода-вывода в секунду вы платите только за использование сервера и больше не требуется подготавливать и платить за ресурсы, которые они не полностью используют, экономя как время, так и деньги. Кроме того, критически важные приложения уровня 1 могут обеспечить согласованную производительность, делая дополнительные операции ввода-вывода доступными для рабочей нагрузки в любое время. Автомасштабирование операций ввода-вывода в секунду устраняет администрирование, необходимое для обеспечения максимальной производительности по крайней мере затрат на База данных Azure для MySQL гибких клиентов сервера.
Динамическое масштабирование. Автоматическое масштабирование операций ввода-вывода в секунду динамически настраивает ограничение операций ввода-вывода в секунду сервера базы данных на основе фактического спроса на рабочую нагрузку. Это обеспечивает оптимальную производительность без вмешательства вручную или настройки.
Обработка пиков рабочих нагрузок. Автоматическое масштабирование операций ввода-вывода в секунду позволяет базе данных легко обрабатывать пики рабочей нагрузки или колебания без ущерба для производительности приложений. Эта функция обеспечивает согласованную скорость реагирования даже во время пиковых периодов использования.
Экономия затрат. В отличие от предварительно подготовленных операций ввода-вывода, в которых указан фиксированный предел операций ввода-вывода и оплачивается независимо от использования, автомасштабирование операций ввода-вывода позволяет платить только за количество операций ввода-вывода, которые вы используете.
Резервное копирование
В службе автоматически создаются резервные копии сервера. Вы можете установить период хранения от 1 до 35 дней. Дополнительные сведения о резервном копировании см. в статье об основных понятиях резервного копирования и восстановления.
Масштабирование ресурсов
После создания сервера можно независимо друг от друга изменять уровень вычислений, объем вычислительных ресурсов (виртуальные ядра и память), объем хранилища и период хранения резервных копий. Объем вычислительных ресурсов можно увеличивать или уменьшать. Период хранения резервных копий можно увеличивать и уменьшать в диапазоне от 1 до 35 дней. Размер хранилища можно только увеличить. Масштабирование ресурсов можно выполнить с помощью портала или Azure CLI.
Примечание.
Размер хранилища можно только увеличить. После увеличения возвращение к меньшему размеру хранилища невозможно.
При изменении уровня вычислений или объема вычислительных ресурсов сервер перезагружается, чтобы изменения вступили в силу. Во время перехода системы на новый сервер нельзя будет установить новые подключения, а для всех незафиксированных транзакций будет выполнен откат. Этот период может быть разным, но обычно составляет от 60 до 120 секунд.
Масштабирование хранилища и изменение периода хранения резервных копий — это операции в сети и не требуют перезапуска сервера.
Цены
Наиболее актуальные сведения о стоимости см. в статье Цены на Базу данных Azure для PostgreSQL. Расходы на вашу конфигурацию можно посмотреть на портале Azure. На вкладке Вычисления + хранение отображается ежемесячная стоимость для выбранных вариантов. Если у вас нет подписки Azure, для расчета цены можно воспользоваться калькулятором цен Azure. На сайте с калькулятором цен Azure нажмите кнопку Добавить элементы, разверните категорию Базы данных и выберите База данных Azure для MySQL и Гибкий сервер в качестве типа развертывания, чтобы настроить параметры.
Если вы хотите оптимизировать стоимость сервера, рассмотрите следующие возможности.
- Если вычислительные ресурсы используются недостаточно, сократите уровень вычислений или объем вычислительных ресурсов (виртуальных ядер).
- Если ваша рабочая нагрузка не всегда использует полную емкость вычислительных ресурсов на уровнях "Общего назначения" и "Критически важный для бизнеса", перейдите на уровень "С увеличивающейся производительностью".
- Останавливайте сервер, когда он не используется.
- Уменьшите период хранения резервных копий, если длительное хранение резервного копирования не требуется.
Связанный контент
- Узнайте, как создать База данных Azure для MySQL гибкий экземпляр сервера на портале.
- Дополнительные сведения см. в статье об ограничениях службы.