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

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

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

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

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

Примечание.

В этой статье мы ограничимся обсуждением обновления только 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 в одной и той же группе доступности не поддерживается вне последовательного обновления; такое состояние не должно возникать на длительное время, так как обновление должно осуществляться быстро. Другой вариант обновления 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 задано значение или , 21 первичная реплика может быть недоступна для чтения и записи, если соответствующее количество вторичных реплик синхронизации недоступно во время процесса обновления.

Примечание.

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

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

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

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

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

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

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

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

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

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

1. Обновление или обновление REMOTE2
2. Отработка отказа FCI2 в REMOTE2
3. Обновление или обновление REMOTE1
4. Обновление или обновление PRIMARY2
5. Отработка отказа FCI1 в PRIMARY2
6. Обновление или обновление PRIMARY1

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

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

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

Иногда уместно будет выполнить последовательное обновление с балансировкой нагрузки. Операция будет включать следующие шаги:

1. Отработка отказа в AG2 Node3 (чтобы освободиться Node2)
2. Обновление или обновление Node2
3. Отработка отказа ag1 Node2 (чтобы освободить)Node1
4. Обновление или обновление Node1
5. Отработка отказа как ag2, так и AG3 Node1 (для освобождения Node3)
6. Обновление или обновление Node3
7. Отработка отказа ag3 в Node3

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

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

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

Примечание.

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

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

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

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

Примечание.

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

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

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

Внимание

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

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

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

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

Инструкции по обновлению экземпляров по этой схеме

1. Резервное копирование всех баз данных, включая системные базы данных, и тех, кто участвует в группе доступности.
2. Обновите NODE4\SQLAG (вторичную группу доступности 2) и перезапустите сервер.
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.

Внимание

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

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

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

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

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

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

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

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

   Примечание.

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

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

Дополнительные сведения см. в статье CDC functionality may break after upgrading to the latest (Возможное нарушение функциональности записи измененных данных после обновления до последнего накопительного обновления).

См. также

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