Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Применимо к:
Управляемый экземпляр SQL Azure
В этой статье сравнивается служба воспроизведения журналов (LRS) со ссылкой управляемого экземпляра при миграции в Управляемый экземпляр SQL Azure.
Обзор
Служба воспроизведения журналов (LRS) использовалась для миграции в Управляемый экземпляр SQL Azure с момента запуска службы в ноябре 2018 года. Под капотом LRS использует реализацию пересылки журналов, которая также обеспечивает сервис миграции баз данных Azure (DMS).
В марте 2022 года ссылка на управляемый экземпляр (MI link) была представлена как более производительный вариант миграции с обещанием минимально возможного времени простоя. Ссылка управляемого экземпляра использует распределенную технологию группы доступности AlwaysOn для репликации данных практически в режиме реального времени из SQL Server в Управляемый экземпляр SQL Azure. С помощью ссылки вы можете также переключиться обратно в режим онлайн из управляемого экземпляра SQL на SQL Server 2022 или более позднюю версию в качестве меры безопасности при миграции.
LRS и связь MI взаимно дополняют друг друга по своим возможностям, при этом каждая из технологий подходит для разных бизнес-потребностей. Просмотрите возможности каждого средства, чтобы определить, какой из лучших способов использовать для миграции в зависимости от ваших конкретных обстоятельств.
Сравните ссылку LRS и MI
Основное различие между LRS и MI-связью связано с базовой технологией. Поскольку LRS основан на журнализации, разностные и транзакционные резервные копии постоянно создаются в SQL Server, передаются в Azure Blob-хранилище и восстанавливаются в управляемый экземпляр SQL. Процесс не в режиме реального времени, так как требуется время для резервного копирования файлов, их отправки и восстановления. Производительность LRS зависит от размера блоков резервного копирования.
В отличие от этого, связь MI использует технологию группы доступности AlwaysOn для отправки записей журналов транзакций практически в реальном времени из SQL Server в управляемый экземпляр SQL, что делает его значительно более высокопроизводительным решением для миграции. Однако чтобы настроить соединение MI, необходимо настроить VPN между SQL Server и управляемым экземпляром SQL Server и открыть соответствующие порты в брандмауэре, в то время как LRS работает сразу с помощью общедоступной конечной точки. LRS можно использовать для всех выпусков SQL Server 2008 и более поздних версий, а ссылка MI может использоваться только для SQL Server 2016 и более поздних версий для выпусков Standard, Enterprise и Developer.
Замечание
В SQL Server 2025 представлены отдельные выпуски SQL Server: Enterprise Developer и Standard Developer.
Основное преимущество связи MI — это возможность обратной миграции на SQL Server 2022 и последующие версии, что невозможно с помощью LRS. Еще одним важным преимуществом миграции с использованием MI-ссылки является то, что база данных SQL в Управляемом экземпляре может использоваться для рабочих нагрузок только для чтения во время миграции. Эта возможность недоступна в LRS, так как база данных находится в состоянии восстановления до завершения миграции. Аналогичным образом, при обратной миграции на SQL Server 2022 и более поздних версиях база данных доступна только для чтения рабочих нагрузок на SQL Server во время миграции.
В следующей таблице сравниваются ссылки LRS и MI более подробно:
| Функция | Ссылка управляемого экземпляра (ссылка MI) | Служба воспроизведения логов (LRS) | Примечания |
|---|---|---|---|
| Базовая технология | Распределенные группы доступности (AG) | Пересылка журналов транзакций | Ссылка MI использует распределенную группу доступности для репликации, которая более новая и более расширенная по сравнению с технологией доставки журналов, используемой LRS. |
| Производительность репликации | Практически в режиме реального времени. | Восстанавливается каждые несколько минут. | Репликация данных по ссылке MI значительно эффективнее, чем применение резервных копий журналов транзакций с помощью LRS. |
| Минимальная поддерживаемая исходная версия | SQL Server 2016 и более поздних версий | SQL Server 2008 и более поздних версий | LRS может поддерживать гораздо более старые версии SQL Server, чем MI link. |
| Минимальная поддерживаемая версия Windows Server | Windows Server 2012 R2 | Windows Server 2008 | LRS может поддерживать гораздо более старые версии Windows Server, чем ссылка MI. |
| Вторичный только для чтения | Поддерживается. | Не поддерживается. | Во время выполнения репликации базы данных Управляемого экземпляра SQL, реплицируемые через ссылку, могут использоваться для только чтения рабочих нагрузок, что позволяет протестировать миграцию перед переключением или использовать базы данных перед миграцией в Azure. Аналогичным образом, при обратной миграции на SQL Server 2022 и более поздних версиях база данных доступна только для чтения рабочих нагрузок на SQL Server во время миграции. Эта возможность недоступна в LRS. |
| Репликация зашифрованных баз данных TDE | Да, требуется импорт ключей безопасности в управляемый экземпляр SQL. | Да, требуется импорт ключей безопасности в управляемый экземпляр SQL. | Требование и процедура переноса соответствующего сертификата шифрования из SQL Server в управляемый экземпляр SQL, прежде чем начать миграцию, совпадает с обоими параметрами миграции. |
| Тип сетевого подключения | — частная конечная точка — VPN, настроенный как с входящими, так и исходящими портами |
Общедоступная конечная точка | Хотя связь MI обеспечивает дополнительные уровни безопасности и предлагает VPN в качестве варианта, сеть сложнее настроить по сравнению с LRS. По умолчанию LRS предоставляет упрощенный интерфейс, поэтому его можно использовать немедленно без какой-либо конфигурации сети или VPN. LRS использует общедоступную конечную точку по умолчанию, которая менее безопасна, чем VPN, используемая с MI-каналом, и она может не удовлетворять некоторым из наиболее требовательных требований к безопасности, так как она использует общедоступную учетную запись хранения BLOB-объектов Azure в качестве посредника, чтобы сохранить данные до восстановления в управляемом экземпляре SQL. Хотя можно использовать частную конечную точку с LRS для повышения безопасности передачи данных, она повышает сложность начальной конфигурации. |
| Шифрование данных в передаче | — Данные, зашифрованные с помощью AES, и — SSL используется для шифрования передачи данных. |
SSL используется для шифрования передачи данных. | Ссылка MI использует дополнительный уровень шифрования AES. SSL используется для передачи данных инструментам миграции. |
| Проверка подлинности для репликации | Сертификаты, подписанные доверенным центром сертификации (ЦС) | Управляемые удостоверения или токены SAS | Для подписывания сертификата для проверки подлинности требуется центр сертификации (ЦС). Для LRS использование управляемых удостоверений является более безопасным, чем использование самогенерированных токенов SAS. |
| Подвержен обновлениям системы или переключению на резервный режим | Нет, кроме минимального прерывания для кратковременного резервного переключения. | — Для экземпляров общего назначения миграция автоматически приостанавливается и возобновляется после прерываний. — Для критически важных для бизнеса экземпляров процесс миграции отменяется в случае прерываний и должен быть перезапущен вручную. |
Связь MI устойчива и миграция не затронута отказоустойчивостью управляемого экземпляра SQL. И наоборот, миграция LRS задерживается из-за перезапусков или отказов управляемых экземпляров SQL на уровне услуги General Purpose, а миграция перезапускается для экземпляров на уровне услуги Business Critical. |
| Длительность репликации | Неограниченное время репликации с помощью ссылки (месяцы и даже годы за раз). | Задание LRS может выполняться до 30 дней. | Соединение MI может выполняться в течение неограниченного времени. LRS ограничен 30-дневным сроком непрерывной отправки журналов, после чего миграция автоматически останавливается и должна быть перезапущена с начала. |
| Тип миграции | Настоящая онлайн-миграция с коротким переключением (измеряется в секундах). | — Миграция через Интернет с ожидаемым временем простоя во время перехода на время восстановления последнего файла резервной копии. — Переключение занимает значительно больше времени для экземпляров в служебном уровне "Критически важный для бизнеса". |
Ссылка MI — это единственное решение, которое предлагает решение с минимальным временем простоя (<1 минуты) для всех служебных уровней Управляемого экземпляра SQL. При использовании LRS последний файл резервной копии по-прежнему восстанавливается во время переключения, поэтому на основе размера последнего файла резервной копии и времени, необходимого для его восстановления, может возникнуть значительное ожидание, пока база данных не станет доступной в Управляемом экземпляре SQL. При использовании LRS для миграции на уровень служб "Критически важный для бизнеса" время простоя миграции может быть значительно больше, так как вся база данных должна быть реплицирована на вторичные узлы с первичного узла, прежде чем база данных будет доступна для рабочих нагрузок на первичном сервере. В зависимости от общего размера базы данных репликация на другие узлы и, следовательно, время простоя иногда может занять несколько часов. Таким образом, базы данных могут подключаться значительно медленнее с использованием LRS по сравнению с интерфейсом MI, который может осуществляться почти мгновенно. |
| Обслуживание, необходимое для источника | Да, регулярные резервные копии журналов транзакций. | Нет. | Ссылка MI требует регулярного резервного копирования журнала транзакций исходного экземпляра SQL Server во время миграции, чтобы усечь журнал транзакций и предотвратить исчерпание свободного места на диске. И наоборот, для LRS не требуется обслуживание. |
| устойчивость | Автоматически возобновляет репликацию ссылок при перезапуске SQL Server. | — Миграция останавливается, если есть нарушенная цепочка резервного копирования или неправильно указанный последний файл резервного копирования. — не поддерживает файлы резервного копирования из нескольких баз данных в одной папке (миграция неудачна). |
Связь MI является более устойчивой, чем LRS, поскольку репликация автоматически возобновляется после устранения проблем (например, непредвиденных простоев, обновлений, потери сетевого подключения и многих других). Кроме того, подключение MI устойчиво к переключениям при отказе SQL MI или обновлениям службы. Некоторые условия приводят к остановке LRS. Миграция LRS автоматически перезапускается, если миграция на уровень служб общего назначения прерывается, но требует перезапуска, если прерывается миграция на уровень служб, критически важный для бизнеса. |
| Обратная миграция с SQL MI обратно в SQL Server | Поддерживается обратная автономная и онлайн миграция на SQL Server 2022 и более поздние версии. | Не поддерживается. | Ссылка на MI — это единственное решение, которое предлагает онлайн и офлайн обратную миграцию на SQL Server 2022 и более поздние версии. Обратная миграция недоступна для более ранних версий SQL Server. |
Что выбрать?
Выбор между LRS и связью MI зависит от ваших обстоятельств и бизнес-потребностей. Важное различие между решениями миграции — производительность. LRS имеет более простую начальную настройку, что позволяет быстро выполнить миграцию. Хотя начальная конфигурация для канала MI является более сложной, она обеспечивает большую устойчивость, безопасность и гибкость.
Кроме того, время переключения значительно короче с MI-каналом, что является значительным преимуществом для многих клиентов. На самом деле, потенциально значительное время простоя при переходе на уровень служб "Критически важный для бизнеса" с помощью LRS заключается в том, почему ссылка MI называется единственной "истинной" миграцией на уровень служб "Критически важный для бизнеса".
Наконец, если вам требуется, чтобы база данных была доступна для рабочих нагрузок, доступных только для чтения, на целевой платформе миграции во время этого процесса, или если необходимо выполнить обратную миграцию на SQL Server 2022 или более поздние версии, ссылка MI — единственный вариант, поддерживающий эти сценарии.