Перенос баз данных из 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 или более поздней версии (установлена).
• Подготовленный контейнер Хранилище BLOB-объектов Azure.
• Маркер безопасности подписанного URL-адреса (SAS) с разрешениями чтения и списка, созданными для контейнера служба хранилища BLOB-объекта или управляемого удостоверения, доступ к которому может получить доступ к контейнеру.
• Поместите файлы резервного копирования для отдельной базы данных в отдельную папку в учетной записи хранения с помощью структуры неструктурированных файлов (обязательно). Вложенные папки в папках базы данных не поддерживаются.

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

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

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

Рекомендации

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

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

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

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

Важно!

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

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

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

Ниже приведен пример структуры папок внутри контейнера Хранилище BLOB-объектов Azure, структура, необходимая для переноса нескольких баз данных с помощью 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>

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

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

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

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

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

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

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

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

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

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

   

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

   

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

   

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

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

   

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

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

Используйте маркер SAS или управляемое удостоверение для доступа к учетной записи Хранилище BLOB-объектов Azure.

Предупреждение

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

Маркер SAS

Создание маркера проверки подлинности SAS хранилища BLOB-объектов для LRS

Доступ к учетной записи Хранилище BLOB-объектов Azure с помощью маркера SAS.

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

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

1. В портал Azure откройте Обозреватель службы хранилища.

2. Разверните раздел Контейнеры BLOB-объектов.

3. Щелкните правой кнопкой мыши контейнер BLOB-объектов и выберите Получить подписанный URL-адрес.

   

4. Выберите период истечения срока действия маркера. Убедитесь, что маркер действителен во время миграции.

5. Выберите часовой пояс для маркера: UTC или местное время.

   Важно!

   Часовой пояс маркера и управляемого экземпляра могут быть несогласованными. Убедитесь, что маркер SAS имеет соответствующие сроки, принимая во внимание часовой пояс. Чтобы учесть различия часового пояса, задайте допустимость значения FROM до начала периода миграции, а значение TO — после завершения миграции.

6. Выберите только разрешения Read (Чтение) и List (Список).

   Важно!

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

7. Нажмите кнопку создания.

   

Проверка подлинности SAS создается с заданным допустимым периодом. Вам нужна версия URI маркера, как показано на следующем снимке экрана:

Примечание.

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

Копирование параметров из маркера SAS

Доступ к учетной записи Хранилище BLOB-объектов Azure с помощью маркера SAS или управляемого удостоверения.

Прежде чем использовать маркер SAS для запуска LRS, необходимо понять его структуру. URI созданного маркера SAS состоит из двух частей, разделенных вопросительным знаком (?), как показано в этом примере:

Первая часть, с https:// и до вопросительного знака (?), используется для параметра StorageContainerURI, который передается в качестве входных данных в LRS. Так LRS получает сведения о папке, в которой хранятся файлы резервной копии базы данных.

Вторая часть, начиная с знака вопроса (?) через конец строки, является параметром StorageContainerSasToken . Эта часть является фактическим подписанным маркером проверки подлинности, допустимым в течение указанного времени. Эта часть не обязательно должна начинаться, sp= как показано в примере. Сценарий может отличаться.

Скопируйте параметры следующим образом:

1. Скопируйте первую часть маркера, https:// не включая вопросительный знак (?). Используйте его в качестве StorageContainerUri параметра в PowerShell или Azure CLI при запуске LRS.

   

2. Скопируйте вторую часть маркера после знака вопроса (?) до конца строки. Используйте его в качестве StorageContainerSasToken параметра в PowerShell или Azure CLI при запуске LRS.

   

Примечание.

Не включайте вопросительный знак (?) при копировании любой части маркера.

Управляемое удостоверение

Чтобы использовать управляемое удостоверение, назначьте управляемое системой или управляемое пользователем удостоверение для доступа к контейнеру Хранилище BLOB-объектов Azure.

Для этого выполните следующие шаги:

1. В портал Azure перейдите к учетной записи служба хранилища BLOB-объектов, к которой планируется авторизовать доступ к управляемому экземпляру.
2. Выберите Управление доступом (IAM) .
3. Выберите Добавить, затем выберите Добавить назначение ролей.
4. Найдите и выберите существующую роль, служба хранилища средство чтения данных BLOB-объектов. Пользовательские роли поддерживаются до тех пор, пока у них есть разрешения на чтение и список, как минимум.
5. Выберите управляемое удостоверение.
6. Используйте параметр "Выбрать участников", чтобы определить подписку.
7. В раскрывающемся списке управляемых удостоверений выберите Управляемый экземпляр SQL, а затем выберите управляемый экземпляр, на который планируется перенести.
8. Выберите "Выбрать ", чтобы сохранить параметры и авторизовать доступ.
9. Завершите процесс, нажав кнопку "Проверить и назначить".

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

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

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

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

Маркер SAS

Если вы используете маркер SAS для проверки подлинности в учетной записи хранения, замените <sastoken> маркер SAS и выполните следующий запрос в вашем экземпляре:

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' 

Управляемое удостоверение

Если вы используете управляемое удостоверение для проверки подлинности в учетной записи хранения, обновите CREATE CREDENTIAL url-адрес учетной записи хранения и выполните следующий пример запроса в вашем экземпляре:

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 непосредственно в учетную запись большого двоичного объекта служба хранилища с помощью команды BACKUP TO URL- адреса, если ваша среда позволяет ей (начиная с SQL Server версии 2012 с пакетом обновления 1 (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-объектов

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

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

Примечание.

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

Создание резервных копий непосредственно в учетной записи служба хранилища BLOB-объектов

Если вы используете поддерживаемую версию SQL Server (начиная с SQL Server 2012 с пакетом обновления 1 (SP1) и SQL Server 2014, а корпоративные и сетевые политики позволяют выполнять резервные копии из SQL Server непосредственно в учетную запись БОЛЬШОго двоичного объекта служба хранилища с помощью собственного параметра РЕЗЕРВНОго копирования SQL Server TO URL-адреса. Если вы можете использоватьBACKUP TO URL, вам не нужно принимать резервные копии в локальное хранилище и отправлять их в учетную запись служба хранилища BLOB-объектов.

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

Используйте следующую команду, чтобы создать учетные данные, импортируемые маркерОМ 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-объектов можно использовать команду 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. Службу можно запустить в автоматическом или непрерывном режиме.

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

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

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

Примечание.

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

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

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

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

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

Важно!

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

Маркер SAS

Следующий пример PowerShell запускает LRS в режиме автозаполнения с помощью маркера 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"

Следующий пример Azure CLI запускает LRS в режиме автозаполнения с помощью маркера SAS:

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"

Управляемое удостоверение

Следующий пример PowerShell запускает LRS в режиме автозаполнения с помощью управляемого удостоверения:

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.

Важно!

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

Маркер SAS

Следующий пример PowerShell запускает LRS в непрерывном режиме с помощью маркера 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"

Следующий пример Azure CLI запускает LRS в непрерывном режиме:

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"

Управляемое удостоверение

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

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, чтобы сообщить об успешном или неудачном выполнении задания.

В ходе этого ожидания команда не будет возвращать управление командной строке. Если вы выполняете скрипты для миграции, и вам нужна команда запуска 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 и более поздних версий предоставляет подробный отчет о ходе выполнения. Просмотрите сведения о восстановлении управляемой базы данных. Получите пример выходных данных.

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

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

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

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

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

Если необходимо остановить миграцию, используйте 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 используйте любой из следующих командлетов мониторинга, чтобы просмотреть состояние операции:

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

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

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

Следующие шаги

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