Поделиться через

Обзор службы воспроизведения журналов с управляемым экземпляром SQL Azure

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

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

Примечание.

Теперь вы можете перенести экземпляр SQL Server, поддерживаемый Azure Arc, непосредственно в Управляемый экземпляр Azure SQL через портал Azure. Дополнительные сведения см. в статье "Миграция в Управляемый экземпляр SQL Azure".

Так как LRS восстанавливает стандартные файлы резервного копирования SQL Server, его можно использовать для миграции из SQL Server , размещенной в любом месте (локальном или любом облаке) в Управляемый экземпляр SQL Azure.

Чтобы начать миграцию с LRS, ознакомьтесь с разделом "Миграция баз данных из SQL Server" с помощью службы воспроизведения журналов.

Внимание

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

Когда следует использовать службу воспроизведения журналов

Azure Database Migration Service, расширение миграции SQL Azure для Azure Data Studio и LRS используют одну и ту же базовую технологию миграции и API. LRS также позволяет выполнять сложные пользовательские миграции и создавать гибридные архитектуры между локальными экземплярами SQL Server и развертываниями Управляемого экземпляра SQL.

Если вы не можете использовать Azure Database Migration Service или расширение SQL Azure для миграции, вы можете использовать LRS непосредственно с PowerShell, командлетами Azure CLI или API для ручной сборки и оркестрации миграции баз данных в Управляемый экземпляр SQL.

Рекомендуется использовать LRS в следующих случаях:

  • Требуется больше контроля над проектом переноса базы данных.
  • Во время переключения на новый режим миграции практически не допускается время простоя.
  • В вашей среде невозможно установить исполняемый файл Database Migration Service.
  • Исполняемый файл Database Migration Service не имеет доступа к резервным копиям вашей базы данных.
  • Вы не можете установить расширение миграции SQL Azure в среду или не сможете получить доступ к резервным копиям базы данных.
  • У вас нет доступа к привилегиям операционной системы узла или администратора.
  • Вы не можете открыть сетевые порты из вашей среды в Azure.
  • Проблемы регулирования сети или блокировки прокси-сервера существуют в вашей среде.
  • Резервные копии хранятся непосредственно в учетных записях хранилища BLOB-объектов Azure с помощью TO URL параметра.
  • Необходимо использовать разностные резервные копии.

Так как LRS работает путем восстановления стандартных файлов резервного копирования SQL Server, он поддерживает миграцию из любого источника. Были проверены следующие источники:

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

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

Примечание.

  • LRS — единственный метод восстановления разностных резервных копий в управляемых экземплярах SQL. Невозможно вручную восстановить разностные резервные копии в управляемых экземплярах или вручную задать NORECOVERY режим с помощью T-SQL.

Принцип работы LRS

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

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

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

Для LRS не требуется определенное соглашение об именовании для файлов резервных копий. Он сканирует все файлы, размещенные в учетной записи Azure Blob Storage, и создает цепочку резервных копий, исходя только из заголовков файлов. В процессе миграции базы данных находятся в состоянии восстановления. LRS восстанавливает базы данных в режиме NORECOVERY , поэтому их нельзя использовать для рабочих нагрузок чтения или записи до завершения процесса миграции.

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

  • Поместите файлы резервного копирования для каждой базы данных в отдельную папку на учетной записи Blob Storage в структуре плоских файлов. Например, используйте отдельные папки базы данных: blobcontainer/database1/files, blobcontainer/database2/files и т. д.
  • Не используйте вложенные папки в папках базы данных, так как структура вложенных папок не поддерживается. Например, не используйте вложенные папки, такие как blobcontainer/database1/subfolder/files.
  • Запустите LRS отдельно для каждой базы данных.
  • Укажите различные пути URI для разделения папок базы данных в аккаунте Blob Storage.

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

Дополнительные сведения см. в статье "Миграция баз данных из SQL Server с помощью службы воспроизведения журналов".

Внимание

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

Автозаполнение vs. миграция в непрерывном режиме

Можно запустить LRS в режиме автозавершения или в непрерывном режиме.

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

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

Когда вы будете готовы к переключение, остановите рабочую нагрузку на экземпляре SQL Server, создайте последний файл резервной копии и отправьте его. Убедитесь, что последний файл резервной копии восстановлен, убедившись, что последняя резервная копия журнала отображается, как восстановлено в Управляемом экземпляре SQL. Затем вручную инициируйте переключение. Последний этап перехода переводит базу данных в онлайн-режим, делая её доступной для чтения и записи на Управляемом экземпляре SQL.

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

Рабочий процесс миграции

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

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

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

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

Операция Подробности
1. Скопируйте резервные копии базы данных из инстанса SQL Server в учетную запись Blob Storage. Скопируйте полные, разностные и лог-файлы резервных копий из экземпляра SQL Server в контейнер хранилища BLOB с помощью AzCopy или Azure Storage Explorer.

Используйте любые имена файлов. LRS не требует определенного соглашения об именовании файлов.

При переносе нескольких баз данных используйте отдельную папку для каждой базы данных.
2. Запустите LRS в облаке. Запустите службу с помощью PowerShell (start-azsqlinstancedatabaselogreplay) или Azure CLI командлеты (az_sql_midb_log_replay_start). Выберите режим автозаполнения или непрерывной миграции.

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

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

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

При запуске LRS в непрерывном режиме он восстанавливает все резервные копии, которые вы изначально отправили, а затем проверяет наличие всех новых файлов, которые вы отправляете в папку. Служба постоянно применяет журналы транзакций на основе цепочки номеров последовательности журналов (LSN), пока она не будет остановлена вручную. Этот режим рекомендуется для активных рабочих нагрузок, для которых требуется наверстывание данных.
2.1. Мониторинг хода выполнения операции. Отслеживайте ход выполнения текущей операции восстановления с помощью PowerShell (get-azsqlinstancedatabaselogreplay) или Azure CLI (az_sql_midb_log_replay_show cmdlets). Чтобы отслеживать дополнительные сведения о неудачном запросе, используйте команду PowerShell Get-AzSqlInstanceOperation или используйте команду Azure CLI az sql mi op show.
2.2. Остановите операцию при необходимости (необязательно). Если необходимо прерывать процесс миграции, можно использовать PowerShell (stop-azsqlinstancedatabaselogreplay) или Azure CLI (az_sql_midb_log_replay_stop).

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

Если вы запускаете LRS в непрерывном режиме, остановите приложение и рабочую нагрузку. Создайте последнюю резервную копию журнала и отправьте ее в развертывание Хранилище BLOB-объектов Azure. Убедитесь, что последняя резервная копия хвоста журнала восстановлена в управляемом экземпляре SQL. Завершите переключение, инициировав операцию LRS с помощью PowerShell (complete) или Azure CLI az_sql_midb_log_replay_complete. Эта операция останавливает LRS и переводит базу данных в режим "в сети" для рабочих нагрузок чтения и записи в Управляемый экземпляр SQL.

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

Внимание

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

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

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

  • Одно задание LRS может выполняться не более 30 дней. По истечении этого периода задание автоматически отменяется.
  • Для длительных заданий обновления системы могут прерывать текущий процесс и тем самым продлевать общее время выполнения заданий миграции. Мы настоятельно рекомендуем использовать окно обслуживания для планирования запланированных обновлений системы. Планируйте миграцию в рамках запланированного окна обслуживания.
  • Задания миграции, прерванные системными обновлениями, автоматически приостанавливаются и возобновляются для управляемых экземпляров SQL общего назначения, и перезапускаются для управляемых экземпляров SQL бизнес-критического назначения. Эти обновления влияют на период миграции.
  • Чтобы увеличить скорость отправки файлов резервного копирования SQL Server в учетную запись хранения BLOB-объектов, если инфраструктура имеет достаточную пропускную способность сети, попробуйте использовать многопоточность.

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

Начните миграцию с запуска LRS. Можно запустить службу в режиме автозавершения или в непрерывном режиме. Дополнительные сведения см. в статье "Миграция баз данных из SQL Server" с помощью службы воспроизведения журналов.

  • Режим автозавершения. При использовании режима автозаполнения миграция завершается автоматически после восстановления последнего из указанных файлов резервной копии. Этот параметр:

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

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

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

    Миграция завершается только после запроса на ручное переключение.

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

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

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

Примечание.

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

Ограничения LRS

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

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

  • Last updated on