Обратная миграция базы данных из Hyperscale

Применимо к: База данных SQL Azure

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

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

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

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

• Обратная миграция доступна только в течение 45 дней после первоначальной миграции в Hyperscale.
• Базы данных, изначально созданные на уровне служб гипермасштабирования, не имеют права на обратную миграцию.
• Вы можете выполнить обратную миграцию только на уровень служб общего назначения. Миграция с Hyperscale на General Purpose может быть нацелена на serverless или предоставленные уровни вычислений. Если вы хотите перенести базу данных на другой уровень вложенности, например Business Critical или на уровень вложенности на основе DTU, сначала выполните обратную миграцию на уровень вложенности общего назначения, а затем измените уровень вложенности.
• Обратная миграция в базы данных с менее чем 2 виртуальными ядрами не поддерживается. После завершения миграции база данных может уменьшиться до менее 2 виртуальных ядер.
• Прямая обратная миграция из или в пул эластичных баз данных не поддерживается. Можно отменить миграцию только одной базы данных с гипермасштабированием в одну базу данных общего назначения.
  • Если база данных Гипермасштабирования является частью эластичного пула гипермасштабирования, необходимо сначала удалить ее из эластичного пула гипермасштабирования до обратной миграции.
  • После завершения обратной миграции при необходимости можно добавить отдельную базу данных типа общего назначения в эластичный пул общего назначения.
• Для баз данных, которые не подлежат обратной миграции, единственным способом миграции с гипермасштабируемого на не гипермасштабируемый уровень служб является экспорт/импорт с использованием bacpac-файла или других технологий передачи данных (массовая копия, Azure Data Factory, Azure Databricks, SSIS и т.д.). Экспорт/импорт bacpac через портал Azure, из PowerShell с использованием New-AzSqlDatabaseExport или New-AzSqlDatabaseImport, из Azure CLI с помощью az sql db export и az sql db import, а также из REST API не поддерживается. Импорт/экспорт Bacpac для меньших баз данных Hyperscale (до 150 ГБ) поддерживается с помощью SSMS и SqlPackage версии 18.4 и более поздних версий. Для больших баз данных bacpac export/import может занять много времени и может завершиться сбоем по различным причинам.

Длительность и время простоя

В отличие от обычных операций изменения уровня обслуживания в Hyperscale, миграция на Hyperscale и обратная миграция в General Purpose — это операции с размером данных.

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

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

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

Предпосылки

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

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

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

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

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

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

Например, можно перемещаться между уровнями служб Hyperscale и обычными уровнями служб.

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

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

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

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

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

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

resourceGroupName="myResourceGroup"
serverName="server01"
databaseName="mySampleDatabase"
serviceObjective="GP_Gen5_2"
computeModel="Provisioned"

az sql db update -g $resourceGroupName -s $serverName -n $databaseName \
    --edition GeneralPurpose --service-objective $serviceObjective \
    --compute-model $computeModel

resourceGroupName="myResourceGroup"
serverName="server01"
databaseName="mySampleDatabase"
serviceObjective="GP_Gen5_2"
computeModel="Provisioned"
maxsize="200GB"

az sql db update -g $resourceGroupName -s $serverName -n $databaseName \
    --edition GeneralPurpose --service-objective $serviceObjective \
    --compute-model $computeModel --max-size $maxsize

resourceGroupName="myResourceGroup"
serverName="server01"
databaseName="mySampleDatabase"

az sql db op list -g $resourceGroupName -s $serverName -n $databaseName

$resourceGroupName = "myResourceGroup"
$serverName = "server01"
$databaseName = "mySampleDatabase"
$serviceObjective = "GP_Gen5_2"
$computeModel = "Provisioned"

Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName `
    -DatabaseName $databaseName -Edition "GeneralPurpose" -computemodel $computeModel `
    -RequestedServiceObjectiveName $serviceObjective

$resourceGroupName = "myResourceGroup"
$serverName = "server01"
$databaseName = "mySampleDatabase"
$serviceObjective = "GP_Gen5_2"
$computeModel = "Provisioned"
$maxSizeBytes = "268435456000"

Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName `
    -DatabaseName $databaseName -Edition "GeneralPurpose" -computemodel $computeModel `
    -RequestedServiceObjectiveName $serviceObjective -MaxSizeBytes $maxSizeBytes

$resourceGroupName = "myResourceGroup"
$serverName = "server01"
$databaseName = "mySampleDatabase"

Get-AzSqlDatabaseActivity -ResourceGroupName $resourceGroupName `
    -ServerName $serverName `
    -DatabaseName $databaseName

ALTER DATABASE [mySampleDatabase]
    MODIFY (EDITION = 'GeneralPurpose', SERVICE_OBJECTIVE = 'GP_Gen5_2');
GO

ALTER DATABASE [mySampleDatabase]
    MODIFY (EDITION = 'GeneralPurpose', SERVICE_OBJECTIVE = 'GP_Gen5_2', MAXSIZE = 200 GB);
GO

SELECT *
FROM sys.dm_operation_status
WHERE major_resource_id = 'mySampleDatabase'
ORDER BY start_time DESC;
GO

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

• Управление базой данных гипермасштабирования
• перевод существующей базы данных на Hyperscale