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

Применимо к:SQL Server

При обновлении экземпляра SQL Server, на котором размещена группа доступности Always On до новой версии 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 в одной и той же группе доступности не поддерживается вне последовательного обновления; такое состояние не должно возникать на длительное время, так как обновление должно осуществляться быстро. Другой вариант обновления SQL Server 2016 (13.x) и более поздних версий — использование распределенной группы доступности.

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

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

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

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

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

    • Запуск 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.

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

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

Схема обновления группы доступности в сценарии HADR.

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

Схема обновления группы доступности с помощью FCI.

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

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

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

ГД Узел1 Узел2 Node3
ГД1 Первичная
ГД2 Первичная
ГД3 Первичная

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

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

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

ГД Узел1 Узел2 Node3
ГД1 Первичная
ГД2 Первичная
ГД3 Первичная

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

Примечание

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

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

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

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

Примечание

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

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

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

Важно!

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

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

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

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

Схема распределенной группы доступности.

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

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

    Примечание

    Выполнение этой команды может занять несколько минут.

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

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

См. также раздел