Аварийное восстановление WSFC через принудительный кворум (SQL Server)

  • Статья

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

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

Перед началом работы

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

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

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

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

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

Безопасность

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

Аварийное восстановление WSFC с помощью процедуры принудительного кворума

Помните, что сбой кворума приведет к переходу в режим «вне сети» всех служб, поддерживающих работу в кластере, экземпляров SQL Server, Группы доступности AlwaysOnи групп доступности в кластере WSFC, поскольку настроенный таким образом кластер не сможет гарантировать отказоустойчивость на уровне узлов. Сбой кворума означает, что исправные голосующие узлы в кластере WSFC более не удовлетворяют модели кворума. Некоторые узлы, возможно, полностью вышли из строя, на других могла просто отключиться служба WSFC, а в остальном они работают исправно, за исключением потери возможности взаимодействовать с кворумом.

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

Можно использовать процедуру принудительного кворума на узле кластера WSFC, чтобы переопределить управляющие параметры безопасности, которые привели к переходу кластера в режим «вне сети». Она предписывает кластеру приостановить проверки голосования кворума, и позволяет привести ресурсы кластера WSFC и SQL Server обратно в режим «в сети» на любом из узлов кластера.

Этот тип процесса аварийного восстановления после аварий должен включать следующие этапы.

Для восстановления после сбоя кворума:

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

    Совет

    На главном экземпляре SQL Serverможно получить сведения о работоспособности групп доступности, которые имеют реплику доступности на экземпляре локального сервера, выполнив запрос к динамическому административному представлению (DMV) sys.dm_hadr_availability_group_states .

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

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

    Дополнительные сведения см. в статье Принудительный запуск кластера WSFC без кворума

    Примечание

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

  3. Запустите службу WSFC обычным образом на каждом узле, исправном во всех остальных отношениях, по одному за раз. Не нужно указывать параметр принудительного кворума при запуске службы кластеров на других узлах.

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

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

    Убедитесь, что каждый узел, который вы запускаете, может общаться с другими узлами, недавно перешедшими в состояние «в сети». Рекомендуется отключить службу WSFC на других узлах. В противном случае вы рискуете создать несколько наборов узлов кворума. Этот сценарий может привести к дроблению. Если на шаге 1 получены точные результаты, этого не должно произойти.

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

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

    Совет

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

  5. При необходимости восстановите реплики баз данных групп доступности. Базы данных, не относящиеся к группам доступности, должны сами восстановиться и вернуться в состояние «в сети» в процессе обычного запуска SQL Server.

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

Примечание

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

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

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

    Примечание

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

    "Свойству RegisterAllProvidersIP для сетевого имени "Name:<сетевое_имя>" присвоено значение 1. В текущей конфигурации кластера для этого свойства должно быть задано значение 0".

    Не обращайте внимания на это сообщение.

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

  3. Анализ RPO/RTO. Следует проанализировать системные журналы SQL Server, метки времени баз данных, журналы событий Windows, чтобы выявить главную причину аварии и задокументировать реальные значения точки восстановления и времени восстановления.

Связанные задачи

См. также

См. также:

Отказоустойчивая кластеризация Windows Server (WSFC) с SQL Server