Перенос баз данных из SQL Server с помощью службы воспроизведения журналов — Управляемый экземпляр SQL Azure

Область применения: Управляемый экземпляр SQL Azure

В этой статье объясняется, как перенести базы данных в Управляемый экземпляр SQL Azure с помощью службы воспроизведения журналов (LRS). LRS — это бесплатная облачная служба, доступная для Управляемый экземпляр SQL Azure на основе технологии доставки журналов SQL Server.

Поддерживаются следующие источники:

• SQL Server на виртуальных машинах
• Amazon EC2 (эластичное вычислительное облако)
• Amazon RDS (реляционная служба баз данных) для SQL Server
• Google Compute Engine
• Cloud SQL для SQL Server — GCP (Google Cloud Platform)

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

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

SQL Server

Убедитесь, что выполнены следующие требования для SQL Server:

• SQL Server версии 2008–2022.
• База данных SQL Server использует модель полного восстановления (обязательно).
• Полная резервная копия баз данных (один или несколько файлов).
• Разностная резервная копия (один или несколько файлов).
• Резервная копия журнала (без разделения на файл журнала транзакций).
• Для SQL Server версий 2008–2016 выполните резервную копию локально и вручную отправьте ее в учетную запись Хранилище BLOB-объектов Azure.
• Для SQL Server 2016 и более поздних версий вы можете сделать резервную копию прямо в учётную запись хранилища Blob Azure.
• Хотя включение CHECKSUM резервного копирования не требуется, настоятельно рекомендуется предотвратить непреднамеренный перенос поврежденной базы данных и ускорить операции восстановления.

Azure

Убедитесь, что выполнены следующие требования для Azure:

• Модуль PowerShell Az.SQL версии 4.0.0.0 или более поздней версии (установлен или доступ к ней через Azure Cloud Shell).
• Azure CLI версии 2.42.0 или более поздней версии (установлена).
• Подготовленный контейнер Azure Blob Storage.
• Маркер безопасности подписанного доступа (SAS) с Read и List разрешениями, созданными для контейнера хранилища BLOB-объектов, или управляемое удостоверение, которое может получить доступ к контейнеру. Предоставление дополнительных разрешений, чем Read и List приведет к сбою LRS.
• Поместите файлы резервного копирования для отдельной базы данных в отдельную папку в учетной записи хранения с помощью структуры неструктурированных файлов (обязательно). Вложенные папки в папках базы данных не поддерживаются.

Разрешения RBAC в Azure

Для запуска LRS с помощью предоставленных клиентов требуется одна из следующих ролей управления доступом на основе ролей Azure (RBAC):

• роль участника Управляемого экземпляра SQL.
• Роль со следующим разрешением: Microsoft.Sql/managedInstances/databases/*

Наилучшие практики

При использовании LRS рассмотрите следующие рекомендации.

• Запустите Помощник по миграции данных, чтобы убедиться, что ваши базы данных готовы к миграции в Управляемый экземпляр SQL.
• Разделите полные и разностные резервные копии на несколько файлов вместо использования одного файла.
• Включите сжатие резервных копий, чтобы ускорить передачу данных по сети.
• Используйте Cloud Shell для запуска скриптов PowerShell или CLI, так как он всегда обновляется до последней версии командлетов.
• Настройте период обслуживания, чтобы обновления системы планировали в определенный день и время вне окна миграции, чтобы предотвратить задержку или прерывание миграции.
• Запланируйте выполнение одного задания миграции LRS в течение не более 30 дней. По истечении этого периода времени задание LRS автоматически отменяется.
• Чтобы предотвратить непреднамеренный перенос поврежденной базы данных и ускорить восстановление базы данных, включите CHECKSUM при создании резервных копий. Хотя Управляемый экземпляр SQL выполняет базовую проверку целостности резервных копий без CHECKSUM, перехват всех форм повреждения не гарантируется. Создание резервных CHECKSUM копий — единственный способ гарантировать, что восстановленные резервные копии на Управляемом экземпляре SQL не повреждены. Базовая проверка целостности резервных копий без CHECKSUM увеличивает время восстановления базы данных.
• При миграции на уровень службы критически важный для бизнеса учитывайте длительную задержку в доступности базы данных после переключения, когда базы данных реплицируются на вторичные реплики. Для особенно больших баз данных с минимальными требованиями к времени простоя рекомендуется сначала перейти на уровень служб общего назначения, а затем перейти на критически важный для бизнеса уровень служб или использовать ссылку на Управляемый экземпляр для переноса ваших данных.
• Отправка тысяч файлов базы данных для восстановления может привести к чрезмерному времени миграции и даже сбою. Консолидируйте базы данных в меньшее количество файлов, чтобы ускорить процесс миграции и обеспечить его успех.
• Чтобы свести к минимуму время переключения и снизить риск сбоя, убедитесь, что последняя резервная копия максимально мала.

Настройка периода обслуживания

Обновления системы для Управляемый экземпляр SQL имеют приоритет над миграцией баз данных.

Миграция влияет по-разному на уровне служб:

• На уровне служб общего назначения все ожидающие миграции LRS приостановлены и возобновляются только после применения обновления. Это поведение системы может продлить время миграции, особенно для больших баз данных.
• В уровне службы Критически важные для бизнеса все ожидающие миграции LRS отменяются и автоматически перезапускаются после применения обновления. Это поведение системы может продлить время миграции, особенно для больших баз данных.

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

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

Перенос нескольких баз данных

При переносе нескольких баз данных с помощью одного и того же контейнера Хранилище BLOB-объектов Azure необходимо разместить файлы резервного копирования для разных баз данных в отдельных папках в контейнере. Все файлы резервной копии для одной базы данных должны быть помещены в структуру неструктурированных файлов в папку базы данных, а папки не могут быть вложенными. Вложенные папки в папках базы данных не поддерживаются.

Ниже приведен пример структуры папок внутри контейнера Azure Blob Storage, необходимой для миграции нескольких баз данных с помощью LRS.

-- Place all backup files for database 1 in a separate "database1" folder in a flat-file structure.
-- Don't use nested folders inside the database1 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database1>/<all-database1-backup-files>

-- Place all backup files for database 2 in a separate "database2" folder in a flat-file structure.
-- Don't use nested folders inside the database2 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database2>/<all-database2-backup-files>

-- Place all backup files for database 3 in a separate "database3" folder in a flat-file structure. 
-- Don't use nested folders inside the database3 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database3>/<all-database3-backup-files>

Создание учетной записи хранилища

Вы используете учетную запись Azure Blob Storage в качестве промежуточного хранилища для файлов резервного копирования между экземпляром SQL Server и развертыванием управляемого экземпляра SQL Server. Чтобы создать новую учетную запись хранения и контейнер BLOB в этой учетной записи:

1. Создание учетной записи хранения.
2. Создайте контейнер BLOB в аккаунте хранения.

Настройка хранилища Azure за брандмауэром

Использование хранилища BLOB-объектов Azure, защищенного брандмауэром, поддерживается, но требует дополнительной настройки. Чтобы включить доступ на чтение и запись к Azure Storage с включенным Azure Firewall, необходимо добавить подсеть управляемого экземпляра SQL в правила брандмауэра виртуальной сети для учетной записи хранения с помощью делегирования подсети SQL управляемого экземпляра и конечной точки службы Storage. Учетная запись хранения и управляемый экземпляр должны находиться в одном регионе или в двух связанных регионах.

Если хранилище Azure находится за брандмауэром, в журнале ошибок управляемого экземпляра SQL может появиться следующее сообщение:

Audit: Storage access denied user fault. Creating an email notification:

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

Чтобы настроить брандмауэр, выполните следующие действия.

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

   

2. На странице "Подсети" выберите имя подсети, чтобы открыть страницу конфигурации подсети.

   

3. В разделе Делегирование подсети выберите Microsoft.Sql/managedInstances из раскрывающегося списка делегировать подсеть службе. Подождите около часа для распространения разрешений, а затем в разделе "Конечные точки службы" выберите Microsoft.Storage в раскрывающемся списке "Службы ".

   

4. Затем перейдите к учетной записи хранения в портал Azure, выберите "Сеть" в разделе "Безопасность и сеть", а затем перейдите на вкладку "Брандмауэры и виртуальные сети".

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

   

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

Проверка подлинности в учетной записи хранения BLOB-объектов

Используйте маркер SAS или управляемое удостоверение для доступа к учетной записи хранилища Blob в Azure.

Подтвердите доступ к хранилищу управляемого экземпляра

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

Сначала отправьте любую резервную копию базы данных, например full_0_0.bakв контейнер Хранилище BLOB-объектов Azure.

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

CREATE CREDENTIAL [https://mitutorials.blob.core.windows.net/databases] 
WITH IDENTITY = 'SHARED ACCESS SIGNATURE' 
, SECRET = '<sastoken>' 

RESTORE HEADERONLY 
FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/full_0_0.bak' 

RESTORE HEADERONLY 
FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/full_0_0.bak' 

CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<containername>] 
WITH IDENTITY = 'MANAGED IDENTITY' 

Загрузка резервных копий в учетную запись хранилища Blob

Когда контейнер BLOB-объектов готов, и вы подтвердили, что управляемый экземпляр может получить доступ к контейнеру, вы можете начать отправку резервных копий в учетную запись хранения BLOB-объектов. Вы можете сделать одно из двух:

• Скопируйте резервные копии в учетную запись хранилища Blob.
• Резервное копирование из SQL Server непосредственно в учетную запись Blob-хранилища с помощью команды BACKUP TO URL, если ваша среда это позволяет (начиная с SQL Server версии 2012 SP1 и SQL Server 2014).

Скопируйте существующие резервные копии в учетную запись Blob-хранилища

Если вы используете более раннюю версию SQL Server или если ваша среда не поддерживает резервное копирование непосредственно на URL-адрес, создайте резервные копии на экземпляре SQL Server, как вы обычно это делаете, и скопируйте их в учетную запись хранилища Blob.

Создание резервных копий в экземпляре SQL Server

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

-- To permit log backups, before the full database backup, modify the database to use the full recovery
USE master
ALTER DATABASE SampleDB
SET RECOVERY FULL
GO

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

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

-- Take full database backup to local disk
BACKUP DATABASE [SampleDB]
TO DISK='C:\BACKUP\SampleDB_full.bak'
WITH INIT, COMPRESSION, CHECKSUM
GO

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

-- Take differential database backup to local disk
BACKUP DATABASE [SampleDB]
TO DISK='C:\BACKUP\SampleDB_diff.bak'
WITH DIFFERENTIAL, COMPRESSION, CHECKSUM
GO

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

-- Take transactional log backup to local disk
BACKUP LOG [SampleDB]
TO DISK='C:\BACKUP\SampleDB_log.trn'
WITH COMPRESSION, CHECKSUM
GO

Копирование резервных копий в учетную запись Blob Storage

После подготовки резервных копий и вы хотите начать перенос баз данных в управляемый экземпляр с помощью LRS, можно использовать следующие подходы для копирования существующих резервных копий в учетную запись хранения BLOB-объектов:

• Скачайте и установите AzCopy.
• Скачайте и установите Обозреватель службы хранилища Azure.
• Используйте Обозреватель хранилища в портале Azure.

Создание резервных копий непосредственно в учетную запись Blob Storage

Если вы используете поддерживаемую версию SQL Server (начиная с SQL Server 2012 SP1 CU2 и SQL Server 2014), и ваши корпоративные и сетевые политики позволяют это, вы можете выполнять резервное копирование из SQL Server непосредственно в свою учетную запись Blob Storage, используя параметр SQL Server BACKUP TO URL. Если вы можете использовать BACKUP TO URL, вам не нужно создавать резервные копии на локальном хранилище и загружать их в учетную запись облачного хранилища.

При выполнении нативных резервных копий непосредственно в учетную запись Blob Storage необходимо пройти аутентификацию в учетной записи.

Используйте следующую команду, чтобы создать учетные данные, которые импортируют токен SAS в экземпляр SQL Server.

CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<containername>] 
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',  
SECRET = '<SAS_TOKEN>';  

Для подробных инструкций по работе с маркерами SAS просмотрите руководство по использованию хранилища BLOB-объектов Azure вместе с SQL Server.

После создания учетных данных для проверки подлинности экземпляра SQL Server с Blob Storage, вы можете использовать команду BACKUP TO URL для резервного копирования непосредственно в учетную запись хранения. CHECKSUM рекомендуется, но не требуется.

В следующем примере выполняется полное резервное копирование базы данных на URL-адрес:

-- Take a full database backup to a URL
BACKUP DATABASE [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_full.bak'
WITH INIT, COMPRESSION, CHECKSUM
GO

В следующем примере выполняется разностное резервное копирование базы данных на URL-адрес:

-- Take a differential database backup to a URL
BACKUP DATABASE [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_diff.bak'  
WITH DIFFERENTIAL, COMPRESSION, CHECKSUM
GO

В следующем примере выполняется резервное копирование журнала транзакций на URL-адрес:

-- Take a transactional log backup to a URL
BACKUP LOG [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_log.trn'  
WITH COMPRESSION, CHECKSUM

Войдите в Azure и выберите подписку

Используйте следующий командлет PowerShell для входа в Azure:

Login-AzAccount

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

Select-AzSubscription -SubscriptionId <subscription ID>

Начало миграции

Запустите миграцию, запуская LRS. Службу можно запустить в режиме автозаполнения или непрерывном режиме.

При использовании режима автозаполнения миграция завершается автоматически после восстановления последних указанных файлов резервной копии. Этот параметр требует, чтобы вся цепочка резервных копий была доступна заранее и загружена в вашу учетную запись хранилища Blob. Он не позволяет добавлять новые файлы резервного копирования во время миграции. Для этого параметра требуется start команда, чтобы указать имя файла последней резервной копии. Мы рекомендуем этот режим для пассивных рабочих нагрузок, для которых не требуется перехват данных.

При использовании непрерывного режима служба постоянно сканирует папку Хранилище BLOB-объектов Azure и восстанавливает все новые файлы резервной копии, добавленные во время миграции. Миграция завершается только после запроса на переход вручную. Необходимо использовать непрерывную миграцию, если у вас нет всей цепочки резервных копий заранее, а также при планировании добавления новых файлов резервного копирования после выполнения миграции. Этот режим рекомендуется для активных рабочих нагрузок, для которых требуется перехват данных.

Запланируйте выполнение одного задания миграции LRS в течение не более 30 дней. По истечении этого времени задание LRS автоматически отменяется.

Запуск LRS в режиме автозавершения

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

Чтобы запустить LRS в режиме автозавершения, используйте команды PowerShell или Azure CLI. Укажите имя последнего файла резервной копии с помощью параметра -LastBackupName. После завершения восстановления последнего указанного файла резервной копии служба автоматически инициирует переключение.

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

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" `
    -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerSasToken "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D" `
    -AutoCompleteRestore `
    -LastBackupName "last_backup.bak"

az sql midb log-replay start -g mygroup --mi myinstance -n mymanageddb -a --last-bn "backup.bak"
    --storage-uri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>"
    --storage-sas "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" `
    -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerIdentity ManagedIdentity  `
    -AutoCompleteRestore `
    -LastBackupName "last_backup.bak"

Запуск LRS в непрерывном режиме

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

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerSasToken "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

az sql midb log-replay start -g mygroup --mi myinstance -n mymanageddb
    --storage-uri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>"
    --storage-sas "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerIdentity ManagedIdentity

Написание сценария задания миграции

Клиенты PowerShell и Azure CLI, запускающие LRS в непрерывном режиме, синхронны. В этом режиме PowerShell и Azure CLI ожидают получения ответа от API о том, успешно или безуспешно выполнено действие, перед тем как начать выполнение задания.

В ходе этого ожидания команда не будет возвращать управление командной строке. Если вы создаете сценарии для миграции и вам необходимо, чтобы команда Start-LRS немедленно возвращала управление для продолжения работы с остальной частью сценария, вы можете запустить PowerShell в фоновом режиме с параметром -AsJob. Например:

$lrsjob = Start-AzSqlInstanceDatabaseLogReplay <required parameters> -AsJob

При запуске фонового задания объект задания возвращается немедленно, даже если для выполнения задания требуется более длительное время. Пока задание выполняется, можно продолжать работу в сеансе. Дополнительные сведения о запуске PowerShell в качестве фонового задания см. в документации по Началу работы с PowerShell .

Аналогично, чтобы запустить команду Azure CLI в Linux в качестве фонового процесса, используйте амперсанд (&) в конце команды запуска LRS:

az sql midb log-replay start <required parameters> &

Контроль за ходом миграции

Az.SQL 4.0.0 и более поздних версий предоставляет подробный отчет о ходе выполнения. Просмотрите Managed Database Restore Details - Get для примера выходных данных.

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

Get-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName"

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

az sql midb log-replay show -g mygroup --mi myinstance -n mymanageddb

Чтобы отслеживать дополнительные сведения о неудачном запросе, используйте команду PowerShell Get-AzSqlInstanceOperation или используйте команду Azure CLI az sql mi op show.

Остановка миграции (необязательно)

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

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

Stop-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName"

Чтобы остановить процесс миграции с помощью Azure CLI, используйте следующую команду:

az sql midb log-replay stop -g mygroup --mi myinstance -n mymanageddb

Завершение миграции (непрерывный режим)

Если вы запускаете LRS в непрерывном режиме, убедитесь, что рабочие нагрузки приложения и SQL Server были остановлены, чтобы предотвратить создание новых файлов резервной копии. Убедитесь, что последняя резервная копия из экземпляра SQL Server была отправлена в учетную запись хранилища Blob-объектов Azure. Отслеживайте ход восстановления управляемого экземпляра и убедитесь, что последняя резервная копия хвоста журнала восстановлена.

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

Чтобы завершить процесс миграции в непрерывном режиме LRS с помощью PowerShell, используйте следующую команду:

Complete-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName" `
-LastBackupName "last_backup.bak"

Чтобы завершить процесс миграции в непрерывном режиме LRS с помощью Azure CLI, используйте следующую команду:

az sql midb log-replay complete -g mygroup --mi myinstance -n mymanageddb --last-backup-name "backup.bak"

Ограничения

При миграции с помощью LRS следует учитывать следующие ограничения:

• Вы не можете использовать базы данных, которые восстанавливаются с помощью LRS, пока процесс миграции не завершится.
• Во время процесса миграции базы данных, которые переносятся, не могут быть использованы для доступа только для чтения в Управляемый экземпляр SQL.
• После завершения миграции процесс миграции будет окончательным и не может быть возобновлен с дополнительными разностными резервными копиями.
• Поддерживаются только файлы базы данных .bak, .log и .diff LRS. Dacpac и bacpac-файлы не поддерживаются.
• Необходимо настроить период обслуживания для планирования обновлений системы в определенный день и время. Запланируйте выполнение и завершение миграции за пределами запланированного периода обслуживания.
• Резервные копии базы данных, которые выполняются без CHECKSUM:
  • может перенести потенциально поврежденные базы данных.
  • требуется больше времени для восстановления, чем резервные копии баз данных с CHECKSUM включенным.
• Токен с подписью общего доступа (SAS), который использует LRS, должен быть создан для всего контейнера BLOB-объектов Azure, и должен иметь только разрешения Read и List. Например, если вы предоставляете разрешения Read, List и Write, LRS не запускается из-за дополнительного разрешения Write.
• Использование маркеров SAS, созданных с разрешениями, заданными путем определения хранимой политики доступа, не поддерживается. Следуйте инструкциям в этой статье, чтобы вручную задать разрешения на прочтение и список для токена SAS.
• Файлы резервного копирования для разных баз данных нужно поместить в отдельные папки учетной записи Blob-хранилища, в плоской файловой структуре. Вложение папок внутри папок базы данных не поддерживается.
• Если вы используете режим автозаполнения, вся цепочка резервных копий должна быть заранее доступна в учетной записи Blob Storage. Невозможно добавить новые файлы резервного копирования в режим автозаполнения. Используйте непрерывный режим, если необходимо добавить новые файлы резервной копии во время миграции.
• Необходимо запустить LRS отдельно для каждой базы данных, которая указывает на полный путь URI, содержащий отдельную папку базы данных.
• Путь к резервному коду ресурса (URI), имя контейнера или имена папок не могут содержать backup или Backup как это зарезервированные ключевые слова.
• При запуске нескольких операций воспроизведения журналов в параллельном режиме, ориентируясь на один и тот же контейнер хранилища, убедитесь, что для каждой операции восстановления предоставляется один и тот же действительный маркер SAS.
• LRS может поддерживать до 100 процессов одновременного восстановления на один управляемый экземпляр.
• Одно задание LRS может выполняться не более 30 дней, после чего оно будет автоматически отменено.
• Хотя можно использовать учетную запись хранилища Azure за брандмауэром, необходима дополнительная конфигурация. Также учетная запись хранилища и управляемый экземпляр должны находиться в одном регионе или в двух взаимосвязанных регионах. Дополнительные сведения см. в статье "Настройка брандмауэра ".
• Максимальное количество баз данных, которые можно восстановить параллельно, составляет 200 на одну подписку. В некоторых случаях это ограничение можно увеличить, открыв запрос в службу поддержки.
• Отправка тысяч файлов базы данных для восстановления может привести к чрезмерному времени миграции и даже сбою. Консолидируйте базы данных в меньшее количество файлов, чтобы ускорить процесс миграции и обеспечить его успех.
• Существуют два сценария в начале и в конце процесса миграции, при которых миграция прерывается в случае отказа, и задание миграции должно быть перезапущено вручную, так как база данных удаляется из управляемого экземпляра SQL.
  • Если при первом запуске задания миграции отработка отказа происходит в то время, когда первая полная резервная копия базы данных находится в процессе восстановления в Управляемом экземпляре SQL, задание миграции должно быть перезапущено вручную с самого начала.
  • Если переключение на резерв происходит после начала переключения миграции, задание миграции нужно вручную перезапустить с самого начала. Убедитесь, что последний файл резервной копии максимально мал, чтобы свести к минимуму время переключения и снизить риск отказа системы во время процесса переключения.

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

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

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

Более длительный переход на уровне обслуживания Business Critical

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

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

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

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

Устранение неполадок LRS

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

• Для PowerShell: get-azsqlinstancedatabaselogreplay
• Для Azure CLI: az_sql_midb_log_replay_show

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

• Для PowerShell: Get-AzSqlInstanceOperation
• Для Azure CLI: az sql mi op show

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

• Совпадает ли название существующей базы данных в вашем управляемом экземпляре с названием той, которую вы пытаетесь перенести из экземпляра SQL Server? Устраните этот конфликт, переименовав одну из баз данных.
• Предоставляются ли разрешения только для маркера SAS для чтения и списка? Предоставление дополнительных разрешений, чем Read и List приведет к сбою LRS.
• Вы скопировали токен SAS для LRS после знака вопроса (?) с содержимым, похожим на sv=2020-02-10...?
• Подходит ли срок действия маркера SAS для периода времени начала и завершения миграции? Из-за разных часовых поясов, используемых для развертывания SQL Managed Instance и создания токена SAS, могут возникнуть несоответствия. Попробуйте повторно создать токен SAS и продлить срок его действия в пределах временного окна до и после текущей даты.
• При параллельном запуске нескольких операций восстановления журнала, нацеленных на один и тот же контейнер хранилища, убедитесь, что для каждой операции используется один и тот же действительный маркер SAS.
• Правильно ли написаны имя базы данных, имя группы ресурсов и имя управляемого экземпляра?
• Указано ли допустимое имя файла для последнего файла резервной копии, если вы запустили LRS в режиме автозаполнения?
• Содержит ли путь URI резервного копирования ключевых слов backup или backups? Переименуйте контейнер или папки, использующие backup или backups как они являются зарезервированными ключевыми словами.

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

• Обзор службы воспроизведения журналов.
• Миграция в Управляемый экземпляр SQL Azure с помощью функции ссылки.
• Миграция из SQL Server в Управляемый экземпляр SQL Azure.
• Различия между SQL Server и управляемым экземпляром SQL.
• Рекомендации по затратам и размерам рабочих нагрузок, перенесенных в Azure.
• Сравнение LRS со ссылкой управляемого экземпляра для миграции