Стоит задача миграции БД на новое железо с одновременным повышением версии с 2014 до 2016, сейчас сервер в кластере AlwaysOn с синхронными нодами. Если убрать оттуда один узел и добавить второй уже на новой машине с 2016 и распространить на него базы (без повышения уровня БД), такой кластер заработает хоть теоретически? Что-то мне подсказывает, что нет, но чем черт не шутит.

Гавриленко Сергей Алексеевич,

Да, вы оказались правы, впрочем, по порядку, кому-то будет полезно.

Прогнали на тестовом стенде. Оставили одну реплику на 2014, ввели в кластер сервер на 2016, распространили на него группу доступности. Она осталась в состоянии Synchronized/Restoring. Вроде как и зеленая, но недоступна. Ну ладно, сделали на новый сервер failover, а группа возьми и поднимись. На старом сервере она сразу ушла в несознанку - Not synchronized. Ну а дальше уже старую реплику вывели из группы, подняли версию, добавили второй узел на 2016 и т.д., все ожило.
Не ожидал, если честно.

aleksrov,

Ага, все-таки этот способ не самопальный, спасибо.

И да, мы не держим все на primary, у нас есть две группы, достаточно независимых, они все основное время работают на разных репликах, мы т.о. распределили нагрузку. Если между базами двух групп нужна связь - делается через linked server.

Если кому интересно, провели операцию на продакшене. Терабайты данных переехали на новое железо и новую версию сиквела без единого простоя для платформы. Годная тема.
Даже если у вас не кластер, для переезда можно сделать из одного узла, включить новую железку и переехать.

Mind,

Нельзя, ну и что?