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

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

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

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

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

Примечание.

В этой статье мы ограничимся обсуждением обновления только SQL Server. Здесь не рассматривается обновление операционной системы с отказоустойчивым кластером Windows Server (WSFC). Обновление операционной системы Windows, на которой размещен отказоустойчивый кластер, не поддерживается для операционных систем ниже Windows Server 2012 R2. Обновление узла кластера под управлением Windows Server 2012 R2 описано в статье Cluster Operating System Rolling Upgrade (Последовательное обновление операционной системы в кластере).

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

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

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

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

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

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

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

Примечание.

Использование различных версий экземпляров SQL Server в одной и той же AG (группе доступности) не поддерживается вне последовательного обновления и не должно оставаться в таком состоянии в течение длительных периодов времени, так как обновление должно проводиться быстро. Другой вариант обновления SQL Server 2016 (13.x) и более поздних версий — использование распределенной группы доступности.

Примечание.

Использование компонента Windows с поддержкой обновления кластера (CAU) для обновления групп доступности AlwaysOn не поддерживается.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

Примечание.

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

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

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

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

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 с несколькими группами доступности

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

АГ	Узел1	Узел2	Узел3
AG1	Основной
AG2		Основной
AG3			Основной

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

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

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

AG	Узел1	Узел 2	Узел3
AG1		Основной
ГД2	Основной
ГД3			Основной

Фактический процесс обновления (как и время простоя клиентских приложений) может отличаться в зависимости от особенностей реализации вашей системы.

Примечание.

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

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

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

Фактический процесс обновления (как и время простоя клиентских приложений) может отличаться в зависимости от особенностей реализации вашей системы.

Примечание.

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

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

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

Внимание

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

Каждый раз при проверке синхронизации рекомендуется обновлять узел базы данных и узел распределенной AG-группы в SQL Server Management Studio. Когда все будет синхронизировано, создайте снимок экрана состояний каждой реплики. С его помощью вы сможете отслеживать, на каком шаге находитесь; перед переходом к следующему шагу он послужит подтверждением того, что все работает правильно, а при возникновении проблем поможет в устранении неполадок.

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

группа доступности	Первичная реплика	Вторичная реплика
AG1	NODE1\SQLAG	NODE2\SQLAG
AG2	NODE3\SQLAG	NODE4\SQLAG
DistributedAG	AG1 (глобальная)	АG2 (сервер пересылки)

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

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.

Внимание

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

Рекомендация: Каждый раз при проверке синхронизации обновляйте узел базы данных и узел распределенной AG в SQL Server Management Studio. Когда всё будет синхронизировано, сделайте снимок экрана и сохраните его. С его помощью вы сможете отслеживать, на каком шаге находитесь; перед переходом к следующему шагу он послужит подтверждением того, что все работает правильно, а при возникновении проблем поможет в устранении неполадок.

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

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

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

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

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

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

   Примечание.

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

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

Дополнительные сведения см. в статье функциональность CDC может быть нарушена после обновления до последнего CU (функциональность записи измененных данных может нарушиться после обновления до последнего накопительного обновления).

См. также

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