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

  • Статья

Применимо к:Управляемый экземпляр SQL Azure

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

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

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

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 параметра.
  • Необходимо использовать разностные резервные копии.

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

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

Примечание.

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

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

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

  • Поместите файлы резервного копирования для каждой базы данных в отдельную папку в учетной записи большого двоичного объекта служба хранилища в структуре неструктурированных файлов. Например, используйте отдельные папки базы данных: 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 в контейнер больших двоичных объектов служба хранилища с помощью AzCopy или служба хранилища Azure Обозреватель.

Используйте любые имена файлов. 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 командлетов).
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. Этот шаг необходимо выполнить самостоятельно, либо вручную, строка подключения изменить приложение, либо автоматически (например, если приложение может считывать строка подключения из свойства или базы данных).

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

Учитывайте следующие ограничения LRS:

  • Только база данных .bakи .log.diff файлы поддерживаются LRS. Dacpac и bacpac-файлы не поддерживаются.
  • Во время миграции базы данных, которые переносятся, нельзя использовать для доступа только для чтения в Управляемый экземпляр SQL.
  • Необходимо настроить период обслуживания, чтобы разрешить планирование обновлений системы в определенный день и время. Запланируйте выполнение и завершение миграции за пределами запланированного периода обслуживания.
  • Резервные копии базы данных, которые не CHECKSUM требуют больше времени для восстановления, чем резервные копии баз данных с включенным CHECKSUM .
  • Маркер подписанного URL-адреса (SAS), который использует LRS, должен быть создан для всего контейнера Хранилище BLOB-объектов Azure, и он должен иметь только разрешения на чтение и список. Например, если вы предоставляете разрешения на чтение, список и запись, LRS не сможет запускаться из-за дополнительного разрешения на запись.
  • Использование маркеров SAS, созданных с разрешениями, заданными путем определения хранимой политики доступа, не поддерживается. Следуйте инструкциям в этой статье, чтобы вручную задать разрешения на чтение и перечисление для маркера SAS.
  • Файлы резервного копирования для разных баз данных необходимо разместить в отдельных папках в учетной записи blob-служба хранилища в структуре неструктурированных файлов. Вложенные папки в папках базы данных не поддерживаются.
  • Если вы используете режим автозавершения, вся цепочка резервных копий должна быть доступна заранее в учетной записи служба хранилища BLOB-объектов. Невозможно добавить новые файлы резервного копирования в режим автозаполнения. Используйте непрерывный режим, если необходимо добавить новые файлы резервной копии во время миграции.
  • Необходимо запустить LRS отдельно для каждой базы данных, которая указывает на полный путь URI, содержащий отдельную папку базы данных.
  • Путь URI резервного копирования, имя контейнера или имена папок не должны содержать backup или backups как они зарезервированы ключевое слово.
  • При запуске нескольких операций воспроизведения журналов параллельно нацеливается на один и тот же контейнер хранилища, убедитесь, что для каждой операции восстановления предоставляется один и тот же действительный маркер SAS.
  • LRS может поддерживать до 100 процессов одновременного восстановления на один управляемый экземпляр.
  • Одно задание LRS может выполняться не более 30 дней, после чего оно будет автоматически отменено.
  • Хотя можно использовать учетную запись служба хранилища Azure за брандмауэром, необходима дополнительная конфигурация, а учетная запись хранения и управляемый экземпляр должны находиться в одном регионе или в двух парных регионах. Дополнительные сведения см. в статье "Настройка брандмауэра ".
  • Максимальное количество баз данных, которые можно восстановить параллельно, составляет 200 на одну подписку. В некоторых случаях это ограничение можно увеличить, открыв запрос в службу поддержки.

Совет

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

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