Как управлять базой данных уровня "Гипермасштабирование"

Область применения: База данных SQL Azure

Уровень служб "Гипермасштабирование" предоставляет высокомасштабируемый уровень производительности хранилища и вычислительных ресурсов, который использует архитектуру Azure для горизонтального увеличения масштаба этих ресурсов для службы "База данных SQL Azure" за пределы, доступные для уровней служб "Общего назначения" и "Критически важный для бизнеса". В этой статье объясняется, как выполнять основные задачи администрирования для баз данных уровня "Гипермасштабирование", включая переход на этот уровень, восстановление базы данных уровня "Гипермасштабирование" в другой регион, обратный переход с уровня "Гипермасштабирование" на другой уровень служб, а также мониторинг состояния текущих и недавно выполненных операций с базой данных уровня "Гипермасштабирование".

Узнайте, как создать новую базу данных уровня "Гипермасштабирование", из статьи Краткое руководство. Создание базы данных уровня "Гипермасштабирование" в Базе данных SQL Azure.

Перенос существующей базы данных на уровень "Гипермасштабирование"

Вы можете переместить существующие базы данных в Базе данных SQL Azure на уровень "Гипермасштабирование" с помощью портала Azure, Azure CLI, PowerShell или Transact-SQL.

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

Во время окончательного перехода на уровень служб "Гипермасштабирование" простой будет совсем незначительным (как правило, несколько минут).

Предварительные требования

Чтобы перенести базу данных в рамках отношения георепликации как базу данных-источник или базу данных-получатель на уровень "Гипермасштабирование", сначала нужно завершить репликацию данных между первичной и вторичной репликами. Базы данных в группе отработки отказа должны быть сначала удалены из группы.

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

Как перенести базу данных на уровень служб "Гипермасштабирование"

Чтобы перенести существующую базу данных в Базе данных SQL Azure на уровень служб "Гипермасштабирование", сначала определите целевую службу. Просмотрите ограничения ресурсов для отдельных баз данных, если вы не определились с тем, какая целевая служба подходит для вашей базы данных. Во многих случаях можно выбрать целевую службу с таким же количеством виртуальных ядер и тем же поколением оборудования, что и исходная база данных. При необходимости позднее вы сможете настроить эту службу с минимальным временем простоя.

Выберите вкладку для предпочитаемого средства переноса базы данных:

Портал Azure позволяет перейти на уровень служб "Гипермасштабирование", изменив ценовую категорию для базы данных.

Снимок экрана: панель вычислений и хранилища базы данных в Azure SQL Database. Раскрывающийся список уровня служб развернут, отображающий параметр для уровня служб

  1. Перейдите к базе данных, которую хотите перенести на портал Azure.
  2. На панели навигации слева выберите элемент Вычисления и хранилище.
  3. Выберите раскрывающийся список Уровень служб, чтобы развернуть раздел параметров для уровней служб.
  4. Выберите элемент Hyperscale (On-demand scalable storage) (Гипермасштабирование (масштабируемое хранилище по запросу)) в раскрывающемся меню.
  5. Просмотрите указанную конфигурацию оборудования. При необходимости выберите команду Изменить конфигурацию, чтобы выбрать соответствующую конфигурацию оборудования для рабочей нагрузки.
  6. Ознакомьтесь с параметром Экономия. Выберите его, если имеете право на применение Преимущества гибридного использования Azure и хотите применить его для этой базы данных.
  7. Выберите ползунок vCores, если вам нужно изменить количество виртуальных ядер, доступных для базы данных на уровне служб "Гипермасштабирование".
  8. Выберите ползунок High-AvailabilitySecondaryReplicas, если вам нужно изменить количество реплик на уровне служб "Гипермасштабирование".
  9. Нажмите кнопку Применить.

Вы можете отслеживать операции для базы данных уровня "Гипермасштабирование" во время выполнения операции.

Обратная миграция с уровня "Гипермасштабирование"

Обратная миграция на уровень служб "Общего назначения" позволяет клиентам, которые недавно перевели существующую базу данных в Базе данных SQL Azure на уровень служб "Гипермасштабирование", оперативно выполнить обратное перемещение, если уровень "Гипермасштабирование" больше не соответствует их потребностям. Обратная миграция инициируется изменением уровня службы, но по сути это перемещение определенного объема данных между разными архитектурами.

Ограничения для обратной миграции

Обратная миграция доступна в следующих условиях:

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

Длительность и простой

В отличие от обычных операций изменения целевого уровня служб на уровне "Гипермасштабирование", миграция на уровень "Гипермасштабирование" и обратная миграция на уровень "Общего назначения" — это операции с размером данных.

Длительность обратной миграции главным образом зависит от размера базы данных и параллельных операций записи, выполняемых во время миграции. Количество виртуальных ядер, назначенных целевой базе данных уровня "Общего назначения", также повлияет на продолжительность обратной миграции. Рекомендуем подготовить целевую базу данных уровня "Общего назначения" с количеством виртуальных ядер, которое больше количества виртуальных ядер, назначенных исходной базе данных уровня "Гипермасштабирование" для поддержания аналогичных рабочих нагрузок, или равно этому количеству.

Во время обратной миграции производительность исходной базы данных уровня "Гипермасштабирование" может понизиться при значительной нагрузке. В частности, скорость журнала транзакций можно снизить (выполнить регулирование), чтобы обеспечить успешное выполнение обратной миграции.

Во время окончательного перехода на новую целевую базу данных уровня "Общего назначения" простой будет совсем незначительным (как правило, несколько минут).

Предварительные требования

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

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

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

Политики резервного копирования

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

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

Например, вы можете переходить между уровнем "Гипермасштабирование" и другими уровнями служб:

  1. Общего назначения
  2. Переход на уровень служб "Гипермасштабирование".
  3. Обратная миграция на уровень "Общего назначения".
  4. Изменение уровня служб на уровень "Критически важный для бизнеса".
  5. Переход на уровень служб "Гипермасштабирование".
  6. Обратная миграция на уровень "Общего назначения".

В этом случае единственными доступными резервными копиями будут созданные между этапами 5 и 6 временной шкалы, если они по-прежнему находятся в пределах настроенного периода хранения. Все резервные копии с предыдущих этапов будут недоступны. Нужно тщательно взвесить необходимость выполнения нескольких операций обратной миграции с уровня "Гипермасштабирование" на уровень "Общего назначения".

Как выполнить обратный перенос базы данных с уровня служб "Гипермасштабирование" на уровень служб "Общего назначения"

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

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

Выберите вкладку для предпочитаемого метода обратного переноса базы данных:

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

Снимок экрана: панель вычислений и хранилища базы данных с гипермасштабированием в Azure SQL Database.

  1. Перейдите к базе данных, которую хотите перенести на портал Azure.
  2. На панели навигации слева выберите элемент Вычисления и хранилище.
  3. Выберите раскрывающийся список Уровень служб, чтобы развернуть раздел параметров для уровней служб.
  4. В раскрывающемся меню выберите элемент General Purpose (Scalable compute and storage options) (Общего назначения (масштабируемые вычислительные ресурсы и параметры хранилища)).
  5. Просмотрите указанную конфигурацию оборудования. При необходимости выберите команду Изменить конфигурацию, чтобы выбрать соответствующую конфигурацию оборудования для рабочей нагрузки.
  6. Ознакомьтесь с параметром Экономия. Выберите его, если имеете право на применение Преимущества гибридного использования Azure и хотите применить его для этой базы данных.
  7. Выберите ползунок vCores, если вам нужно изменить количество виртуальных ядер, доступных для базы данных на уровне служб "Общего назначения".
  8. Нажмите кнопку Применить.

Мониторинг операций для базы данных уровня "Гипермасштабирование"

Вы можете отслеживать состояние текущих или недавно завершенных операций для Базы данных SQL Azure с помощью портал Azure, Azure CLI, PowerShell или Transact-SQL.

Выберите вкладку для предпочитаемого метода мониторинга операций.

При выполнении такой операции, как миграция, обратная миграция или восстановление на портале Azure отображается уведомление для базы данных в Базе данных SQL Azure.

Снимок экрана: панель обзора базы данных в Azure SQL Database. Уведомление о текущей операции отображается в области уведомлений в нижней части панели.

  1. Перейдите к базе данных на портале Azure.
  2. На левой панели навигации выберите Обзор.
  3. Просмотрите раздел Уведомления в нижней части панели справа. Если операции выполняются, появится окно уведомлений.
  4. Выберите поле уведомлений, чтобы просмотреть подробные сведения.
  5. Откроется область Текущие операции. Просмотрите сведения о текущих операциях.

Просмотр баз данных на уровне служб "Гипермасштабирование"

После переноса базы данных на уровень "Гипермасштабирование" или перенастройки базы данных на уровне служб "Гипермасштабирование", возможно, потребуется просмотреть и (или) задокументировать конфигурацию базы данных уровня "Гипермасштабирование".

На портале Azure отображается список всех баз данных на логическом сервере. Столбец Ценовая категория включает уровень служб для каждой базы данных.

Снимок экрана: панель обзора логического сервера в Azure SQL Базе данных. Список баз данных появится в нижней части панели.

  1. Перейдите к логическому серверу на портале Azure.
  2. На левой панели навигации выберите Обзор.
  3. Прокрутите список ресурсов в нижней части панели. В окне отобразятся эластичные пулы SQL и базы данных на логическом сервере.
  4. Просмотрите столбец Ценовая категория, чтобы определить базы данных на уровне служб "Гипермасштабирование".

Дальнейшие действия

Дополнительные сведения о базах данных уровня "Гипермасштабирование" см. в следующих статьях: