Поделиться через

Длительность операций управления в Управляемом экземпляре SQL Azure

Применимо к:Управляемый экземпляр SQL Azure

В этой статье описаны шаги и длительность операций управления в Управляемом экземпляре SQL Azure.

Для обзора основных процессов, связанных с операциями управления, такими как инициализация и переключение при отказах, см. Обзор операций управления.

Действия по управлению

Управление управляемым экземпляром SQL Azure включает следующие операции:

  • Создание: операции, возникающие при создании управляемого экземпляра SQL. Это включает создание или изменение размера базовой группы виртуальных машин и развертывание процесса ядра СУБД SQL.
  • Обновление. Операции, возникающие при изменении свойств существующего управляемого экземпляра SQL, таких как масштабирование вычислений или хранилища, изменение уровня служб или обновление конфигурации экземпляра. Обновление часто включает создание или изменение размера базовой группы виртуальных машин, а также загрузку данных, и затем переключение на новый процесс ядра СУБД SQL.
  • Удаление. Операции, возникающие при удалении существующего управляемого экземпляра SQL, включая очистку ресурсов, таких как группа виртуальных машин, связанная с экземпляром.

Создание операции

Операция создания инициирует развертывание нового управляемого экземпляра SQL в подсети виртуальной сети, при настройке вычислений, хранилища и среды ядра СУБД SQL для экземпляра.

Процесс создания обычно проходит три этапа:

  1. Проверка запроса: отправленные параметры синтаксически и семантично проверяются. Если параметры недопустимы (например, неправильная подсеть или неподдерживаемый номер SKU), операция немедленно завершается ошибкой.
  2. Создайте или измените размер группы виртуальных машин: создает или расширяет группу виртуальных машин для размещения нового экземпляра. Длительность операции зависит от того, является ли экземпляр избыточным для зоны или нет.
  3. Запуск нового экземпляра SQL: развертывает и запускает процесс ядра СУБД SQL на выделенных виртуальных машинах.

Операция обновления

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

Процесс обновления обычно проходит пять этапов:

  1. Проверка запроса: отправленные параметры синтаксически и семантично проверяются. Проверяет поддерживаемые типы обновлений на основе текущей конфигурации экземпляра и запрошенных изменений. Если запрос недопустим, операция завершается ошибкой.
  2. Создайте или измените размер группы виртуальных машин: в зависимости от изменения существующая группа виртуальных машин изменяется или создается новая группа виртуальных машин, например в следующих операциях обновления:
    • Масштабирование хранилища вверх или вниз
    • Масштабирование вычислений вверх или вниз
    • Изменение уровня служб
    • Изменение оборудования
    • Настройка периода обслуживания
    • Включение или отключение избыточности зоны
  3. Запуск экземпляра SQL: новый процесс ядра СУБД SQL инициализирован с обновленной конфигурацией.
    • При создании новой группы виртуальных машин или изменении размера существующей группы виртуальных машин происходит полное развертывание ядра СУБД SQL.
  4. Начальное или присоединенное хранилище. Подготовка базы данных в новой или измененной группе виртуальных машин. Экземпляр доступен во время этого процесса.
  5. Подготовка к переключению и переходу на резервный сервер: трафик перенаправляется на новую инстанцию.
    • Экземпляр недоступен только во время аварийного переключения, когда трафик перенаправляется в новый механизм СУБД SQL. На уровне служб "Критически важный для бизнеса " экземпляр недоступен до 20 секунд, в то время как на уровне служб общего назначения экземпляр может быть недоступен до 2 минут.
  6. Очистите старый экземпляр SQL: разделите старые виртуальные машины и удалите процессы SQL, которые больше не требуются.

Это важно

Масштабирование вычислительных ресурсов или хранилища и изменение уровня службы одновременно с длительными транзакциями (такими как импорт данных, задания по обработке данных или перестроение индекса) не рекомендуется, так как переключение базы данных в конце операции отменяет все активные транзакции.

Операция удаления

Операция удаления удаляет существующий управляемый экземпляр SQL и очищает связанные ресурсы. После активации операции удаления выставление счетов для Управляемого экземпляра SQL отключено. Длительность операции удаления не влияет на выставление счетов.

Процесс удаления обычно проходит через четыре этапа:

  1. Проверка запроса: отправленные параметры синтаксически и семантично проверяются. Если запрос недопустим, операция завершается ошибкой.
  2. Резервное копирование tail-log: если экземпляр не пуст, резервная копия tail-log принимается для каждой базы данных, чтобы убедиться, что данные не будут потеряны после удаления экземпляра. Резервные копии хранятся на основе политики хранения каждой базы данных.
  3. Очистка экземпляра SQL: процесс ядра СУБД SQL удаляется из группы виртуальных машин, а ресурсы, связанные с экземпляром, освобождены.
  4. Удаление группы виртуальных машин. Если в подсети есть другие экземпляры, группа виртуальных машин остается нетронутой для этих экземпляров. Если удаленный экземпляр является последним экземпляром в подсети, группа виртуальных машин синхронно удаляется в качестве последнего шага. Когда последний экземпляр в подсети удаляется, удаление группы виртуальных машин автоматически инициирует удаление виртуального кластера.

Пулы экземпляров

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

Создание пула экземпляров включает следующие действия.

  • Проверка запроса: отправленные параметры синтаксически и семантично проверяются. Если запрос недопустим, операция завершается ошибкой.
  • Создайте группу виртуальных машин: создается новая группа виртуальных машин для размещения пула экземпляров в подсети виртуальной сети Azure. Количество виртуальных ядер, выделенных виртуальному кластеру, — это максимальное количество виртуальных ядер, используемых всеми экземплярами в пуле. Это одноразовая операция, которая настраивает базовую инфраструктуру для нескольких управляемых экземпляров.
  • Создание экземпляра: экземпляры создаются в пуле экземпляров, который включает развертывание процесса ядра СУБД SQL на выделенных виртуальных машинах. Экземпляры совместно используют ресурсы виртуального кластера, что позволяет повысить эффективность использования ресурсов. Клиент создает экземпляры по мере необходимости.

Создание экземпляра в пуле включает следующие действия.

  • Проверка запроса: отправленные параметры синтаксически и семантично проверяются. Если запрос недопустим, операция завершается ошибкой.
  • Создание экземпляра: экземпляры создаются в пуле экземпляров, который включает развертывание процесса ядра СУБД SQL на выделенных виртуальных машинах.

Перемещение экземпляра в пул экземпляров включает следующие действия.

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

Перемещение экземпляра из пула экземпляров включает следующие действия.

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

Зональная избыточность

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

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

Длительность операции управления

Длительность операций управления зависит от уровня служб Управляемого экземпляра SQL. В следующих разделах приведены подробные сведения о продолжительности операций управления для каждого уровня служб.

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

Операция управления Длительные сегменты Ожидаемая продолжительность
Создание операций
Создание нового экземпляра Создание или изменение размера группы виртуальных машин 95% операций завершаются за 30 минут
Создание нового зонально-резервного экземпляра Создание или масштабирование группы виртуальных машин с отказоустойчивостью зоны 95% операций завершено в течение 4 часов
Создание нового пула экземпляров Создание группы виртуальных машин 95% операций завершаются за 30 минут
Создание экземпляра внутри пула Отсутствует 95 процентов операций группы% выполняются менее чем за 10 минут
Операции обновления
Изменение базовых свойств экземпляра, таких как тип лицензии или Microsoft Entra Отсутствует До 1 минуты
Масштабирование хранилища Отсутствует 99% операций завершаются за 5 минут
Масштабирование вычислительных ресурсов (виртуальные процессоры) Создание или изменение размера группы виртуальных машин 95% операций выполняются в течение 60 минут
Изменение уровня обслуживания на Критически важный для бизнеса Изменение размера группы виртуальных машин
+ Заполнение базы данных начальными данными		 95% операций выполняются в течение 60 минут + время для инициализации баз данных
Переход на уровень служб общего назначения следующего поколения Создание или изменение размера группы виртуальных машин
+ Заполнение базы данных начальными данными		 95% операций выполняются в течение 60 минут + время для инициализации баз данных
Изменение оборудования или окна обслуживания Создание или изменение размера группы виртуальных машин 95% операций выполняются в течение 60 минут
Включение зональной избыточности Создание новой группы виртуальных машин
+ Заполнение базы данных начальными данными		 95% операций завершаются за 4 часа + время для инициализации баз данных
Отключение избыточности зоны Создание новой группы виртуальных машин
+ Заполнение базы данных начальными данными		 95% операций выполняются в течение 30 минут + время на заполнение баз данных
Перемещение экземпляра в пул экземпляров Отсутствует 95% операций завершено за 10 минут
Перемещение экземпляра из пула экземпляров Создание или изменение размера группы виртуальных машин 95% операций выполняются в течение 60 минут
Удаление операций
Удаление непоследнего экземпляра1 Резервное копирование заключительного фрагмента журнала для всех баз данных 90% операций заканчиваются за 1 минуту.
Удаление последнего экземпляра2 Резервное копирование хвоста журнала для всех баз данных
Удаление виртуального кластера		 95% операций завершаются за 90 минут

1 Если в кластере несколько групп виртуальных машин, удаление последнего экземпляра в группе немедленно активирует удаление группы виртуальных машин асинхронно.
2 Удаление последнего экземпляра в подсети немедленно активирует удаление виртуального кластера синхронно.

Экземпляр доступен в течение всех операций управления, за исключением последнего этапа отработки отказа , когда трафик перенаправляется в новый процесс ядра СУБД SQL. На уровне служб "Критически важный для бизнеса " экземпляр недоступен до 20 секунд, в то время как в уровнях служб "Общего назначения " и "Следующее поколение общего назначения " экземпляр может быть недоступен до 2 минут.

Продолжительность раздачи

Посев — это процесс инициализации и синхронизации данных в SQL-движках базы данных. Продолжительность заполнения данных в основном зависит от размера базы данных. В среднем скорость загрузки составляет примерно 220 ГБ в час.

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

В следующей таблице приведены следующие сведения:

  • Вероятное оценочное время начала процесса для большинства случаев
  • Ожидаемое максимально ожидаемое время посева для 95% случаев
Диапазон размера базы данных (ГБ) Вероятное время посева Ожидаемое максимальное время посева
0 – 32 ГБ 30 минут 1 час
32 – 256 ГБ 1,5 ч 2 часа
256 – 512 ГБ 2 часа 5 часов
512 – 1024 ГБ 5 часов 9 часов
1024 – 2048 ГБ 9 часов 15 часов
2048 — 3072 ГБ 10 часов 16 ч
3072 – 4096 ГБ 12 часов 18 часов
Больше 4096 ГБ 15 часов 20 часов

Связанный контент