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

Внимание

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

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

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

Ниже приведен пример структуры папок внутри контейнера Хранилище 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.Storage в раскрывающемся списке "Службы ".

   

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 непосредственно в учетную запись хранения BLOB-объектов с помощью команды 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 непосредственно в учетную запись хранения BLOB-объектов с помощью собственного параметра РЕЗЕРВНОго копирования SQL Server TO URL-адрес . Если вы можете использовать BACKUP TO URL, вам не нужно принимать резервные копии в локальное хранилище и отправлять их в учетную запись хранения BLOB-объектов.

При выполнении собственных резервных копий непосредственно в учетную запись хранения 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. Службу можно запустить в автоматическом или непрерывном режиме.

При использовании режима автозаполнения миграция завершается автоматически после восстановления последних указанных файлов резервной копии. Этот параметр требует предварительной доступности всей цепочки резервных копий и отправки в учетную запись хранения BLOB-объектов. Он не позволяет добавлять новые файлы резервного копирования во время миграции. Для этого параметра требуется 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 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 включенным.
• Маркер подписанного URL-адреса (SAS), который использует LRS, должен быть создан для всего контейнера Хранилище BLOB-объектов Azure, и он должен иметь Read только List разрешения. Например, если вы предоставляете и ListWrite разрешенияRead, LRS не запускается из-за дополнительного Write разрешения.
• Использование маркеров SAS, созданных с разрешениями, заданными путем определения хранимой политики доступа, не поддерживается. Следуйте инструкциям в этой статье, чтобы вручную задать разрешения на чтение и перечисление для маркера SAS.
• Файлы резервного копирования для разных баз данных необходимо разместить в отдельных папках в учетной записи хранения BLOB-объектов в структуре неструктурированных файлов. Вложенные папки в папках базы данных не поддерживаются.
• Если вы используете режим автозаполнения, вся цепочка резервных копий должна быть доступна заранее в учетной записи хранения BLOB-объектов. Невозможно добавить новые файлы резервного копирования в режим автозаполнения. Используйте непрерывный режим, если необходимо добавить новые файлы резервной копии во время миграции.
• Необходимо запустить LRS отдельно для каждой базы данных, которая указывает на полный путь URI, содержащий отдельную папку базы данных.
• Путь URI резервного копирования, имя контейнера или имена папок не должны содержать backup или backups как это зарезервированные ключевые слова.
• При запуске нескольких операций воспроизведения журналов параллельно нацеливается на один и тот же контейнер хранилища, убедитесь, что для каждой операции восстановления предоставляется один и тот же действительный маркер SAS.
• LRS может поддерживать до 100 процессов одновременного восстановления на один управляемый экземпляр.
• Одно задание LRS может выполняться не более 30 дней, после чего оно будет автоматически отменено.
• Хотя можно использовать учетную запись служба хранилища Azure за брандмауэром, необходима дополнительная конфигурация, а учетная запись хранения и управляемый экземпляр должны находиться в одном регионе или в двух парных регионах. Дополнительные сведения см. в статье "Настройка брандмауэра ".
• Максимальное количество баз данных, которые можно восстановить параллельно, составляет 200 на одну подписку. В некоторых случаях это ограничение можно увеличить, открыв запрос в службу поддержки.
• Отправка тысяч файлов базы данных для восстановления может привести к чрезмерному времени миграции и даже сбою. Консолидируйте базы данных в меньшем количестве файлов, чтобы ускорить процесс миграции и убедиться, что это успешно.

Примечание.

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

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

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

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

Внимание

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

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

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

Миграция на Управляемый экземпляр 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 и маркера SAS, могут возникнуть несоответствия. Попробуйте повторно создать маркер SAS и продлить срок действия маркера временного окна до и после текущей даты.
• При запуске нескольких операций воспроизведения журналов параллельно нацеливается на один контейнер хранилища, убедитесь, что для каждой операции восстановления предоставляется один и тот же действительный маркер SAS.
• Правильно ли написаны имя базы данных, имя группы ресурсов и имя управляемого экземпляра?
• Если вы запустили LRS в режиме автозаполнения, было допустимым именем файла для последнего файла резервной копии?
• Содержит ли путь URI резервного копирования ключевых слов backup или backups? Переименуйте контейнер или папки, использующие backup или backups как они являются зарезервированными ключевыми словами.

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

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