Выполнение миграции с использованием распределенной группы доступности (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 см. в разделе Подключение приложений.
Обратная связь
https://aka.ms/ContentUserFeedback.
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделеОтправить и просмотреть отзыв по