Бөлісу құралы:

Отработка отказа и режимы отработки отказа (группы доступности AlwaysOn)

Область применения: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 Если вы выдаете команду принудительного переключения на синхронизированной вторичной реплике, вторичная реплика будет вести себя так же, как при ручном переключении.

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

Внимание

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

Наборы отработки отказа

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

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

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

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

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

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

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

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

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

Автоматическая отработка отказа

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

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

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

Автоматический переход на другой ресурс происходит только при следующих условиях.

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

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

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

    Совет

    Группы доступности AlwaysOn отслеживают состояние обеих реплик из набора автоматического перехода на другой ресурс. В случае сбоя одной из реплик состоянию исправности группы доступности задается значение CRITICAL. Если вторичная реплика завершается ошибкой, автоматическое переключение невозможно, так как целевая реплика для автоматического переключения недоступна. В случае сбоя первичной реплики группа доступности выполнит переход на вторичную реплику. Цель автоматического перехода на другой ресурс будет отсутствовать, пока реплика, которая ранее была первичной, не вернется в режим «в сети». В любом случае для обеспечения доступности в случае последовательного сбоя (который маловероятен) рекомендуется в качестве цели автоматического перехода на другой ресурс задать другую вторичную реплику.

    Дополнительные сведения см. в разделах Использование политик AlwaysOn для определения работоспособности группы доступности (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. Также можно изменить политику гибкой отработки отказа в группе доступности и указать типы сбоев, которые вызывают автоматический переход на другой ресурс. Дополнительные сведения см. в разделе Настройка гибкой политики перехода на другой ресурс для контроля автоматического перехода на другой ресурс (группы доступности AlwaysOn) и Политика перехода на другой ресурс для экземпляров отказоустойчивого кластера.

Запланированный переход на другой ресурс вручную (без потери данных)

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

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

  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. Цель отработки отказа становится новой первичной репликой и немедленно доставляет свои копии баз данных клиентам. Когда бывшая первичная реплика становится доступной, она переходит к вторичной роли, а её базы данных становятся вторичными базами данных.

Все базы данных-получатели (включая бывшие базы данных-источники, когда они станут доступны) приостановлены. В зависимости от предыдущего состояния синхронизации данных в приостановленной базе данных-получателе, возможно, из нее не удастся извлечь отсутствующие зафиксированные данные этой базы данных-источника. Во вторичной реплике, настроенной на доступ только для чтения, можно выполнять запросы к базам данных-получателям для извлечения отсутствующих данных вручную. Затем можно выполнить инструкции 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 должно быть правильным: вторичная реплика на узле С должна быть показана как несинхронизированная (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. В этот момент рекомендуется попытаться выполнить резервное копирование заключительного фрагмента журнала удаленной базы данных. Затем можно обновить текущую базу данных-источник (бывшую базу данных-получатель), экспортировав данные, которые необходимо сохранить, из исходной базы данных-источника и импортировав их в текущую базу данных-источник. При этом рекомендуется как можно скорее создать полную резервную копию обновленной базы данных-источника.

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

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

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

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

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

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

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