Миграция группы доступности AlwaysON в другой кластер

добавлено: 09 ноя 20
понравилось:0
просмотров: 17698
комментов: 4

теги:

Автор: Александр Гладченко

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

Продолжить чтение.

Комментарии


  • при наличии пункта 14, в чем приемущество данного подхода перед ручным рестором базы и подкатыванием логов в процессе подготовки миграции?
    С ув.Макс

  • 02 марта 2021, 16:40 Александр Гладченко

    Всё делается для сокращения времени недоступности баз группы. На тестах у меня сама миграция делалась почти мгновенно, на практике для большого числа баз из-за неизбежно го рекавери на базах больше 30Тб это занимало от10 минут до получаса. На маленьких базах будет быстро, пару минут.

  • Согласен что переподнять листенера и группы будет быстрее чем тоже самое+последний лог. Но рекавери по любому прийдется ждать один раз на новой праймари реплике. Вопрос как старый кластер отреагирует если ему добавить штук 5 реплик с нового, для 30ТБ+ баз. Мы как раз собираемся писать план миграции для sql2016ee->sql2019ee
    Спасибо, статья кратко и по сути...

  • 02 марта 2021, 17:16 Александр Гладченко

    Это не миграция в новую версию MSSQL, миграция только в другой КЛАСТЕР который может быть на более новой винде.
    Если добавляете 5 реплик той же версии MSSQL, проблем не должно быть.



Необходимо войти на сайт, чтобы оставлять комментарии