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

Применимо к:Azure SQL Managed Instance

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

Примечание.

Теперь можно перенести экземпляр SQL Server с поддержкой Azure Arc на Azure SQL Managed Instance непосредственно через портал Azure. Чтобы узнать больше, ознакомьтесь с Переносом на Azure SQL Managed Instance.

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

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

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

Внимание

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

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

SQL Server

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

  • SQL Server версии 2008–2022.
  • База данных SQL Server использует модель полного восстановления (обязательно).
  • Полная резервная копия баз данных (один или несколько файлов).
  • Разностная резервная копия (один или несколько файлов).
  • Резервная копия журнала (без разделения на файл журнала транзакций).
  • Для SQL Server версий 2008–2016 выполните локальную резервную копию и мануально отправьте ее в учетную запись Azure Blob Storage.
  • Для SQL Server 2016 и более поздних версий вы можете сделать резервную копию напрямую в учетную запись Azure Blob Storage.
  • Хотя включение CHECKSUM резервного копирования не требуется, настоятельно рекомендуется предотвратить непреднамеренный перенос поврежденной базы данных и ускорить операции восстановления.
  • Любая версия Windows Server поддерживается на основе поддержки версий SQL Server.
  • Для SQL Server 2019 и более поздних версий необходимо включить ускоренное восстановление базы данных, если для хранилища постоянных версий задано значение PRIMARY. Дополнительные сведения см. в разделе Известные проблемы после миграции на SQL Managed Instance в этой статье.
  • Чтобы использовать Service Broker в базе данных, перенесенной в Azure SQL Managed Instance, перед миграцией необходимо включить Компонент Service Broker в исходной базе данных. Дополнительные сведения см. в разделе Известные проблемы после миграции на SQL Managed Instance в этой статье.

Azure

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Снимок экрана страницы управляемого экземпляра SQL для конфигурации подсети на портале Azure.

  4. Затем перейдите к учетной записи хранения на портале Azure, выберите Networking в разделе Security + networking и выберите вкладку Firewalls и виртуальных сетей.

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

    Снимок экрана страницы «Сеть учетной записи хранения» портала Azure с выбранной опцией добавления существующей виртуальной сети.

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

Аутентификация в вашей учетной записи Blob Storage

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

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

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

Создание маркера проверки подлинности SAS Blob Storage для LRS

Получите доступ к вашей учетной записи Azure Blob Storage, используя токен SAS.

Вы можете использовать учетную запись Azure Blob Storage в качестве промежуточного хранилища для файлов резервного копирования между экземпляром SQL Server и развертыванием SQL Managed Instance. Создайте маркер проверки подлинности SAS для LRS только с разрешениями на чтение и список. Маркер позволяет LRS получить доступ к вашей учетной записи Blob Storage и использует файлы резервного копирования для их восстановления в управляемую базу данных.

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

  1. Перейдите в центр Storage на портале Azure и выберите учетную запись хранения.

  2. В разделе "Безопасность и сеть" выберите подписанный URL-адрес , чтобы открыть область подписанного URL-адреса .

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

    1. Разрешенные службы: Blob и File.

    2. Допустимые типы ресурсов: служба.

    3. Разрешения: только для чтения и списка .

      Внимание

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

    4. Разрешения на версионирование BLOB: необязательно

    5. Разрешенные права доступа индексов BLOB: могут быть отключены.

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

      Внимание

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

    7. Выберите Generate SAS and connection string для создания токена:

    Снимок экрана: выбор срока действия маркера SAS, часового пояса и разрешений вместе с кнопкой

    Проверка подлинности SAS создается с заданным допустимым периодом.

  4. Скопируйте значение, указанное в поле URL-адреса службы BLOB-объектов SAS, которое является маркером в формате URI, необходимым для запуска LRS.

Примечание.

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

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

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

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

Снимок экрана: пример URI для сгенерированного токена SAS для службы воспроизведения журналов.

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

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

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

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

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

Примечание.

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

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

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

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

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

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

CREATE CREDENTIAL [https://<mystorageaccountname>.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';

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

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

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

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

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

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

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

-- To permit log backups, before the full database backup, modify the database to use the full recovery
USE master;

ALTER DATABASE SampleDB
SET RECOVERY FULL;
GO

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

Подробные инструкции по работе с маркерами SAS см. в руководстве Использование хранилища Azure Blob с SQL Server.

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

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

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

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

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

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

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

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

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

Login-AzAccount

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

Select-AzSubscription -SubscriptionId <subscription ID>

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

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

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

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

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

Примечание.

При переносе нескольких баз данных каждая база данных должна находиться в собственной папке. LRS необходимо запустить отдельно для каждой базы данных, указав полный ПУТЬ URI контейнера Azure Blob Storage и отдельную папку базы данных. Вложенные папки внутри папок базы данных не поддерживаются.

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

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

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

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

Внимание

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

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

Следующий пример 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"

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

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

Внимание

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

Следующий пример 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 и Azure CLI, запускающие LRS в непрерывном режиме, синхронны. В этом режиме PowerShell и Azure CLI ожидают ответа API, который сообщит об успешном выполнении или сбое, перед началом задания.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы завершить процесс миграции в непрерывном режиме 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 Managed Instance.
  • После завершения миграции процесс миграции будет окончательным и не может быть возобновлен с дополнительными разностными резервными копиями.
  • Поддерживаются только файлы базы данных .bak, .log и .diff LRS. Файлы Dacpac и bacpac не поддерживаются.
  • Необходимо настроить период обслуживания для планирования обновлений системы в определенный день и время. Запланируйте выполнение и завершение миграции за пределами запланированного периода обслуживания.
  • Резервные копии базы данных, которые выполняются без CHECKSUM:
    • может перенести потенциально поврежденные базы данных.
    • требуется больше времени для восстановления, чем резервные копии баз данных с CHECKSUM включенным.
  • Маркер SAS, который использует LRS, должен быть создан для всего контейнера Azure Blob Storage, и он должен иметь только разрешения Read и List. Например, если вы предоставляете разрешения Read, List и Write, LRS не запускается из-за дополнительного разрешения Write.
  • Использование маркеров SAS, созданных с разрешениями, заданными путем определения хранимой политики доступа, не поддерживается. Следуйте инструкциям в этой статье, чтобы вручную задать разрешения на прочтение и список для токена SAS.
  • Файлы резервного копирования для разных баз данных необходимо разместить в отдельных папках в учетной записи Blob Storage в структуре неструктурированных файлов. Вложение папок в папки базы данных не поддерживается.
  • Если вы используете режим автозаполнения, вся цепочка резервных копий должна быть доступна заранее в учетной записи Blob Storage. Невозможно добавить новые файлы резервного копирования в режим автозаполнения. Используйте непрерывный режим, если необходимо добавить новые файлы резервной копии во время миграции.
  • Необходимо запустить LRS отдельно для каждой базы данных, которая указывает на полный путь URI, содержащий отдельную папку базы данных.
  • Путь к резервному коду ресурса (URI), имя контейнера или имена папок не могут содержать backup или Backup как это зарезервированные ключевые слова.
  • При запуске нескольких операций воспроизведения журналов в параллельном режиме, ориентируясь на один и тот же контейнер хранилища, убедитесь, что для каждой операции восстановления предоставляется один и тот же действительный маркер SAS.
  • LRS поддерживает миграцию всех баз данных в один экземпляр до достижения ограничений по ресурсам уровня службы. Например, можно восстановить до 100 баз данных на уровне служб общего назначения и до 500 баз данных на уровне служб общего назначения следующего поколения .
  • LRS поддерживает 100 одновременных восстановления базы данных в одном экземпляре и 150 одновременных восстановления базы данных для всех экземпляров в одной подписке. Например, можно одновременно восстановить 100 баз данных параллельно с двумя экземплярами одной подписки или 50 баз данных в трех одновременных пакетах параллельно с четырьмя отдельными экземплярами в одной подписке.
  • Одно задание LRS может выполняться не более 30 дней, после чего оно будет автоматически отменено.
  • Хотя можно использовать учетную запись Azure Storage за брандмауэром, необходима дополнительная конфигурация, а учетная запись хранения и управляемый экземпляр должны находиться в одном регионе или в двух парных регионах. Дополнительные сведения см. в статье "Настройка брандмауэра ".
  • Максимальное количество баз данных, которые можно восстановить параллельно, составляет 150 на одну подписку. В некоторых случаях это ограничение можно увеличить, открыв запрос в службу поддержки.
  • Отправка тысяч файлов базы данных для восстановления может привести к чрезмерному времени миграции и даже сбою. Консолидируйте базы данных в меньшее количество файлов, чтобы ускорить процесс миграции и обеспечить его успех.
  • В начале и в конце процесса миграции есть два сценария, при которых процесс миграции прерывается, если происходит сбой, и задание миграции должно быть вручную заново запущено с самого начала, так как база данных удаляется из SQL Managed Instance.
    • Если переключение на резервный сервер происходит, когда первая полная резервная копия базы данных находится в процессе восстановления в экземпляр SQL Managed Instance при первом запуске задания на миграцию, задание на миграцию должно быть перезапущено вручную с самого начала.
    • Если переключение на резерв происходит после начала переключения миграции, задание миграции нужно вручную перезапустить с самого начала. Убедитесь, что последний файл резервной копии максимально мал, чтобы свести к минимуму время переключения и снизить риск отказа системы во время процесса переключения.
  • Если акселерированное восстановление базы данных отключен в исходном SQL Server 2019 и более поздних экземплярах, его нельзя включить после миграции на Azure SQL Managed Instance. Кроме того, если для хранилища постоянных версий (PVS) не задано PRIMARYзначение, можно столкнуться с проблемами с операциями восстановления в целевом управляемом экземпляре SQL.
  • Если Service Broker отключен в экземпляре исходного SQL Server, то после миграции не удается использовать компонент Service Broker в целевом управляемом экземпляре SQL.

Примечание.

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

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

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

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

Внимание

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

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

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

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

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

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

Известные проблемы после миграции в SQL Managed Instance

Рассмотрите следующие известные проблемы после миграции в Azure SQL Managed Instance:

Проблемы с выполнением операции восстановления после миграции в SQL Managed Instance

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

Чтобы обойти эту проблему, убедитесь, что хранилище версий persistent (PVS) задано как PRIMARY в исходной базе данных SQL Server перед переносом на SQL Managed Instance. Если база данных уже перенесена без настройки PVS для PRIMARY, ее можно задать в базе данных-источнике SQL Server, а затем повторно перенести базу данных в SQL Managed Instance.

Не удалось использовать ускоренное восстановление базы данных после миграции в SQL Managed Instance

Начиная с SQL Server 2019, если вы переносите базу данных в Azure SQL Managed Instance, и исходная база данных имеет отключенное ускоренное восстановление базы данных, невозможно использовать ускоренное восстановление базы данных на целевом управляемом экземпляре SQL Managed Instance.

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

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

Не удается использовать Service Broker после миграции в SQL Managed Instance

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

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

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

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

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

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

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

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

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

  • Last updated on