Тестирование работы AlwaysON при обновлении MS SQL Server с версии 2019 до версии 2022

Всем привет, уважаемые читатели блога pyatilistnik! Сегодня хотел с вами поделиться результатами тестирования работы кластера высокой доступности AlwaysON при обновлении MS SQL Server с версии 2019 до версии 2022 с установкой обновления CU30. Перед тем как обновлять в боевой среде, я решил протестировать на стенде и поделиться результатами. Посмотрим как ведут себя базы данных, какая будет доступность\отказоустойчивость в разные моменты обновления и какой будет результат. Надеюсь, это поможет вам заранее спланировать обновления кластера высокой доступности и знать, что может произойти. Поехали!

Установку операционных систем, создание WSFC (Windows Failover Cluster), настройка Quorum-диска, установку двух тестовых MS SQL 2019 серверов (или как ещё любят говорить - инстансов), установку SQL Server Management Studio (SSMS), создание группы доступности и добавление баз данных в группы доступности — пропустим (будут отдельные выпуски). Также вы можете почитать, есть отдельные статьи по разворачиванию кластера высокой доступности с нуля, например тут — или тут.

Считаем, что у нас есть готовый стенд и следующее исходное состояние:

2 инстанса с именами по умолчанию (MSSQLSERVER) на двух Windows Server Standard 2022:

1 - SQLTest01 (Secondary replica);

2 - SQLTest02 (Primary replica);

Версия MS SQL Server 2019 с пакетом накопительного обновления CU32. Об этом говорит надпись 15.0.4430.1 - код версии с установленным CU на картинке ниже.

Для тестов я добавил 2 базы данных разных размеров, Test_Small_Base - около 20 МБ и Test_BIG_Base - 180 ГБ. Зеленые галочки справа (так же как и   Availibility group state - Healthy) говорят, что данные в базах синхронизируются в реальном времени.

Сначала проверим, что переключение между репликами (Failover) работает. Для этого раскрываем вкладки Always On High Availability - Availability Group - AGTestK.  Нажимаем правой кнопкой мыши по выбранной группе доступности (AGTestK (Primary)) и нажимаем Failover... Это можно сделать как на Primary реплике, так и на Secondary:

Появится всплывающее окно Introduction. Тут просто Next:

Далее выбираем, кто будет основной репликой,  т.е. Primary replica. Так как в нашем кластере всего два узла, выбор не велик. Ставим галочку напротив сервера SQLTest01 и жмём Next.

Далее мы присоединяемся к вторичной реплике, чтобы перевести её в режим первичной или основной, для этого сначала нажимаем Connect...:

Во всплывающем окне потребуется ввести данные для подключения. Скорее всего, 99%, они у вас по умолчанию уже вшиты и останется нажать только кнопку Connect. Я использую метод Authentication - Windows Authentication, в поле User name уже указана моя учетная запись. Если вы работаете во внутренней сети, то рекомендую поставить галочку - Trust server certificate, чтобы не было проверки на доверенность сертификата, а он просто использовался. Если у клиента нет корневого сертификата SQL сервера, подключение не будет установлено без этой галочки. Для облачных баз не рекомендуется ставить галку из-за соображений безопасности.

Теперь, когда связность есть, можно нажать Next и начать переключение реплик:

Нажимаем Finish и ждем окончания переключения реплики:

Запускается процесс переключения, долго он не занимает, обычно до 10 секунд:

Получаем окно об успешном завершении переключения реплики, нажимаем Close:

Как видно, переключение (Failover) на нашем тестовом стенде работает и мы получаем исходное состояние следующего вида:  SQLtest01 - основная реплика, SQLtest02 - вторичная реплика. На картинке — вывод команды Show Dashboard:

И вот настал момент, когда нам нужно обновить наш кластер высокой доступности с MS SQL 2019 до MS SQL 2022. Хотел напомнить, что обратного пути, так называемого downgrade - нет. Можно лишь откатывать Cumulative Update. Поэтому путь только один - полный вперёд! Настоятельно рекомендую начать процесс обновления с вторичной реплики, так как в процессе установки служба сервера (SQL Server (MSSQLSERVER)) будет остановлена и произойдет потеря связи с базами данных, что в случае использования кластера высокой доступности в продуктовой среде — неприемлемо.

Процесс обновления сервера SQL в целом выглядит просто, однако для полноты картины, я его распишу:

1. Скачиваем дистрибутив MS SQL Server 2022 с официального или альтернативного сайта (например вот);
2. Монтируем диск и запускаем setup.exe (рекомендую запускать из-под Администратора);
3. После запуска инсталлятора переходим во вкладку Installation и выбираем Upgrade from a previous version of SQL Server:

Галочку Use Microsoft Update to check for updates (recommended) лучше не ставить, чтобы не было неожиданностей и рассинхрона по версиям. Нажимаем Next:

Проверка, распаковка, подготовка к установке. Дожидаемся когда Status - Completed и нажимаем Next:

Выбор версии, Edition. Так как я использую корпоративную версию Enterprise и у меня есть лицензионный ключ, то указываю  и ставлю галочку - I have a SQL Server license only. Если вы разворачиваете MS SQL Server в рамках тестирования или обучения, рекомендуется использовать версию Developer (Полная функциональность Enterprise версии). Остальные версии - Express (ограничение по ресурсам памяти и по объему Базы Данных) и Evaluation (функционал Enterprise, но срок действия 180 дней). Нажимаем Next:

Далее окно с лицензированием - Licence Terms, устанавливаем галку I accept the license terms and Privacy Statement и нажимаем Next:

Далее идет окно с выбором инстанса - Select Instance для обновления, по умолчанию он один, стандартный - MSSQLSERVER. У меня на серверах для тестирования их несколько. Выбираем нужный в поле Instance to upgrade и нажимаем Next:

Окно Select Features, проверяем, что по умолчанию установлена галочка напротив Ядра СУБД  Database Engine Services и нажимаем Next:

Далее окно Instance Configuration, где можно поменять место расположения SQL Server, что делать очень не рекомендуется, особенно при обновлении, так как потом нужно будет искать какие и где зависимости не будут работать. Оставляем по умолчанию и нажимаем Next:

Далее окно Ready to Upgrade, чтобы мы могли проверить что всё ранее указанное — указано правильно, проверяем и жмём Upgrade:

После окончания процесса обновления получаем окно об успешном обновлении SQL Server'а.

После установки новой версии MS SQL Server, предлагаю перезагрузиться и/или сразу установить Cumulative update.

Сразу после обновления вторичной реплики получаем такую картину в Dashboard. Ошибка связана с недоступностью вторичной реплики. В Dashboard информация меняется в реальном времени (по умолчанию). Обращаем внимание на разницу в версиях MS SQL Server. Основная реплика у нас 2019 (15.0.4430.1), вторичная — уже 2022 (16.0.1000.6):

Если нажать в группе доступности на реконнект второй реплики — ничего не произойдет. Такое состояние будет до перезагрузки сервера или роли (службы). Поэтому устанавливаем Cumulative update CU19 и перезагружаем вторичную реплику.

После перезагрузки сервера работа группы доступности восстанавливается:

Продолжим наше тестирование, делаем Failover (как делали в самом начале статьи), переключаем основную реплику с SQLtest01 -> SQLtest02 и получаем рассинхрон. Даже если зайти на вторичную реплику и нажать Resume Data Movement - это не поможет, состояние останется таким же, как на картинке ниже. Базы данных на вторичной реплике будут в состоянии - Not Synchronizing / In Recovery:

Ситуация так себе. Единственное, что остается, обновить вторичную реплику и надеяться, что реплики и базы данных засинхронизируются. Но перед этим мы проделаем ещё 2 промежуточные задачи:

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

Пункт 1. После добавления новой базы на сервер и в группу доступности на основной реплике и вторичной реплике получаем следующую картину:

Видим, что на основной реплике база данных Test_new_base доступна, а до вторичной реплики она "не доехала". Она не отображается в локальных базах, а в группе доступности указана с ошибкой. Попытка добавить ее "вручную", командой Join to Availability Group... тоже успеха не принесет, получим ошибку, что базы данных просто не существует:

Пункт 2. Перезагружаем вторичную реплику. И видим результат. Стоит обратить внимание на вкладки Availability Replicas на основной и вторичной реплике. Если провалиться внутрь и нажать правой кнопкой мыши на SQLTest02 и Connect..., то это ни к чему не приведет. Разные версии после Fаilover'а дружить отказываются:

Приступаем к финальному этапу нашего тестирования. Обновление вторичной реплики. Процесс обновления SQLTest01 (на текущее состояние этот сервер в роли вторичной реплики) аналогичен уже ранее произведенным действиям. Расписывать детально не буду, только по пунктам:

1. Делаю Upgrade MS SQL Server 2019 -> MS SQL Server 2022 (аналогично первичной реплике);
2. Устанавливаю CU19 (аналогично первичной реплике);
3. Перезагружаю Windows-сервер.

После обновления и перезагрузки получается следующая картина. Обе реплики переходят в состояние Healthy, однако в автоматическом режиме засинхронизировалась только новая база данных Test_new_base. Остальные базы данных на вторичной реплике остались в статусе Not Synchronizing / In Recovery:

Для того чтобы базы данных синхронизировались их нужно "подтолкнуть руками", выполнив команду Resume Data Movement...:

Во всплывающем окне нажимаем ОК и дожидаемся окончания восстановления данных:

Вот в целом и всё, базы данных переходят в режим Synchronized, далее мы проверим что переключение реплик работает (на изображении ниже уже результат переключения):

Подведем итог: проделанное тестирование показало, что кластер AlwaysON может работать на разных версиях MS SQL Server, его можно последовательно обновлять, начиная со вторичной реплики и в случае нештатной ситуации, его можно переключать на более низкую версию сервера, но только 1 раз. Поэтому рекомендую обновлять обе реплики последовательно, но с минимальным временным интервалом!

P.S. На последнем изображении есть один дефект, пасхалка:). Кто знает, как ее полечить, прошу в комментарии! Всем хорошего дня, надеюсь не сильно Вас утомил!)