Подготовка среды для миграции LRS — миграции SQL Server на Azure Arc

Применимо к:SQL Server

Эта статья поможет вам подготовить среду для миграции с использованием Log Replay Service (LRS) для экземпляра SQL Server, подключенного Azure Arc, в Azure SQL Managed Instance на портале Azure.

С помощью LRS можно перенести базы данных SQL Server в Azure SQL Managed Instance с помощью резервного копирования и восстановления с помощью доставки журналов (онлайн-миграция):

Предпосылки

Чтобы перенести базы данных SQL Server в Azure SQL Managed Instance на портале Azure, необходимо выполнить следующие предварительные требования:

• Активная подписка Azure. Если ее нет, создайте бесплатную учетную запись.
• Поддерживаемый экземпляр SQL Server, включенный с помощью Azure Arc, с последней версией расширения Azure для SQL Server. Сведения об обновлении расширения см. в статье об обновлении расширения.

Поддерживаемые версии SQL Server

Миграция с помощью LRS работает с каждым выпуском SQL Server на Windows. Хотя миграция на уровни служб "Общего назначения" и "Бизнес-критичный" для SQL Managed Instance поддерживается, миграция непосредственно на уровень служб "Бизнес-критичный" имеет некоторые важные ограничения.

В следующей таблице перечислены минимальные поддерживаемые версии SQL Server для LRS:

Обратная миграция поддерживается только для SQL Server 2025 и SQL Server 2022 из управляемых экземпляров SQL с соответствующей политикой update. Вы можете вручную отменить миграцию с помощью других средств, таких как собственное резервное копирование и восстановление, или вручную настроить ссылку в SSMS.

Permissions

В этом разделе описываются разрешения, необходимые для переноса экземпляра SQL Server на SQL Managed Instance через портал Azure.

В исходном SQL Server экземпляре требуются следующие разрешения:

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

Чтобы выполнить миграцию с помощью LRS, вам потребуется одно из следующих разрешений для целевого объекта SQL Managed Instance:

• роль SQL Managed Instance участника
• Роль со следующим разрешением: Microsoft.Sql/managedInstances/databases/*

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

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

Чтобы создать новую учетную запись хранения и контейнер BLOB в этой учетной записи:

1. Создайте учетную запись хранения:
   1. Найдите учетные записи Storage на портале Azure и выберите Create.
   2. На вкладке "Основные сведения" выберите подписку и группу ресурсов. Регион должен совпадать с вашим целевым объектом SQL Managed Instance.
   3. Оставьте предпочтительный тип хранилища пустым.
   4. Используйте параметры по умолчанию для остальных вкладок и выберите "Просмотр и создание".
   5. После прохождения проверки выберите Создать.
2. Создайте контейнер BLOB в аккаунте хранения.
   1. Перейдите к новой учетной записи хранения на портале Azure.
   2. В разделе Хранилище данных выберите Контейнеры.
   3. Используйте Добавить контейнер, чтобы открыть панель Новый контейнер.
   4. Введите имя контейнера, оставьте параметры по умолчанию и нажмите кнопку "Создать ", чтобы создать контейнер.
3. (Необязательно) Если ваше хранилище Azure находится за брандмауэром, то хранилище Blob в Azure требует дополнительной настройки после подготовки управляемого экземпляра SQL.

Предоставление разрешений для Azure Blob Storage

Миграция SQL Server в Azure Arc с использованием LRS использует управляемое удостоверение для проверки подлинности в сервисе Azure Blob Storage.

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

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

Предоставление пользователю доступа к учетной записи хранения

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

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

1. На портале Azure перейдите в группу ресурсов, содержащую учетную запись хранения.

2. Выберите элемент управления доступом (IAM) в меню ресурсов.

3. Используйте + Add, чтобы выбрать Добавить назначение ролей и открыть область Добавить назначение ролей.

4. Найдите и выберите роль Storage Blob Data Reader. Затем выберите Далее.

   

5. Используйте +Выберите участников, чтобы открыть область Выберите участников и найдите учетную запись пользователя, выполняющего миграцию. Если несколько пользователей переносят данные, предоставьте всем этим пользователям этот доступ. Выберите учетную запись пользователя и нажмите кнопку "Выбрать ", чтобы сохранить выбранный вариант. Проверьте параметр назначения доступа пользователю , группе или субъекту-службе.

6. Выберите "Проверка и назначение ", чтобы перейти на вкладку "Рецензирование и назначение ", а затем нажмите кнопку "Проверить и назначить еще раз", чтобы завершить назначение роли.

Предоставление пользователю доступа к группе ресурсов

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

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

1. На портале Azure перейдите в группу ресурсов, содержащую учетную запись хранения.

2. Выберите элемент управления доступом (IAM) в меню ресурсов.

3. Используйте + Add, чтобы выбрать Добавить назначение ролей и открыть область Добавить назначение ролей.

4. Найдите и выберите роль читателя . Затем выберите Далее.

   

5. Используйте +Выберите участников, чтобы открыть область Выберите участников и найдите учетную запись пользователя, выполняющего миграцию. Если несколько пользователей переносят данные, предоставьте всем этим пользователям этот доступ. Выберите учетную запись пользователя и нажмите кнопку "Выбрать ", чтобы сохранить выбранный вариант. Установите флажок, чтобы назначить доступ пользователю, группе или субъекту-службе, а затем нажмите Далее.

6. На вкладке Тип назначения установите Тип назначения на Активный, а длительность назначения на Постоянный:

   

7. Выберите "Проверка и назначение ", чтобы перейти на вкладку "Рецензирование и назначение ", а затем нажмите кнопку "Проверить и назначить еще раз", чтобы завершить назначение роли.

Предоставление управляемому удостоверению доступа к учетной записи хранения

После подготовки управляемого экземпляра SQL необходимо назначить управляемой идентификации этого экземпляра роль Storage Blob Data Reader, чтобы экземпляр мог получить доступ к учетной записи хранилища BLOB Azure во время миграции.

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

1. Перейдите к управляемому экземпляру SQL на портале Azure.
2. В разделе "Безопасность" выберите "Удостоверение".
   1. Если в разделе "Назначаемое пользователем управляемое удостоверение" вы видите "Не найдено управляемых удостоверений, назначаемых пользователем", экземпляр SQL с управляемой идентификацией использует управляемое удостоверение, назначаемое системой, по умолчанию.
   2. Если вы видите запись в поле основная идентификация, значит ваш управляемый экземпляр SQL использует пользовательскую управляемую идентификацию, назначенную пользователем. Запишите это управляемое удостоверение для использования на шаге, где вы выбираете его при предоставлении права читателя данных BLOB-объектов хранилища к учетной записи хранения.

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

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

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

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

Настройка базы данных источника SQL Server

Включите ускоренное восстановление базы данных и Service Broker в исходном SQL Server экземпляре, если вы планируете использовать эти функции в целевом SQL Managed Instance после миграции, так как эти функции нельзя включить после миграции, если они еще не включены в исходном SQL Server экземпляре.

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

Для SQL Server 2019 и более поздних версий включите функцию ускоренного восстановления базы данных и убедитесь, что для хранилища постоянных версий (PVS) задано значение . Если ускоренное восстановление базы данных не включено в исходной SQL Server базе данных, его нельзя включить в целевом управляемом экземпляре SQL после миграции базы данных. Если хранилище постоянных версий (PVS) не задано PRIMARY, возникают проблемы при выполнении операций восстановления в целевом управляемом экземпляре SQL.

Для SQL Server 2017 и более ранних версий ускорение восстановления базы данных не поддерживается, поэтому этот шаг не нужен.

Чтобы правильно настроить ускоренное восстановление базы данных в исходной SQL Server базе данных, выполните следующие действия.

1. Включите ускоренное восстановление базы данных, выполнив следующий скрипт Transact-SQL в SQL Server:

   ALTER DATABASE [<database name>] SET ACCELERATED_DATABASE_RECOVERY = ON;
   

2. Хранилище постоянных версий (PVS) должно иметь PRIMARY значение в исходной базе данных, которая является конфигурацией по умолчанию. Если это было изменено ранее, перед началом миграции необходимо изменить его обратно на PRIMARY .

Включение компонента Service Broker

Service Broker включен по умолчанию для всех версий SQL Server. Если компонент Service Broker отключен и вы планируете использовать его в SQL Managed Instance, включите Service Broker в исходной базе данных SQL Server перед миграцией на SQL Managed Instance. Если компонент Service Broker не включен в исходной базе данных SQL Server, его нельзя использовать в целевом управляемом экземпляре SQL.

Чтобы проверить, включен ли Компонент Service Broker, выполните следующий скрипт Transact-SQL в экземпляре SQL Server:

SELECT name AS [Database Name], is_broker_enabled AS [Service Broker Enabled]
FROM sys.databases
WHERE name = '<database name>';

Если компонент Service Broker отключен, включите его, выполнив следующий скрипт Transact-SQL в исходной базе данных SQL Server:

USE master;
GO

ALTER DATABASE [<database name>]
    SET ENABLE_BROKER;
GO

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

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

Чтобы отправить резервные копии в Azure:

• Делайте резервные копии на экземпляре SQL Server.
• Копируйте ваши резервные копии в учетную запись Blob Storage.
• Альтернативно, SQL Server 2025 (17.x) на Windows Server вводит поддержку управляемых удостоверений для резервного копирования непосредственно на URL-адрес. Чтобы выполнить резервное копирование напрямую на URL-адрес для SQL Server 2022 и более ранних версий, необходимо использовать SAS-токен. Чтобы использовать управляемое удостоверение с SQL Server 2022 и более ранними версиями, скопируйте резервные копии в учетную запись Blob Storage с помощью AzCopy. Единственным исключением является миграция из SQL Server на виртуальных машинах Azure, которая поддерживает резервное копирование непосредственно на URL-адрес с проверкой подлинности управляемого удостоверения, начиная с SQL Server 2022 CU 17.

Учитывайте приведенные ниже рекомендации.

• Создавайте резервные копии с параметрами COMPRESSION и CHECKSUM, чтобы уменьшить размер резервных файлов и предотвратить миграцию поврежденной базы данных.
• Создание резервных копий в небольших пакетах.
• Используйте параллельные потоки загрузки.
• Сделайте последний файл резервной копии как можно меньше.
• Чтобы перенести несколько баз данных с помощью одного и того же контейнера Azure Blob Storage, разместите все файлы резервной копии для отдельной базы данных в отдельную папку внутри контейнера. Используйте структуру неструктурированных файлов для каждой папки базы данных. Вложение папок в папки базы данных не поддерживается.

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

В этом разделе показано, как создать резервную копию локально, но можно также создать резервную копию непосредственно на URL-адрес.

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

-- 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

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

• Скачайте и установите AzCopy.
• Скачайте и установите Azure Storage Explorer.
• Используйте Storage Explorer на портале Azure.

Ограничения

Ограничения LRS применяются к миграциям через портал Azure.

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

При переходе на SQL Managed Instance на уровне служб Business Critical следует учитывать следующие ограничения:

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

Более длительный переход на сервисном уровне "Бизнес-критичный"

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

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

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

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

Мониторинг миграции с помощью портала Azure доступен только для SQL Server экземпляров, которые соответствуют требованиям мониторинга лицензирования.

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

См. раздел устранение проблем при миграции для устранения распространенных проблем при миграции на Azure SQL Managed Instance.

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

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

• миграция SQL Server в Azure Arc
• Подготовка среды для миграции ссылок управляемого экземпляра
• Обзор SQL Server с поддержкой Azure Arc
• Обратная связь о миграции непосредственно в группу продуктов
• Миграция на Azure SQL Managed Instance — миграция SQL Server с использованием Azure Arc