Выполнение миграции с использованием распределенной группы доступности (AG)

Используйте распределенную группу доступности для переноса баз данных из SQL Server в SQL Server на виртуальных машинах Azure.

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

Мониторинг миграции

Для отслеживания хода выполнения миграции используйте Transact-SQL.

Выполните приведенный ниже скрипт на глобальном сервере-источнике и сервере пересылки, а затем проверьте, что для synchronization_state_desc первичной группы доступности (OnPremAG) и вторичной группы доступности (AzureAG) отображается состояние SYNCHRONIZED. Убедитесь, что synchronization_state_desc для распределенной группы доступности (DAG) выполняется синхронизация, а для каждой last_hardened_lsn базы данных — как в глобальном источнике, так и в сервере пересылки.

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

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

SELECT ag.name 
       , drs.database_id 
       , db_name(drs.database_id) as database_name 
       , drs.group_id 
       , drs.replica_id 
       , drs.synchronization_state_desc 
       , drs.last_hardened_lsn   
FROM sys.dm_hadr_database_replica_states drs  
INNER JOIN sys.availability_groups ag on drs.group_id = ag.group_id; 

Завершение миграции

После проверки состояния группы доступности и распределенной группы доступности вы можете завершить миграцию. Это включает отработку отказа распределенной группы доступности на сервер пересылки (целевой SQL Server в Azure), а затем разрезание приложения до нового источника на стороне Azure.

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

После отработки отказа обновите строку подключения для приложения, чтобы подключиться к новой первичной реплике в Azure. На этом этапе можно выбрать поддержку распределенной группы доступности или использовать DROP AVAILABILITY GROUP [DAG] как в исходном, так и в целевом экземплярах SQL Server, чтобы удалить ее.

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

Дальнейшие действия

Руководство по переносу базы данных в SQL Server в Azure Виртуальные машины с помощью команды T-SQL RESTORE см. в статье Руководство по миграции: SQL Server в SQL Server в Azure Виртуальные машины.

Дополнительные сведения об SQL Server на виртуальных машинах Azure см. в статье Обзор.

Сведения о подключении приложений к SQL Server на виртуальных машинах Azure см. в разделе Подключение приложений.