База данных Azure для MySQL — уровни служб отдельного сервера
ОБЛАСТЬ ПРИМЕНЕНИЯ: 
База данных Azure для MySQL — отдельный сервер
Внимание
База данных Azure для MySQL один сервер находится на пути выхода на пенсию. Настоятельно рекомендуется выполнить обновление до База данных Azure для MySQL гибкого сервера. Дополнительные сведения о миграции на гибкий сервер База данных Azure для MySQL см. в статье "Что происходит с одним сервером База данных Azure для MySQL?"
Вы можете создать сервер службы "База данных Azure для MySQL" в одной из трех уровней служб: "Базовый", "Общего назначения" и "С оптимизацией для операций в памяти". Уровни служб различаются объемом вычислительных ресурсов в виртуальных ядрах, которые можно подготовить, объемом памяти на виртуальное ядро и технологиями хранения данных. Все ресурсы настраиваются на уровне сервера MySQL. У сервера может быть одна или несколько баз данных.
| Атрибут | Базовая | Общего назначения | Оптимизировано для обработки в памяти |
|---|---|---|---|
| Поколение вычислительных ресурсов | Поколение 4, поколение 5 | Поколение 4, поколение 5 | 5 поколение |
| Количество виртуальных ядер | 1, 2 | 2, 4, 8, 16, 32, 64 | 2, 4, 8, 16, 32 |
| Объем памяти на виртуальное ядро | 2 ГБ | 5 ГБ | 10 ГБ |
| Объем памяти | От 5 ГБ до 1 ТБ | От 5 ГБ до 16 ТБ | От 5 ГБ до 16 ТБ |
| Срок хранения резервной копии | От 7 до 35 дней | От 7 до 35 дней | От 7 до 35 дней |
Чтобы выбрать ценовую категорию, в качестве отправной точки используйте следующую таблицу.
| Уровень служб | Целевые рабочие нагрузки |
|---|---|
| Базовая | Рабочие нагрузки с невысокими вычислительными потребностями и производительностью операций ввода-вывода. К примерам относятся серверы, применяющиеся для разработки или тестирования, или небольшие редко используемые приложения. |
| Общего назначения | Для решения большинства бизнес-задач требуются сбалансированные вычислительные ресурсы и память с масштабируемой пропускной способностью операций ввода-вывода. Это могут быть серверы для размещения веб-и мобильных приложений и других корпоративных приложений. |
| С оптимизацией для операций в памяти | Рабочие нагрузки с высокой производительностью базы данных, требующие эффективной обработки данных в памяти для быстрого выполнения транзакций и повышения уровня параллелизма. Это могут быть серверы для обработки данных в режиме реального времени и высокопроизводительные транзакционные или аналитические приложения. |
Примечание.
В настоящее время динамическое масштабирование из уровней служб "Базовый" и в них не поддерживается. Серверы ценовой категории "Базовый" невозможно масштабировать до уровней общего назначения или оптимизированных для операций в памяти.
После создания сервера общего назначения или оптимизированного для операций в памяти количество виртуальных ядер, поколение оборудования и ценовую категорию можно увеличить и уменьшить в считанные секунды. Кроме того, можно независимо друг от друга увеличивать и уменьшать объем хранилища и срок хранения резервных копий без простоя приложения. После создания сервера невозможно изменить тип хранилища резервных копий. Дополнительные сведения см. в разделе Масштабирование ресурсов.
Поколения вычислительных ресурсов и виртуальные ядра
Вычислительные ресурсы поставляются в виде виртуальных ядер, которые представляют собой логические ЦП основного оборудования. В регионах Восточный Китай 1, Северный Китай 1, центральный регион US DoD и восточный регион US DoD используются логические ЦП 4-го поколения, основанные на процессорах Intel E5-2673 v3 (Haswell) с тактовой частотой 2,4 ГГц. Во всех остальных регионах используются логические ЦП 5-го поколения, основанные на процессорах Intel E5-2673 v4 (Broadwell) с тактовой частотой 2,3 ГГц.
Хранилище
Хранилище, которое вы подготавливаете, определяет объем доступной емкости хранилища для сервера службы "База данных Azure для MySQL". Хранилище используется для файлов базы данных, временных файлов, журналов транзакций и журналов сервера MySQL. Общий объем хранилища, который вы подготовили, также определяет доступную производительность операций ввода-вывода для сервера.
База данных Azure для MySQL — отдельный сервер поддерживает следующее серверное хранилище для серверов.
| Тип хранилища | Базовая | Общего назначения версии 1 | Общего назначения версии 2 |
|---|---|---|---|
| Объем памяти | От 5 ГБ до 1 ТБ | От 5 ГБ до 4 ТБ | От 5 ГБ до 16 ТБ |
| Шаг приращения хранилища | 1 ГБ | 1 ГБ | 1 ГБ |
| ОПЕРАЦИЙ ВВОДА-ВЫВОДА | «Переменная» | 3 операции ввода-вывода в секунду на ГБ Минимум 100 операций ввода-вывода в секунду Макс. 6000 операций ввода-вывода в секунду |
3 операции ввода-вывода в секунду на ГБ Минимум 100 операций ввода-вывода в секунду Макс. 20 000 операций ввода-вывода в секунду |
Примечание.
При использовании хранилища категории "Базовый" число операций ввода-вывода в секунду не гарантируется. В хранилище общего назначения показатель операций ввода-вывода в секунду соотносится с подготовленным размером хранилища как 3 к 1.
Хранилище категории "Базовый"
Хранилище категории "Базовый" — это серверное хранилище, поддерживающее серверы ценовой категории "Базовый". Базовое хранилище использует хранилище Azure уровня "Стандартный" в серверной части, где подготовленные операции ввода-вывода не гарантируются, а задержка является переменной. Категория "Базовый" лучше всего подходит для не требующих серьезных вычислительных ресурсов рабочих нагрузок с низкими затратами и небольшим числом операций ввода-вывода, относящихся к разработке или небольшим редко используемым приложениям.
Хранилище данных общего назначения
Хранилище данных общего назначения — это серверное хранилище, поддерживающее уровень серверов общего назначения и серверов, оптимизированных для операций в памяти. В хранилище общего назначения показатель операций ввода-вывода в секунду соотносится с подготовленным размером хранилища как 3 к 1. Как указано далее, существует два поколения хранилища общего назначения.
Хранилище общего назначения версии 1 (поддерживает до 4 ТБ)
В основе хранилища общего назначения версии 1 лежит устаревшая технология хранилища, которая поддерживает для каждого сервера хранилище объемом до 4 ТБ и 6000 операций ввода-вывода в секунду. Хранилище общего назначения версии 1 оптимизировано для использования памяти вычислительных узлов, где ядро MySQL применяется для локального кэширования и резервного копирования. Процесс резервного копирования в хранилище общего назначения версии 1 считывает данные из файлов данных и журналов в памяти вычислительных узлов, а также копирует их в целевое хранилище резервных копий, где они хранятся до 35 дней. В результате потребление памяти и количество операций ввода-вывода в хранилище во время резервного копирования относительно выше.
Все регионы Azure поддерживают хранилище общего назначения версии 1
В случае сервера общего назначения или сервера, оптимизированного для операций в памяти, в хранилище общего назначения версии 1 рекомендуется рассмотреть
- планирование увеличения памяти на 10-30% с учетом уровня SKU для вычислительных ресурсов в целях кэширования хранилища и создания буферов резервного копирования;
- подготовку на 10% больше операций ввода-вывода в секунду, чем требуется рабочей нагрузке БД с учетом количества операций ввода-вывода при резервном копировании;
- кроме того, можно выполнить миграцию в хранилище общего назначения версии 2, которое поддерживает объем хранилища до 16 ТБ, если базовая инфраструктура хранилища доступна в предпочитаемых регионах Azure, которые перечислены ниже.
Хранилище общего назначения версии 2 (поддерживает хранение до 16 ТБ данных)
В основе хранилища общего назначения версии 2 лежит новейшая инфраструктура хранилища, которая способна поддерживать до 16 ТБ и 20000 операций ввода-вывода в секунду. В том подмножестве регионов Azure, где доступна такая инфраструктура, все новые подготавливаемые серверы по умолчанию рассчитаны на применение хранилища общего назначения версии 2. По сравнению с хранилищем общего назначения версии 1 хранилище общего назначения версии 2 не потребляет память вычислительного узла MySQL и обеспечивает лучше прогнозируемые задержки при выполнении операций ввода-вывода. Резервное копирование на серверах с хранилищем общего назначения версии 2 выполняется на основе моментального снимка без дополнительных издержек, связанных с операциями ввода-вывода. Предполагается, что производительность сервера MySQL будет выше в хранилище общего назначения версии 2 по сравнению с хранилищем общего назначения версии 1 при подготовке одного и того же хранилища и числа операций ввода-вывода в секунду. Дополнительные затраты на хранилище общего назначения, поддерживающее хранение данных объемом до 16 ТБ, не предусмотрены. Чтобы получить помощь при переходе на хранилище объемом 16 ТБ, отправьте запрос в службу поддержки портала Azure.
Хранилище общего назначения версии 2 поддерживается в следующих регионах Azure.
| Область/регион | Доступность хранилища общего назначения версии 2 |
|---|---|
| Восточная Австралия | ✔️ |
| Юго-восточная часть Австралии | ✔️ |
| Южная Бразилия | ✔️ |
| Центральная Канада | ✔️ |
| Восточная Канада | ✔️ |
| Центральная часть США | ✔️ |
| Восточная часть США | ✔️ |
| Восточная часть США 2 | ✔️ |
| Восточная Азия | ✔️ |
| Восточная Япония | ✔️ |
| Западная Япония | ✔️ |
| Республика Корея, центральный регион | ✔️ |
| Республика Корея, южный регион | ✔️ |
| Северная Европа | ✔️ |
| Центрально-северная часть США | ✔️ |
| Центрально-южная часть США | ✔️ |
| Юго-Восточная Азия | ✔️ |
| южная часть Соединенного Королевства | ✔️ |
| западная часть Соединенного Королевства | ✔️ |
| Центрально-западная часть США | ✔️ |
| западная часть США | ✔️ |
| западная часть США 2 | ✔️ |
| Западная Европа | ✔️ |
| Центральная Индия | ✔️ |
| Центральная Франция* | ✔️ |
| Северная часть ОАЭ* | ✔️ |
| Северная часть ЮАР* | ✔️ |
Примечание.
*Регионы, в которых База данных Azure для MySQL имеет хранилище общего назначения версии 2 в общедоступной предварительной версии
* В случае этих регионов Azure можно будет создать сервер в хранилище общего назначения как версии 1, так и версии 2. Для серверов, созданных с хранилищем общего назначения версии 2 в общедоступной предварительной версии, ниже приведены ограничения.
- геоизбыточное резервное копирование не будет поддерживаться;
- сервер-реплика должен находиться в регионах, поддерживающих хранилище общего назначения версии 2.
Как определить тип хранилища для своего сервера?
Тип хранилища сервера можно найти на странице Параметры>Вычисления и хранилище
- Если сервер подготовлен с использованием SKU "Базовый", тип хранилища — "Базовое хранилище".
- Если сервер подготовлен с помощью SKU общего назначения или оптимизированного для памяти, тип хранилища — хранилище общего назначения
- Если максимальный объем хранилища, который может быть подготовлен на сервере, составляет 4 ТБ, тип хранилища — "Хранилище общего назначения версии 1".
- Если максимальный объем хранилища, которое может быть подготовлено на сервере составляет 16 ТБ, тип хранилища — "Хранилище общего назначения версии 2".
Можно ли перейти от хранилища общего назначения версии 1 к хранилищу общего назначения версии 2? А если да, то как и влечет ли это за собой дополнительные затраты?
Да, переход от хранилища общего назначения версии 1 к хранилищу общего назначения версии 2 поддерживается, если базовая инфраструктура хранилища доступна в регионе Azure исходного сервера. Такой переход и хранилище версии 2 не влекут за собой дополнительных затрат.
Можно ли мне увеличить размер хранилища после подготовки сервера?
Можно добавить дополнительную емкость хранилища во время и после создания сервера, а также разрешить системе автоматически увеличивать размер хранилища в зависимости от объема используемой рабочей нагрузки.
Внимание
Масштаб хранилища можно только увеличить вертикально, но не уменьшить.
Мониторинг использования операций ввода-вывода
Вы можете отслеживать показатель операций ввода-вывода на портале Azure или с помощью команд Azure CLI. Соответствующие метрики для мониторинга — это максимальный объем хранилища, процент использования хранилища, используемый объем хранилища и процент операций ввода-вывода. Метрики мониторинга для сервера MySQL с хранилищем общего назначения версии 1 сообщают о памяти и операциях ввода-вывода, потребляемых ядром MySQL, но могут не включать сведения о потреблении памяти и операциях ввода-вывода на уровне хранилища, что служит ограничением.
Достигнут размер хранилища
Серверы с подготовленным хранилищем объемом менее 100 ГБ помечаются как доступные только для чтения, если объем свободного хранилища составляет меньше 5 % от размера подготовленного хранилища. Серверы с подготовленным хранилищем более чем на 100 ГБ помечаются как доступные только для чтения, когда остается менее 5 ГБ свободного хранилища.
Например, если вы подготовили 110 ГБ емкости хранилища и фактическое использование превысило 105 ГБ, сервер помечается как доступный только для чтения. Еще пример: если вы подготовили 5 ГБ емкости хранилища, сервер помечается как доступный только для чтения, когда остается менее 256 МБ свободной емкости хранилища.
Пока служба пытается пометить сервер как доступный только для чтения, блокируются все новые запросы на запись транзакций, а выполнение существующих активных транзакций продолжается. Если сервер помечен как доступный только для чтения, все последующие операции записи и фиксации транзакций не выполняются. Запросы на чтение продолжат обрабатываться без перерыва. После повышения емкости подготовленного хранилища сервер снова будет готов к принятию транзакций записи.
Мы рекомендуем включить автоматическое увеличение хранилища и настроить оповещение для получения уведомлений о приближении к порогу емкости хранилища сервера, чтобы избежать перехода в режим только для чтения. Дополнительные сведения см. в статье о том, как настроить оповещение.
Автоматическое увеличение хранилища
Автоматическое увеличение хранилища используется, чтобы у серверов всегда сохранялся доступная емкость хранилища и они не переходили в режим только для чтения. Если включено автоматическое увеличение размера хранилища, объем хранилища автоматически увеличивается, не влияя на рабочую нагрузку. Для серверов с подготовленным хранилищем объемом 100 ГБ или меньше размер подготовленного хранилища увеличивается на 5 ГБ, когда свободный объем опускается ниже 10 % от подготовленного объема хранилища. Для серверов с подготовленным хранилищем объемом более 100 ГБ размер подготовленного хранилища увеличивается на 5 %, когда свободный объем хранилища опускается ниже 10 ГБ. Применяются максимальные ограничения хранилища, указанные выше.
Например, если вы подготовили 1000 ГБ емкости хранилища и фактическое использование превысило 990 ГБ, размер хранилища сервера увеличится до 1050 ГБ. Другой пример: подготовлено хранилище объемом 10 ГБ, размер хранилища увеличится до 15 ГБ, когда останется свободно менее 1 ГБ.
Помните, что объем хранилища можно только увеличить, но не уменьшить.
Хранилище резервных копий
В службе "База данных Azure для MySQL" хранилище для резервных копий размером до 100 % объема подготовленного хранилища базы данных предоставляется бесплатно. Любое хранилище резервных копий, используемое сверх этого объема, оплачивается за количество ГБ в месяц. Например, если вы подготовили сервер с 250 ГБ емкости хранилища, вам будет бесплатно предоставлены дополнительные 250 ГБ для хранения резервных копий сервера. Плата за резервные копии, превышающие 250 ГБ, будет рассчитываться согласно модели ценообразования. Чтобы понять факторы, влияющие на использование хранилища резервных копий, мониторинг и контроль затрат на хранение резервных копий, см. документацию по резервному копированию.
Масштабирование ресурсов
После создания сервера можно независимо друг от друга изменять количество виртуальных ядер, поколение оборудования, ценовую категорию (кроме переключения на категорию "Базовый" и с нее), объем хранилища и срок хранения резервных копий. После создания сервера невозможно изменить тип хранилища резервных копий. Число виртуальных ядер можно увеличивать или уменьшать. Срок хранения резервных копий можно увеличивать и уменьшать в диапазоне от 7 до 35 дней. Размер хранилища можно только увеличить. Масштабирование ресурсов можно выполнить с помощью портала или Azure CLI. Пример масштабирования с помощью CLI см. в статье Мониторинг и масштабирование сервера базы данных Azure для MySQL с помощью Azure CLI.
При изменении количества виртуальных ядер, поколения оборудования или ценовой категории создается копия сервера-источника с новым распределением вычислительных ресурсов. После того как новый сервер заработает, подключения переключатся на него. Во время перехода системы на новый сервер нельзя будет установить новые подключения, а для всех незафиксированных транзакций будет выполнен откат. Время простоя при масштабировании может составлять около 60–120 секунд. Время простоя при масштабировании зависит от времени восстановления базы данных, что может привести к тому, что база данных будет находиться в оперативном режиме, если на сервере во время операции масштабирования имеется высокая активность транзакций. Чтобы избежать более длительного перезапуска, рекомендуется выполнять операции масштабирования в периоды низкой активности транзакций на сервере.
Масштабирование хранилища и изменение срока хранения резервных копий — это полностью интерактивные операции. Они не останавливают работу приложения и не влияют на нее. Так как количество операций ввода-вывода в секунду возрастает по мере увеличения размера подготовленного хранилища, вы можете увеличивать количество доступных операций ввода-вывода на сервере путем масштабирования хранилища.
Цены
Наиболее актуальные сведения о стоимости см. в статье Цены на Базу данных Azure для PostgreSQL. Расходы на вашу конфигурацию можно посмотреть на портале Azure. На вкладке Ценовая категория отображается ежемесячная стоимость выбранных параметров. Если у вас нет подписки Azure, для расчета цены можно воспользоваться калькулятором цен Azure. На сайте с калькулятором цен Azure нажмите кнопку Добавить элементы, разверните категорию Базы данных и выберите База данных Azure для MySQL, чтобы настроить параметры.
Следующие шаги
- Узнайте, как создать сервер MySQL на портале.
- Дополнительные сведения см. в статье Ограничения в базе данных Azure для PostgreSQL.
- Дополнительные сведения см. в статье Горизонтальное увеличение масштаба с помощью реплик чтения.