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

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

  • Статья

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

В этой статье представлен обзор службы воспроизведения журналов (LRS), которую можно использовать для переноса баз данных из SQL Server в Управляемый экземпляр SQL Azure. LRS — это бесплатная облачная служба, доступная для Azure SQL Управляемого экземпляра и основанная на технологии доставки журналов 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 Managed Instance.

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

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

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

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

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

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

Внимание

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

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

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

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

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

Когда вы будете готовы к переключение, остановите рабочую нагрузку на экземпляре 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 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. Убедитесь, что последняя резервная копия хвоста журнала восстановлена на управляемом экземпляре. Завершите переключение, инициировав операцию 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.

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