Обновление реплик группы доступности

Область применения:SQL Server

При обновлении экземпляра SQL Server, на котором размещена группа доступности Always On, до новой версии SQL Server, до нового пакет обновления или накопительного обновления для SQL Server, или при установке нового пакет обновления или накопительного обновления для Windows, можно сократить время простоя основной реплики до одного ручного переключения, выполнив последовательное обновление (или два ручных переключения, если происходит возврат к исходной основной реплике).

Во время обновления вторичная реплика не будет доступна для отработки отказа или для операций только для чтения, а после обновления может потребоваться некоторое время, чтобы вторичная реплика догнала основной узел реплики в зависимости от объема действий на первичном узле реплики (поэтому ожидается высокий сетевой трафик).

Также помните, что после первоначального переключения при отказе на вторичную реплику, работающую под управлением более новой версии SQL Server, базы данных в этой AG (группе доступности) пройдут через процесс обновления, чтобы быть переведёнными на последнюю версию. В это время ни одна из этих баз данных не будет иметь читаемых реплик. Время простоя после начального переключения при отказе зависит от количества баз данных в группе доступности. Если вы планируете переключиться обратно на исходный основной элемент, этот шаг не будет повторяться при обратном переключении.

Предварительные условия

Перед установкой ознакомьтесь со следующими важными сведениями.

• Поддерживаемые обновления версий и выпусков. Убедитесь, что вы можете обновить до последней версии SQL Server из вашей версии операционной системы Windows и версии SQL Server. Например, при обновлении непосредственно из экземпляра SQL Server 2005 уровень совместимости базы данных обновляется.

• Выберите метод обновления ядра СУБД: чтобы обновить в правильном порядке, выберите соответствующий метод обновления и шаги на основе проверки поддерживаемых обновлений версии и выпуска, а также на основе других компонентов, установленных в вашей среде.

• Планирование и проверка плана обновления ядра СУБД: ознакомьтесь с заметками о выпуске и известными проблемами обновления, контрольным списком подготовки и разработкой и тестированием плана обновления.

• Требования к оборудованию и программному обеспечению для установки SQL Server. Изучите требования к программному обеспечению для установки SQL Server. Если требуется дополнительное программное обеспечение, установите его на каждом узле перед запуском обновления, чтобы минимизировать время простоя.

• Проверьте, используется ли отслеживание измененных данных или репликация для баз данных в группах доступности. Если для баз данных включено отслеживание измененных данных (CDC), выполните эти инструкции.

Основы пошагового обновления для групп доступности

При модернизации или обновлении сервера, следует руководствоваться следующими рекомендациями, чтобы минимизировать время простоя и потерю данных для групп доступности.

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

  • Выполните тестирование отказа вручную по крайней мере на одном из экземпляров реплики с синхронной фиксацией.

  • Защитите данные, выполнив полную резервную копию базы данных в каждой базе данных доступности.

  • Запустите DBCC CHECKDB на каждой базе данных доступности.

• Всегда сначала обновляйте удаленные экземпляры вторичных реплик, затем локальные экземпляры вторичных реплик, и только в последнюю очередь — экземпляр первичной реплики.

• Резервные копии не могут возникать в базе данных, которая находится в процессе обновления. Перед обновлением вторичных реплик настройте автоматическое резервное копирование так, чтобы оно создавало резервные копии только первичной реплики. При обновлении до новой версии реплики недоступны для чтения или резервного копирования. Во время обновления неверсии можно настроить автоматические резервные копии для запуска на вторичных репликах перед обновлением первичной реплики.

• Во время обновления версии чтение доступных для чтения вторичных реплик невозможно после обновления этой вторичной реплики и до тех пор, пока основная реплика либо не переключится на обновленную вторичную, либо не будет обновлена.

• Чтобы предотвратить для групп доступности непреднамеренный переход на другой ресурс при обновлении, перед началом операции удалите на всех репликах с синхронной фиксацией конфигурацию перехода на другой ресурс для групп доступности.

• Не обновляйте экземпляр первичной реплики перед переключением группы доступности на обновленный экземпляр с вторичной репликой. В противном случае клиентские приложения могут страдать от длительного простоя во время обновления на основном экземпляре реплики.

• Всегда выполняйте переключение для группы доступности на экземпляр вторичной реплики с синхронной фиксацией. Если вы переключаетесь на вторичную реплику с асинхронной фиксацией, базы данных подвержены риску потери данных, и перемещение данных автоматически приостанавливается до тех пор, пока вы вручную не возобновите его.

• Не обновляйте экземпляр первичной реплики до обновления любого экземпляра вторичной реплики. Обновленная первичная реплика больше не может отправлять журналы в любую вторичную реплику, экземпляр SQL Server которой еще не был обновлен до той же версии. Если перемещение данных к вторичной реплике приостанавливается, то для этой реплики не может осуществляться автоматический переход на резервную реплику, а базы данных высокой доступности становятся подверженными потере данных. Это также применяется во время последовательного обновления, когда вы вручную выполняете отработку отказа из старой первичной в новую первичную. Таким образом, после обновления старого основного может потребоваться возобновить синхронизацию.

• Прежде чем выполнить переключение группы доступности на другую узел, убедитесь, что состояние синхронизации целевого объекта SYNCHRONIZED.

  Предупреждение

  Установка нового экземпляра или новой версии SQL Server на сервер, на котором установлена более ранняя версия SQL Server, может непреднамеренно вызвать сбой для любой группы доступности, размещенной более старой версией SQL Server. Это связано с тем, что во время установки экземпляра или версии SQL Server модульRHS.EXE высокой доступности () обновляется. В результате временно прерывается работа существующих групп доступности в основной роли на сервере. Поэтому настоятельно рекомендуется выполнить одно из следующих действий при установке более новой версии SQL Server в систему, где уже размещена более ранняя версия SQL Server с группой доступности:

  • установить новую версию SQL Server во время периода обслуживания;

  • Переключите группу доступности на вторичную реплику, чтобы она не была основной во время установки нового экземпляра SQL Server.

Процесс последовательного обновления

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

1. Удалите автоматическое переключение на всех репликах с синхронной фиксацией.
2. Обновите все экземпляры вторичной реплики с асинхронной фиксацией.
3. Обновите все экземпляры удаленных вторичных реплик с синхронной фиксацией.
4. Обновите все локальные экземпляры вторичной реплики с синхронной фиксацией.
5. Вручную переведите группу доступности на локальную вторичную реплику с синхронной фиксацией (новая обновлённая версия).
6. Обновление локального экземпляра реплики, на котором ранее размещалась первичная реплика.
7. Настройте партнеров для автоматического переключения таким образом, как нужно.

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

Обновление реплики синхронной фиксации и его отключение в автономном режиме не отложит транзакции на первичном сервере. После отключения вторичной реплики транзакции фиксируются в первичной реплике без ожидания записи журнала во вторичной реплике. Если REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT задано 1 значение "Или 2", первичная реплика может быть недоступна для чтения и записи, если соответствующее количество вторичных реплик синхронизации недоступно во время процесса обновления.

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

Группа доступности с одной удаленной вторичной репликой

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

В этой ситуации вы должны переключить группу доступности на вторичную реплику с асинхронной фиксацией в ходе пошагового обновления. Чтобы предотвратить потерю данных, измените режим фиксации на синхронную фиксацию и дождитесь синхронизации вторичной реплики, прежде чем выполнить переключение на резервную копию AG. Поэтому процесс последовательного обновления может выглядеть следующим образом:

1. Обновите вторичную реплику на удаленной площадке.
2. Измените режим фиксации на синхронную фиксацию.
3. Подождите, пока состояние синхронизации не будет SYNCHRONIZED.
4. Переключите группу доступности на вторичную реплику на удаленном сайте.
5. Модернизируйте или обновите локальный экземпляр реплики (основного сайта).
6. Переключите группу доступности обратно на первичный сайт.
7. Измените режим фиксации на асинхронную фиксацию.

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

• Тщательно выберите период обслуживания во время низкого трафика клиента.

• При апгрейде или обновлении SQL Server на первичном сайте измените режим доступности на асинхронную фиксацию, а затем вернитесь к синхронной фиксации, когда будете готовы выполнить переключение на первичный сайт снова.

Группа доступности с узлами экземпляра отказоустойчивого кластера

Если AG содержит узлы экземпляра отказоустойчивого кластера (FCI), сначала обновите неактивные узлы, а затем активные. На приведенном ниже рисунке показан обычный сценарий для групп доступности с использованием экземпляров FCI для достижения локального высокого уровня доступности и асинхронной фиксации между экземплярами FCI для удаленного аварийного восстановления, а также последовательность обновления.

1. Обновление или модернизация REMOTE2
2. Переключение FCI2 на REMOTE2
3. Обновление или модернизация REMOTE1
4. Обновление или модернизация PRIMARY2
5. Переключить FCI1 на PRIMARY2
6. Обновление или модернизация PRIMARY1

Повышение версии или обновление экземпляров SQL Server с несколькими группами доступности

Если вы работаете с несколькими группами доступности с основными репликами на отдельных узлах сервера (конфигурация Active/Active), путь обновления включает дополнительные этапы отработки отказа, чтобы сохранить высокий уровень доступности в процессе. Предположим, вы выполняете три группы доступности на трех узлах сервера со всеми репликами в синхронном режиме фиксации, как показано в следующей таблице:

В вашей ситуации может потребоваться выполнить последовательное обновление с балансировкой нагрузки.

1. Переключение на AG2 Node3 (для освобождения Node2)
2. Обновление или модернизация Node2
3. Переключение AG1 на Node2 (для освобождения Node1)
4. Обновление или модернизация Node1
5. Переключение на резервный как AG2, так и AG3 на Node1 (чтобы освободить Node3)
6. Обновление или модернизация Node3
7. Переключение при отказе AG3 на Node3

Такая последовательность обновления имеет среднее время простоя менее чем два перехода на другую группу доступности для каждой AG. Результирующая конфигурация показана в приведенной ниже таблице.

В зависимости от конкретной реализации путь обновления может отличаться, а время простоя клиентских приложений может отличаться.

Пошаговое обновление распределенной группы доступности

Чтобы выполнить последовательное обновление распределенной группы доступности, сначала обновите все вторичные реплики. Затем выполните отработку отказа для перенаправляющего устройства и обновите единственный оставшийся экземпляр второй группы доступности. После обновления всех остальных реплик переключите на резервную глобальную первичную и обновите последний оставшийся экземпляр первой группы доступности. Подробная схема с шагами представлена в следующем разделе.

В зависимости от конкретной реализации путь обновления может отличаться, а время простоя клиентских приложений может отличаться.

Общие шаги для обновления распределенной группы доступности

1. Создайте резервную копию всех баз данных, включая системные базы данных и участвующие в группе доступности.
2. Обновите и перезапустите все вторичные реплики второй группы доступности (вниз по потоку).
3. Обновите и перезапустите все вторичные реплики первой группы доступности (восходящая часть).
4. Переключите первичную реплику пересылки на обновленную реплику вторичной группы доступности.
5. Дождитесь синхронизации данных. Базы данных должны отображаться как синхронизированные во всех репликах с синхронной фиксаций, и глобальная первичная реплика должна быть синхронизирована с сервером пересылки.
6. Обновите и перезапустите последний экземпляр второй группы доступности.
7. Переключите глобальную первичную реплику на обновленную вторичную реплику первой группы доступности.
8. Обновите последний экземпляр первой группы доступности.
9. Перезапустите обновленный сервер.
10. (Необязательно) Восстановите в обеих группах доступности исходные первичные реплики.

Пример схемы последовательного обновления распределенной группы доступности

Шаги для обновления экземпляров на этой диаграмме:

1. Сделайте резервное копирование всех баз данных, включая системные базы данных, и тех, которые участвуют в группе доступности.
2. Обновите NODE4\SQLAG (вторичный элемент AG2) и перезапустите сервер.
3. Обновите NODE2\SQLAG (вторичную версию AG1) и перезапустите сервер.
4. Ошибка AG2 переносится с NODE3\SQLAG на NODE4\SQLAG.
5. Обновите NODE3\SQLAG и перезапустите сервер.
6. Переключите отказ AG1 с NODE1\SQLAG на NODE2\SQLAG.
7. Обновите NODE1\SQLAG и перезапустите сервер.
8. (Необязательно) Переключитесь на исходные первичные реплики.
   1. Переключение при отказе AG2 с NODE4\SQLAG на NODE3\SQLAG.
   2. Переключить возврат AG1 с NODE2\SQLAG на NODE1\SQLAG.

Если бы третья реплика существовала в каждой группе доступности, вы обновили бы ее до NODE3\SQLAG и NODE1\SQLAG.

Особые действия для записи измененных данных или репликации

В зависимости от примененного обновления для баз данных реплики группы доступности, которые включены для отслеживания или репликации измененных данных, могут потребоваться дополнительные шаги. См. заметки о выпуске для обновления, чтобы определить необходимость выполнения приведенных далее шагов.

1. Обновите каждую вторичную реплику.

2. Завершите обновление всех вторичных реплик, затем выполните перенос группы доступности на обновленный экземпляр.

3. Выполнение следующего запроса Transact-SQL на экземпляре, где размещена первичная реплика.

   EXECUTE [master].[sys].[sp_vupgrade_replication];
   

   Примечание.

   Выполнение этой команды может занять несколько минут. Пропустите этот шаг, если вы находитесь в SQL Server 2019 CU1 или более поздней версии. Чтобы узнать больше, ознакомьтесь с KB4530283.

4. Обновление экземпляра, который изначально был первичной репликой.

Дополнительные сведения см. в статье о функциональных возможностях CDC после обновления до последней версии cu.

Связанный контент

• Обновление SQL Server с помощью мастера установки
• Установка и настройка SQL Server в Windows из командной строки