Перейти по ссылке — Управляемый экземпляр SQL Azure

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

В этой статье описывается перенос базы данных SQL Server на Управляемый экземпляр SQL Azure с помощью ссылки Управляемый экземпляр.

Для получения подробного руководства по миграции обратитесь к статье Миграция на Управляемый экземпляр SQL Azure. Чтобы сравнить средства миграции, просмотрите Compare LRS со ссылкой Управляемый экземпляр.

Примечание.

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

Обзор

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

Миграция со ссылкой предоставляет вам следующее:

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

Примечание.

Хотя вы можете перенести только одну базу данных на одну ссылку, можно установить несколько ссылок из одного экземпляра SQL Server на один и тот же Управляемый экземпляр SQL.

Поведение при переключении

Поведение при переключении зависит от версии SQL Server, с которой выполняется миграция, и политики обновления целевого управляемого экземпляра SQL:

  • Для SQL Server 2016–SQL Server 2019 при переключении на Управляемый экземпляр SQL связь разрывается.
  • Для SQL Server 2022 или более поздних версий при переключении на Управляемый экземпляр SQL можно либо удалить ссылку, либо сохранить её в зависимости от выбранного вами варианта во время отработки отказа. Если вы решили сохранить ссылку, а управляемый экземпляр SQL настроен с соответствующей политикой обновления, вы можете вернуться обратно в SQL Server при необходимости.

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

Реверсировать миграцию

Обратная миграция обратно в SQL Server из Управляемый экземпляр SQL Azure может поддерживаться в зависимости от политики update управляемого экземпляра SQL. Рассмотрим пример.

  • политика обновления SQL Server 2022: базы данных из экземпляров, настроенных в соответствии с политикой обновления SQL Server 2022, могут быть восстановлены в экземпляры SQL Server 2022.
  • политика обновления SQL Server 2025: базы данных из экземпляров, настроенных в соответствии с политикой обновления SQL Server 2025, могут быть восстановлены обратно на экземпляры SQL Server 2025.
  • Always-up-to-date update policy: базы данных из экземпляров, настроенных с помощью Always-up-to-date политики обновления нельзя восстановить обратно в SQL Server.

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

Предварительные условия

Чтобы использовать ссылку с Управляемый экземпляр SQL Azure для миграции, вам потребуется следующее:

Оценка и обнаружение

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

Для обнаружения источников SQL в вашей среде можно использовать следующие средства:

  • SQL Server при поддержке Azure Arc: SQL Server, при поддержке Azure Arc, автоматически создаёт оценку для миграции на Azure, упрощая процесс обнаружения и оценивания готовности к миграции.
  • Миграция Azure для оценки пригодности к миграции локальных серверов, определения размеров на основе производительности и предоставления оценок затрат на их работу в Azure.
  • Microsoft набор средств для оценки и планирования (набор средств MAP) для оценки текущей ИТ-инфраструктуры. Этот набор средств представляет собой мощный инструмент для инвентаризации, оценки и создания отчетов, позволяющий упростить планирование миграции.

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

Для оценки вашего исходного экземпляра SQL Server можно использовать оценку готовности к миграции.

Для получения подробных рекомендаций смотрите перед миграцией.

Создание целевого экземпляра

После оценки существующей среды и определения соответствующего уровня служб и конфигурации оборудования для целевого управляемого экземпляра SQL разверните целевой экземпляр с помощью портала Azure, PowerShell или Azure CLI.

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

Проверка задержки репликации

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

Используйте следующий запрос T-SQL в SQL Server и Управляемый экземпляр SQL для отслеживания задержки репликации между репликами:

-- Execute on SQL Server and SQL Managed Instance 
USE master
DECLARE @link_name varchar(max) = '<DAGname>'
SELECT
   ag.name [Link name], 
   ars1.role_desc [Link role],
   ars2.connected_state_desc [Link connected state],
   ars2.synchronization_health_desc [Link sync health],
   drs.secondary_lag_seconds [Link replication latency (seconds)]
FROM
   sys.availability_groups ag 
   JOIN sys.dm_hadr_availability_replica_states ars1
   ON ag.group_id = ars1.group_id
   JOIN sys.dm_hadr_availability_replica_states ars2
   ON ag.group_id = ars2.group_id
   JOIN sys.dm_hadr_database_replica_states drs
   ON ars2.replica_id = drs.replica_id
WHERE 
   ag.is_distributed = 1 AND ag.name = @link_name AND ars1.is_local = 1 AND ars2.is_local = 0
GO

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

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

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

Синхронизация данных и переход

После установки ссылки и готовности к миграции выполните следующие действия (обычно во время периода обслуживания):

  1. Остановите нагрузку на основной базе данных SQL Server, чтобы вторичная база данных на Управляемый экземпляр SQL догнала её. Самый простой способ остановить нагрузки на первичной реплике SQL Server — отключить подключения приложений к экземпляру.
  2. Убедитесь, что все данные переданы во вторичную базу данных на Управляемый экземпляр SQL. Проверьте задержку репликации , чтобы убедиться, что вторичная реплика подключена к первичной реплике.
  3. Переключите подключение на вторичный управляемый экземпляр SQL, выбрав запланированное переключение.
  4. (Необязательно) Установите флажок "Удалить ссылку" после успешной отработки отказа , чтобы убедиться, что отработка отказа является одним из способов, и ссылка удаляется.
  5. (Необязательно) Если вы используете поддерживаемую версию SQL Server с соответствующей политикой обновления Управляемый экземпляр SQL , вы можете сохранить ссылку после переключения на резерв, чтобы отменить миграцию при необходимости. Проверьте раздел об отмене миграции для конкретных сведений о версии.
  6. Переключите приложение для подключения к конечной точке управляемого экземпляра SQL.
  7. (Необязательно) Если вы не решили удалить ссылку во время переключения на резервный узел, вы можете удалить ссылку после переключения, когда она вам больше не нужна.

Проверка миграции

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

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

Известные проблемы с миграцией

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

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

База данных автоматически восстанавливается после вмешательства Microsoft, но это восстановление может занять некоторое время.

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

Проблемы с выполнением операции восстановления после миграции в Управляемый экземпляр SQL

Если вы переносите базу данных в управляемый экземпляр SQL Azure из SQL Server 2019 и более поздних версий с включенным ускоренным восстановлением базы данных, но настроенным хранилищем постоянных версий (PVS) с отличными от PRIMARY файловой группы параметрами, вы можете столкнуться с неудачами операций восстановления в целевом управляемом экземпляре SQL.

Чтобы обойти эту проблему, убедитесь, что хранилище версий persistent (PVS) задано как PRIMARY в исходной базе данных SQL Server перед переносом на Управляемый экземпляр SQL. Если вы уже перенесли базу данных без установки PVS PRIMARY, вы можете установить его в исходной базе данных SQL Server, а затем повторно перенести базу данных в управляемый экземпляр SQL.

Не удалось использовать ускоренное восстановление базы данных после миграции в Управляемый экземпляр SQL

Начиная с SQL Server 2019, если вы переносите базу данных в Управляемый экземпляр SQL Azure, и исходная база данных имеет отключенное ускоренное восстановление базы данных, невозможно использовать ускоренное восстановление базы данных на целевом управляемом экземпляре SQL Managed Instance.

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

SQL Server 2017 и более ранних версий не поддерживают ускоренное восстановление базы данных, поэтому эта проблема не применяется к базам данных, перенесенным из этих версий SQL Server.

Не удается использовать Service Broker после миграции в Управляемый экземпляр SQL

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

Чтобы обойти эту проблему, убедитесь, что вы включите Service Broker в исходной базе данных SQL Server, прежде чем перенести ее в Управляемый экземпляр SQL. Если база данных уже перенесена без включения Service Broker, ее можно включить в исходной SQL Server базе данных, а затем повторно перенести базу данных в Управляемый экземпляр SQL.

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

Чтобы использовать ссылку, выполните следующие действия.

Дополнительные сведения о ссылке:

Для других сценариев репликации и миграции учтите следующее:

  • Last updated on