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

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

  • Статья

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

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

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

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

Внимание

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

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

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 Compute Engine
  • Cloud SQL для SQL Server — GCP (Google Cloud Platform)
  • Alibaba Cloud RDS для SQL Server

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

Примечание.

  • Рекомендуется автоматизировать миграцию баз данных из SQL Server в Управляемый экземпляр SQL Azure с помощью расширения миграции SQL Azure для Azure Data Studio. Рекомендуется использовать LRS для оркестрации миграций, когда расширение миграции SQL Azure не полностью поддерживает сценарии.
  • LRS — единственный метод восстановления разностных резервных копий в управляемых экземплярах. Невозможно вручную восстановить разностные резервные копии в управляемых экземплярах или вручную задать NORECOVERY режим с помощью T-SQL.

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

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

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

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

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

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

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

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

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

Внимание

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

Автоматическая компиляция и непрерывная миграция в режиме

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

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

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

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

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

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

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

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

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

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

Работа Details
1. Скопируйте резервные копии базы данных из экземпляра SQL Server в учетную запись хранения BLOB-объектов. Скопируйте полные, разностные и журналные резервные копии из экземпляра SQL Server в контейнер хранилища BLOB-объектов с помощью AzCopy или служба хранилища Azure Explorer.

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

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

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

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

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

При запуске LRS в непрерывном режиме восстанавливает все резервные копии, которые были первоначально отправлены, а затем просматривает все новые файлы, отправленные в папку. Служба постоянно применяет журналы на основе цепочки последовательности журналов (LSN), пока она не будет остановлена вручную. Этот режим рекомендуется для активных рабочих нагрузок, для которых требуется перехват данных.
2.1. Мониторинг хода выполнения операции. Ход выполнения текущей операции восстановления можно отслеживать с помощью PowerShell (get-azsqlinstancedatabaselogreplay) или Azure CLI (az_sql_midb_log_replay_show командлетов). Чтобы отслеживать дополнительные сведения о неудачном запросе, используйте команду 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. Убедитесь, что последняя резервная копия хвоста журнала восстановлена в управляемом экземпляре. Завершите прямую миграцию, инициировав операцию complete LRS с помощью PowerShell (complete-azsqlinstancedatabaselogreplay) или Azure CLI az_sql_midb_log_replay_complete. Эта операция останавливает LRS и переводит базу данных в режим "в сети" для рабочих нагрузок чтения и записи в Управляемый экземпляр SQL.

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

Внимание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

Дополнительные сведения см . в ограничениях при использовании LRS.

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