Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Используйте распределенную группу доступности (AG), чтобы перенести автономный экземпляр SQL Server или группу доступности на SQL Server на виртуальных машинах Azure.
В этой статье описываются необходимые компоненты для подготовки исходной и целевой сред для переноса экземпляра SQL Server или группы доступности на виртуальные машины SQL Server с помощью распределенной группы доступности.
Перенос базы данных (или нескольких баз данных) из автономного экземпляра с помощью распределенной группы доступности — это простое решение, которое не требует отказоустойчивого кластера Windows Server или прослушивателя группы доступности в источнике или целевом объекте. Для переноса группы доступности необходим кластер и прослушиватель на исходном и целевом серверах.
Исходный SQL Server
Чтобы перенести экземпляр или группу доступности, исходный SQL Server должен удовлетворять следующим требованиям:
При переносе изолированного экземпляра минимальной поддерживаемой версией является SQL Server 2017. При переносе группы доступности поддерживается SQL Server 2016 и более поздних версий.
Выпуском SQL Server должен быть Enterprise.
Необходимо включить функцию группы доступности.
Для баз данных, которые вы хотите перенести, созданы резервные копии в полном режиме.
Если у вас уже есть группа доступности, она должна быть состоянии работоспособности. Если вы создаете группу доступности в рамках этого процесса, она должна быть в состоянии работоспособности до начала миграции.
Порты, используемые экземпляром SQL Server (по умолчанию 1433), и конечная точка зеркалирования базы данных (по умолчанию 5022) должны быть открыты в брандмауэре. Чтобы перенести базы данных в группу доступности, обязательно откройте в брандмауэре порт, используемый прослушивателем.
Виртуальная машина целевого SQL Server
Перед подготовкой виртуальных машин целевого SQL Server к миграции убедитесь, что они удовлетворяют следующим требованиям:
Учетная запись Azure, выполняющая миграцию, назначена как владелец или участник для группы ресурсов, которая включает виртуальные машины целевого SQL Server.
Чтобы вы могли использовать автоматическое заполнение для создания распределенной группы доступности, имя экземпляра для глобального первичного сервера (источника) распределенной группы доступности должно совпадать с именем экземпляра сервера пересылки (назначения) распределенной группы доступности. Если имеется несоответствие имени экземпляра между глобальным первичным и переадресатором, необходимо использовать ручное начальное значение для создания DAG и вручную добавить дополнительные файлы базы данных в будущем.
Для простоты версия экземпляра целевого SQL Server должна совпадать с версией экземпляра исходного SQL Server. Если вы решили выполнить обновление во время миграции с помощью более поздней версии SQL Server в целевом объекте, необходимо вручную заполнить базу данных, а не использовать автоматическое заполнение, как показано в этой серии статей. Дополнительные сведения см. в статье "Миграция на более высокие версии SQL Server".
Выпуском SQL Server должен быть Enterprise.
Необходимо включить функцию группы доступности.
Порты, используемые экземпляром SQL Server (по умолчанию 1433), и конечная точка зеркалирования базы данных (по умолчанию 5022) должны быть открыты в брандмауэре. Чтобы перенести базы данных в группу доступности, обязательно откройте в брандмауэре порт, используемый прослушивателем.
Подключение
Экземпляры исходного и целевого SQL Server должны быть связаны сетевым подключением.
Если экземпляр исходного SQL Server располагается в локальной сети, настройте VPN-подключение типа "сеть — сеть" или подключение Azure ExpressRoute между локальной сетью и виртуальной сетью, в которой располагается виртуальная машина целевого SQL Server.
Если экземпляр исходного SQL Server располагается в виртуальной сети Azure, которая отличается от сети виртуальной машины целевого SQL Server, настройте пиринг между виртуальными сетями.
Проверка подлинности
Чтобы упростить аутентификацию между экземплярами исходного и целевого SQL Server, присоедините оба сервера к одному домену (предпочтительно на стороне источника) и примените аутентификацию на основе домена. Так как это рекомендуемый подход, в инструкциях в этой серии учебников предполагается, что экземпляры исходного и целевого SQL Server принадлежат к одному домену.
Если исходный и целевой серверы относятся к разным доменам, настройте федерацию между двумя доменами или независимую от домена группу доступности.