Перейти по ссылке — Azure SQL Managed Instance

Применимо к:Azure SQL Managed Instance

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

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

Примечание.

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

Обзор

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Last updated on