Переключение при отказе и режимы переключения при отказе (группы доступности Always On)

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

В этой статье описаны автоматический и ручной режимы отработки отказа для Always On Availability Groups SQL Server.

Обзор

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

Примечание.

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

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

Формы переключения при отказе, которые поддерживает данная реплика доступности, определяются свойством режима переключения при отказе. Для данной реплики доступности возможные режимы переключения зависят от режима доступности реплики следующим образом:

  • Реплики синхронной фиксации поддерживают два параметра: автоматически или вручную. Настройка «Автоматически» поддерживает как автоматическое, так и ручное переключение при отказе. Чтобы предотвратить потерю данных, для автоматического переключения при отказе и планового переключения при отказе требуется, чтобы целевым объектом переключения при отказе была вторичная реплика с синхронной фиксацией и исправным состоянием синхронизации (это означает, что каждая вторичная база данных на целевом объекте переключения при отказе синхронизирована с соответствующей первичной базой данных). Всякий раз, когда вторичная реплика не соответствует обоим этим условиям, она поддерживает только принудительное переключение. Принудительное переключение при сбое также поддерживается у реплик в состоянии RESOLVING.

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

Примечание.

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

Изменения SQL Server 2025

В SQL Server 2025 представлены следующие изменения:

Быстрое аварийное переключение для устойчивых проблем с работоспособностью

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

Поведение WSFC при отказе управляется значением RestartThreshold. По умолчанию RestartThreshold установлено значение 1 для группы доступности Always On, что означает, что WSFC пытается перезапустить ресурс на текущем узле перед аварийным переключением.

Начиная с SQL Server 2025 (17.x), можно установить RestartThreshold для группы доступности Always On на значение 0, что является указанием для WSFC немедленно выполнить переключение на резервный ресурс при обнаружении постоянной проблемы работоспособности. Это полезно для сценариев, когда требуется свести к минимуму время простоя и убедиться, что группа доступности всегда доступна в работоспособной реплике.

Существует очевидный компромисс:

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

Вы можете использовать Диспетчер отказоустойчивости кластеров или PowerShell для задания RestartThreshold ресурса группы доступности Always On.

Например, чтобы задать RestartThreshold значение 0 для группы доступности с именем ag1, используйте следующую команду:

(Get-ClusterResource -Name "ag1").RestartThreshold = 0

Чтобы проверить текущий RestartThreshold параметр, выполните следующую команду:

Get-ClusterResource -Name "ag1" | Format-List *

Улучшение диспетчеризации асинхронных запросов страниц

При отработки отказа группы доступности каждая реплика должна найти общую точку восстановления для синхронизации. Точка восстановления поддерживает стабильность группы доступности, чтобы она могла продолжать распространять изменения. Отмена повторного выполнения является частью этого процесса синхронизации. Отмена повторного выполнения происходит, когда вторичная реплика должна отменить транзакции, чтобы получить общую точку восстановления. Отмена повторного выполнения наиболее распространена во время переключения аварийного восстановления (DR) на асинхронную реплику с FAILOVER_ALLOW_DATA_LOSS.

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

Чтобы улучшить отмену операции повторного выполнения в этом сценарии, SQL Server 2025 (17.x) вводит обновление механизма синхронизации, благодаря которому группа доступности теперь выполняет запросы страниц асинхронно и пакетами.

Рассмотрим следующее:

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

Базы данных переключаются на разрешение состояния после сбоя

В редких случаях одна или несколько баз данных группы доступности могут оставаться в состоянии Not Synchronizing после того, как группа доступности выходит в офлайн на короткое время из-за временной потери кворума WSFC, например, из-за временного отключения сети или перезапуска большинства узлов кластера. Обновление логики восстановления группы доступности, введенной в SQL Server 2025 (17.x), повышает внутреннюю терпимость к этому типу потери кворума кластера и предотвращает зависание баз данных группы доступности в состоянии не синхронизации после возвращения группы доступности в сеть снова.

Условия и определения

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

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

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

Автоматическое переключение настроено

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

Задана отработка отказа синхронной фиксации

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

Весь набор аварийного переключения

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

Обзор переключения при отказе

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

Форма переключения при отказе Режим асинхронной фиксации Режим синхронной фиксации с режимом ручного переключения при отказе Режим синхронной фиксации с автоматическим переключением при отказе
автоматическое переключение при отказе нет нет Да
Запланированное ручное переключение при отказе нет Да Да
Принудительное переключение при отказе Да Да Да1

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

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

Внимание

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

Наборы аварийного переключения

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

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

  • Набор для отработки отказа с синхронной фиксацией (необязательно): В данной группе доступности — набор из двух или трех реплик доступности (включая текущую первичную реплику), если таковые имеются, настроенных на режим синхронной фиксации. Набор отработки отказа с синхронной фиксацией вступает в силу, только если для вторичных реплик настроен режим ручного переключения при отказе и как минимум одна вторичная реплика в настоящее время находится в состоянии «SYNCHRONIZED» с первичной репликой.

  • Полный набор для отработки отказа: В пределах данной группы доступности это набор всех реплик доступности, операционное состояние которых в настоящий момент — В СЕТИ, независимо от режима доступности и режима отработки отказа. Весь набор отработки отказа становится актуальным, если ни одна вторичная реплика в настоящее время не находится в состоянии SYNCHRONIZED с первичной репликой.

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

Например, рассмотрим группу доступности, включающую четыре реплики доступности:

Реплика Настройки режима доступности и режима отработки отказа
а Синхронная фиксация с автоматическим переключением при отказе
Б Синхронная фиксация с автоматическим переключением при отказе
С Синхронная фиксация только при плановом ручном переключении при отказе
Д Асинхронная фиксация (только при принудительном переключении при отказе)

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

Влияние конфигурации первичной реплики на отработку отказа

Автоматическое переключение при отказе

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

В этом разделе.

Условия, необходимые для автоматического переключения при отказе

Автоматическое переключение при отказе выполняется только при следующих условиях:

  • Существует набор автоматического переключения при отказе. Этот набор состоит из первичной реплики и вторичной реплики ( цель автоматического перехода на другой ресурс), причем на обеих настроен режим синхронной фиксации и обе реплики имеют режим перехода на другой ресурс AUTOMATIC. Если для первичной реплики установлено значение MANUAL переключения, автоматическое переключение не может произойти, даже если для вторичной реплики задано автоматическое переключение.

    Дополнительные сведения см. в разделе Режимы доступности (группы доступности Always On).

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

    Совет

    Группы доступности Always On контролируют работоспособность обеих реплик в наборе автоматического переключения при отказе. Если одна из реплик завершается сбоем, состояние работоспособности группы доступности устанавливается в значение CRITICAL. Если вторичная реплика завершается ошибкой, автоматическое переключение невозможно, так как целевая реплика для автоматического переключения недоступна. В случае сбоя первичной реплики группа доступности выполнит переход на вторичную реплику. Пока бывшая первичная реплика не вернется в сеть, цели для автоматического переключения при отказе не будет. В любом случае, чтобы обеспечить доступность в маловероятном случае последовательного сбоя, рекомендуется настроить другую вторичную реплику в качестве цели автоматического переключения при отказе.

    Дополнительные сведения см. в разделах Использование политик Always On для просмотра состояния группы доступности (SQL Server) и Изменение режима отработки отказа реплики доступности (SQL Server).

  • Кластер WSFC имеет кворум. Дополнительные сведения см. в разделе Режим кворума и участвующая в голосовании конфигурация WSFC (SQL Server).

  • Основная реплика стала недоступной, и выполнены уровни условия переключения на резерв, установленные вашей гибкой политикой переключения на резерв. Дополнительные сведения об уровнях условий перехода на другой ресурс см. в разделе Гибкая политика перехода на другой ресурс для автоматического перехода на другой ресурс группы доступности (SQL Server).

Как работает автоматическое переключение при отказе

Автоматическое переключение на резервный ресурс запускает следующую последовательность действий:

  1. Если экземпляр сервера, на котором размещена текущая первичная реплика, все еще работает, он изменяет состояние баз данных-источников на DISCONNECTED и отсоединяет всех клиентов.

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

    Примечание.

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

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

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

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

Настройка автоматического переключения при отказе

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

Настроить автоматическое переключение на резерв

  1. Убедитесь, что вторичная реплика настроена для использования режима доступности синхронной фиксации. Дополнительные сведения см. в разделе Изменение режима доступности для реплики доступности (SQL Server).

  2. Задайте автоматический режим перехода на другой ресурс. Дополнительные сведения см. в разделе Изменение режима перехода на другой ресурс для реплики доступности (SQL Server).

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

Плановое ручное переключение без потери данных

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

На следующем рисунке показаны этапы планового переключения при отказе.

  1. Перед переключением при отказе первичная реплика размещена на экземпляре сервера на Node01.

  2. Администратор базы данных инициирует плановое переключение на резервный ресурс. Целевой объект переключения при отказе — это реплика доступности, размещенная на экземпляре сервера на Node02.

  3. Целевой узел переключения при отказе (на Node02) становится новой первичной репликой. Поскольку это запланированное переключение, бывшая первичная реплика во время переключения переходит во вторичную роль и немедленно переводит свои базы данных в состояние «в сети» как вторичные базы данных.

Иллюстрация запланированной отработки отказа вручную

В этом разделе.

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

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

  • Настроен для работы в режиме синхронной фиксации.

  • В настоящее время синхронизировано с первичной репликой.

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

Как работает плановое ручное аварийное переключение

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

  1. Чтобы не допустить выполнения новых пользовательских транзакций в исходных базах данных-источниках, кластер WSFC отправляет запрос на перевод первичной реплики в режим «вне сети».

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

    Примечание.

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

  3. Вторичная реплика становится новой первичной репликой, а бывшая первичная реплика становится вторичной репликой.

  4. Новая первичная реплика откатывает все незафиксированные транзакции и подключает свои базы данных к сети в качестве основных баз данных. Все вторичные базы данных кратко помечаются как НЕ СИНХРОНИЗИРОВАНЫ до тех пор, пока они не подключатся и не ресинхронизируются с новыми главными базами данных. Этот процесс не откатывает никакие подтверждённые транзакции.

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

    Примечание.

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

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

Поддержка уровня доступности при обновлениях

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

Принудительное переключение при отказе (с возможной потерей данных)

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

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

Для принудительного переключения при отказе требуется наличие кворума у кластера WSFC. Дополнительные сведения о настройке кворума и принудительном создании кворума см. в разделе Отказоустойчивая кластеризация Windows Server (WSFC) с SQL Server.

В этом разделе.

Как работает принудительное переключение при отказе

Принудительное переключение при отказе инициирует передачу первичной роли целевой реплике, роль которой находится в состоянии SECONDARY или RESOLVING. Узел переключения при отказе становится новой первичной репликой и немедленно начинает обслуживать клиентов, используя свои копии баз данных. Когда бывшая первичная реплика становится доступной, она переходит к вторичной роли, а её базы данных становятся вторичными базами данных.

Все вторичные базы данных (включая бывшие первичные базы данных, когда они станут доступны) находятся в состоянии SUSPENDED. В зависимости от предыдущего состояния синхронизации данных в приостановленной вторичной базе данных, она может подходить для восстановления недостающих зафиксированных данных этой первичной базы данных. На вторичной реплике, настроенной для доступа только на чтение, можно выполнять запросы к вторичным базам данных, чтобы вручную обнаружить недостающие данные. Затем можно выполнить инструкции Transact-SQL в новых базах данных-источниках для внесения необходимых изменений.

Риски принудительного переключения при отказе

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

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

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

Режим доступности вторичной реплики База данных синхронизирована? Потеря данных возможна?
Синхронная фиксация Да нет
Синхронная фиксация нет Да
Асинхронная фиксация нет Да

Вторичные базы данных отслеживают только две ветви восстановления, поэтому, если выполнить несколько принудительных отработок отказа, любая вторичная база данных, которая начала синхронизацию данных при предыдущей принудительной отработке отказа, может не суметь возобновить синхронизацию. Если это происходит, все базы данных-получатели, которые не могут быть возобновлены, должны быть удалены из группы доступности, восстановлены до правильной точки во времени и повторно присоединены к группе доступности. В этом сценарии может наблюдаться ошибка 1408 с состоянием 103 (ошибка: 1408, серьезность: 16, состояние: 103). Восстановление невозможно в нескольких ветвях восстановления, поэтому после выполнения более одного принудительного переключения при отказе обязательно выполните резервное копирование журнала транзакций.

Почему после принудительного формирования кворума требуется принудительное переключение при отказе

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

Например, рассмотрим кластер WSFC с размещенной на трех узлах группой доступности. Первичная реплика находится на узле A, a на каждом из узлов B и C размещается вторичная реплика. Узел C отсоединяется от кластера WSFC, в то время как локальная вторичная реплика находится в состоянии SYNCHRONIZED. Однако узел A и узел B сохраняют работоспособный кворум, а группа доступности остается подключенной к сети. На узле A первичная реплика по-прежнему принимает обновления, а на узле B вторичная реплика продолжает синхронизироваться с первичной репликой. На узле C вторичная реплика становится несинхронизированной и все больше отстает от первичной реплики. Однако, поскольку узел C отключен от сети, реплика остается (неправильно) в состоянии SYNCHRONIZED.

Если кворум будет потерян, а затем принудительно установлен на узле A, состояние синхронизации группы доступности в кластере WSFC должно отображаться корректно, при этом вторичная реплика на узле C должна отображаться как несинхронизированная (UNSYNCHRONIZED). Однако, если на узле C принудительно установлен кворум, синхронизация группы доступности будет работать неправильно. Синхронизация на кластере вернется к состоянию, существовавшему в то время, когда узел C был отключен — вторичная реплика на узле C будет неправильно показана как синхронизированная (SYNCHRONIZED). Так как запланированные отработки отказа вручную гарантируют безопасность данных, они запрещены для возвращения группы доступности в режим онлайн после принудительного достижения кворума.

Отслеживание возможной потери данных

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

  1. Подключитесь к первичной реплике.

  2. Выполните запрос к столбцам last_commit_lsn (LSN последней зафиксированной транзакции) и last_commit_time (время последней фиксации транзакции) динамического административного представления sys.dm_hadr_database_replica_states.

  3. Сравните значения, возвращаемые для каждой базы данных-источника и каждой из ее баз данных-получателей. Различие между их номерами LSN последней фиксации указывает величину отставания.

  4. Можно инициировать предупреждение, если величина отставания для базы данных или набора баз данных превышает заданное максимальное отставание за определенный период времени. Например, запрос может быть инициирован заданием, которое выполняется каждую минуту на каждой базе данных-источнике. Если разница между last_commit_time первичной базы данных и любой из ее вторичных баз данных с момента последнего выполнения задания превысила целевой показатель точки восстановления (RPO) (например, 5 минут), задание может выдать предупреждение.

Внимание

Если кластер WSFC не имеет кворума или кворум был создан принудительно, last_commit_lsn и last_commit_time равны NULL. Сведения о том, как можно избежать потери данных после принудительного формирования кворума, см. в разделе "Возможные способы избежать потери данных после принудительного формирования кворума" статьи Выполнение принудительного переключения при отказе вручную для группы доступности (SQL Server).

Управление возможной потерей данных

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

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

Изначальная первичная реплика снова подключена

После сбоя бывшая первичная реплика обычно быстро восстанавливает соединение со своим партнером. После повторного подключения, исходная первичная реплика становится вторичной репликой. Ее базы данных становятся вторичными базами данных и входят в состояние SUSPENDED. Новые базы данных-получатели не будут откатированы, если только вы не возобновляете их.

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

  • Если потеря данных недопустима, следует удалить базы данных из группы доступности, чтобы сохранить их.

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

  • Если потеря данных будет приемлема для ваших бизнес-целей, можно возобновить работу вторичных баз данных.

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

Исходная первичная реплика не восстановила соединение

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

  • Если потенциальная потеря данных допустима

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

  • Если потеря данных недопустима

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

    Затем на экземпляре Server, на котором размещена новая вторичная реплика, можно удалить приостановленную вторичную базу данных и создать новую вторичную базу данных, восстановив эту резервную копию (и по крайней мере одну последующую резервную копию журнала транзакций) с использованием RESTORE WITH NORECOVERY. Рекомендуется отложить создание дополнительных резервных копий журналов транзакций текущих первичных баз данных до возобновления работы соответствующих вторичных баз данных.

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

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

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

Настройка поведения перехода на резервные ресурсы

Выполните ручное переключение

Настройка конфигурации кворума WSFC

  • Last updated on