Отработка отказа и режимы отработки отказа (группы доступности AlwaysOn)
Применимо к:
SQL Server
В контексте группы доступности роли первичной и вторичной реплик доступности обычно являются взаимозаменяемыми в ходе процесса, известного как переход на другой ресурс или отработка отказа. Существуют три формы перехода на другой ресурс: автоматический переход на другой ресурс (без потери данных), запланированный переход на другой ресурс вручную (без потери данных) и принудительный переход на другой ресурс вручную (с возможной потерей данных), обычно именуемый принудительным переходом на другой ресурс. При автоматическом и запланированном ручном переходе на другой ресурс все данные сохраняются. Группа доступности выполняет переход на другой ресурс на уровне реплики доступности. Это значит, что при отработке отказа группа доступности переходит на одну из ее вторичных реплик (на текущую цель отработки отказа).
Примечание
Если не настроен параметр Определение работоспособности на уровне базы данных, переход группы доступности на другой ресурс не вызывается проблемами на уровне баз данных, например обозначением базы данных как подозрительной в связи с потерей файла данных, удалением базы данных или повреждением журнала транзакций.
Во время отработки отказа цель принимает первичную роль, восстанавливает свои базы данных и переводит их в режим «в сети» в качестве новых баз данных-источников. Бывшая первичная реплика, если она доступна, переключается в роль вторичной, а ее базы данных становятся базами данных-получателями. Возможно многократное переключение ролей между двумя (и большим числом целей обработки отказа) либо в результате многочисленных ошибок, либо в целях администрирования.
Виды отработки отказа, которые поддерживает данная реплика доступности, задаются свойством режим отработки отказов . Возможные режимы отработки отказа определенной реплики доступности зависят от режима доступности реплики следующим образом:
Реплики синхронной фиксации поддерживают два параметра: автоматически или вручную. Параметр «автоматическая» поддерживает как автоматическую так ручную отработку отказа. Чтобы предотвратить потерю данных, для автоматической отработки отказа и запланированной отработки отказа необходимо, чтобы целью была вторичная реплика синхронной фиксации с работоспособным состоянием синхронизации (это значит, что каждая база данных-получатель в цели отработки отказа синхронизирована с соответствующей базой данных-источником). Если вторичная реплика не соответствует ни одному из этих условий, то она поддерживает только принудительную ручную отработку отказа. Обратите внимание, что принудительная отработка отказа также поддерживается репликами, роль которых находится в состоянии RESOLVING.
Реплики асинхронной фиксации поддерживают отработку отказа только вручную. Кроме того, поскольку они никогда не синхронизированы, они поддерживают только принудительную отработку отказа.
Примечание
После отработки отказа клиентским приложениям, которым требуется доступ к базам данных-источникам, будет необходимо подключиться к новой первичной реплике. Кроме того, если новая вторичная реплика настроена на доступ только на чтение, то клиентские приложения с доступом только на чтение могут подключиться к ней. Дополнительные сведения о подключении клиентов в группе доступности см. в разделе Прослушиватели групп доступности, возможность подключения клиентов и переход приложений на другой ресурс (SQL Server).
Подразделы данного раздела
Запланированный переход на другой ресурс вручную (без потери данных)
Принудительная отработка отказа (с возможной потерей данных)
Термины и определения
автоматический переход на другой ресурс
Отработка отказа, которая выполняется автоматически при потере первичной реплики. Автоматический переход на другой ресурс поддерживается только в ситуации, когда текущая первичная и одна из вторичных реплик настроены на режим перехода на другой ресурс AUTOMATIC, а вторичная реплика в данный момент синхронизована. Если для первичной или вторичной реплики задан режим отработки отказа MANUAL, автоматический переход на другой ресурс будет невозможен.
Запланированный переход на другой ресурс вручную (без потери данных)
Запланированный переход на другой ресурс вручную или переход на другой ресурс вручнуюобычно осуществляется администратором базы данных в административных целях. Запланированный переход на другой ресурс вручную поддерживается лишь в случае, когда первичная и вторичная реплики настроены на режим синхронной фиксации, а первичная и вторичная реплики в данный момент синхронизованы (находятся в состоянии SYNCHRONIZED). Если целевая вторичная реплика синхронизирована, то переход на другой ресурс вручную (без потери данных) возможен даже в случае сбоя первичной реплики, поскольку базы данных-получатели готовы к отработке отказа. Администратор базы данных вручную запускает переход на другой ресурс.
Принудительная отработка отказа (с возможной потерей данных)
Отработка отказа, которая может быть инициирована администратором базы данных, если ни одна вторичная реплика не синхронизирована (SYNCHRONIZED) с первичной репликой либо первичная реплика не запущена и ни одна вторичная реплика не готова к отработке отказа. Принудительная отработка отказа может привести к потере данных, ее рекомендуется использовать исключительно при аварийном восстановлении. Принудительная отработка отказа также известна как принудительная отработка отказа вручную, поскольку она может быть инициирована только вручную. Это единственная форма отработки отказа, которая поддерживается в режиме доступности асинхронной фиксации.
Задан автоматический переход на другой ресурс
В пределах заданной группы доступности это пара реплик доступности (включая текущую первичную реплику), которые настроены для режима синхронной фиксации с автоматическим переходом на другой ресурс (если они есть). задан автоматический переход на другой ресурс вступает в силу только в случае, если вторичная реплика в настоящее время находится в состоянии SYNCHRONIZED с первичной репликой.
Задана отработка отказа синхронной фиксации
В пределах заданной группы доступности это набор из двух или трех реплик доступности (включая текущую первичную реплику), в которых, при их наличии, настроен режим синхронной фиксации. задана отработка отказа синхронной фиксациивступает в силу, только если во вторичных репликах настроен режим перехода на другой ресурс вручную и как минимум одна вторичная реплика находится в состоянии SYNCHRONIZED с первичной репликой.
Задана полная отработка отказа
В данной группе доступности набор всех реплик доступности, состоянием работоспособности которых в данный момент является ONLINE, вне зависимости от режима доступности или режима отработки отказа. задана полная отработка отказавступает в силу только в случае, если вторичная реплика в настоящее время находится в состоянии SYNCHRONIZED с первичной репликой.
Общие сведения об отработке отказа
Следующая таблица содержит сводные данные о различных видах отработки отказа, поддерживаемых в различных режимах доступности и отработки отказа. Для каждой пары действующий режим доступности и отработки отказа определяется как пересечение режимов первичной реплики и режимов одной или нескольких вторичных реплик.
| Форма отработки отказа | Режим асинхронной фиксации | Режим синхронной фиксации с режимом перехода на другой ресурс вручную | Режим синхронной фиксации с режимом автоматического перехода на другой ресурс |
|---|---|---|---|
| автоматический переход на другой ресурс | Нет | Нет | Да |
| Запланированная отработка отказа вручную | Нет | Да | Да |
| принудительным переходом на другой ресурс | Да | Да | Да***** |
*****Если команда принудительного перехода на другой ресурс выполняется в синхронизированной вторичной реплике, то она функционирует так же, как в случае перехода на другой ресурс вручную.
Время, в течение которого база данных недоступна в ходе отработки отказа, зависит от типа отработки отказа и причины, вызвавшей его.
Важно!
Для обеспечения поддержки клиентских подключений после отработки отказа (за исключением автономных баз данных) имена входа и задания, определенные для всех бывших баз данных-источников, будет необходимо создать вручную для новой первичной базы данных-источника. Подробные сведения см. в статье Управление именами входа для заданий, использующих базы данных в группе доступности Always On.
Наборы отработки отказа
Формы отработки отказа, которые могут быть реализованы для данной группы доступности, можно называть наборами отработки отказа. Набор отработки отказа состоит из первичной и вторичной реплик, поддерживающих данную форму отработки отказа.
Группа автоматического перехода на другой ресурс (опция): В пределах заданной группы доступности это пара реплик доступности (включая текущую первичную реплику), которые настроены для режима автоматического перехода на другой ресурс с синхронной фиксацией (при наличии). Набор автоматического перехода на другой ресурс учитывается только в случае, если вторичная реплика в настоящее время находится в состоянии SYNCHRONIZED с первичной репликой.
Группа перехода на другой ресурс синхронной фиксацией (опция): В пределах заданной группы доступности это группа из двух или трех реплик доступности (включая текущую первичную реплику), которые настроены для режима с синхронной фиксацией (при наличии). Набор отработки отказа с синхронной фиксаций используется, только если во вторичных репликах настроен режим отработки отказа вручную и как минимум одна вторичная реплика находится в состоянии SYNCHRONIZED с первичной репликой.
полная группа перехода на другой ресурс : В данной группе доступности это группа всех реплик доступности, текущее рабочее состояние которых В СЕТИ, вне зависимости от режима доступности или режима переходы на другой ресурс. Полный набор отработки отказа используется только в случае, если вторичная реплика в настоящее время находится в состоянии SYNCHRONIZED с первичной репликой.
Если реплика доступности настраивается на синхронную фиксацию с автоматическим переходом на другой ресурс, реплика доступности входит в состав задан автоматический переход на другой ресурс. Однако функционирование набора зависит от текущей первичной реплики. То, какие виды перехода на другой ресурс являются доступными в определенный момент, зависит от наборов отработки отказа, действующих на данный момент.
Например, рассмотрим группу доступности, которая имеет четыре реплики доступности:
| Реплика | Настройки режима доступности и режима отработки отказа |
|---|---|
| Объект | Синхронная фиксация с автоматической отработкой отказа |
| B | Синхронная фиксация с автоматической отработкой отказа |
| C | Синхронная фиксация только с плановой отработкой отказа вручную |
| D | Асинхронная фиксация (только с режимом принудительной отработки отказа) |
Поведение отработки отказа каждой из вторичных реплик зависит от того, какая реплика доступности назначена в данный момент первичной. Обычно для данной вторичной реплики отработка отказа— это худший возможный вариант при текущей первичной реплике. На следующем рисунке показано, как способ отработки отказа на вторичных репликах зависит от текущей первичной реплики и от того, настроена она на режим асинхронной фиксации (только с принудительным переходом на другой ресурс) или режим синхронной фиксации (с автоматическим переходом на другой ресурс или без него).
Автоматическая отработка отказа
Автоматический переход на другой ресурс вызывает переключение подходящей вторичной реплики в первичную роль после того, как первичная реплика становится недоступной. Автоматический переход на другой ресурс наиболее полезен в случае, если узел WSFC, на котором размещена первичная реплика, является локальным для узла, на котором размещена вторичная реплика. Так происходит потому, что синхронизация данных лучше всего работает при малой задержке сообщений между компьютерами, а клиентские соединения могут оставаться локальными.
В этом разделе.
Необходимые условия для автоматического перехода на другой ресурс
Автоматический переход на другой ресурс происходит только при следующих условиях.
Наличие набора автоматического перехода на другой ресурс. Этот набор состоит из первичной реплики и вторичной реплики ( цель автоматического перехода на другой ресурс), причем на обеих настроен режим синхронной фиксации и обе реплики имеют режим перехода на другой ресурс AUTOMATIC. Если для первичной реплики задан режим перехода на другой ресурс MANUAL, автоматический переход на другой ресурс не может быть выполнен, даже если на вторичной реплике задан режим отработки перехода на другой ресурс AUTOMATIC.
Дополнительные сведения см. в разделе Режимы доступности (группы доступности Always On).
Цель автоматического перехода на другой ресурс имеет нормальное состояние синхронизации (то есть все базы данных-получатели на цели отработки отказа синхронизированы с соответствующей базой данных-источником).
Совет
Группы доступности AlwaysOn отслеживают состояние обеих реплик из набора автоматического перехода на другой ресурс. В случае сбоя одной из реплик состоянию исправности группы доступности задается значение CRITICAL. В случае сбоя вторичной реплики выполнение автоматической отработки отказа невозможно, поскольку цель автоматического перехода на другой ресурс недоступна. В случае сбоя первичной реплики группа доступности выполнит переход на вторичную реплику. Цель автоматического перехода на другой ресурс будет отсутствовать, пока реплика, которая ранее была первичной, не вернется в режим «в сети». В любом случае для обеспечения доступности в случае последовательного сбоя (который маловероятен) рекомендуется в качестве цели автоматического перехода на другой ресурс задать другую вторичную реплику.
Дополнительные сведения см. в разделах Использование политик AlwaysOn для определения работоспособности группы доступности (SQL Server) и Изменение режима перехода на другой ресурс реплики доступности (SQL Server).
Кластер WSFC имеет кворум. Дополнительные сведения см. в разделе Режимы кворума и участвующая в голосовании конфигурация WSFC (SQL Server).
Первичная реплика стала недоступной и уровни условий перехода на другой ресурс, заданные гибкой политикой отработки отказа, были удовлетворены. Дополнительные сведения об уровнях условий перехода на другой ресурс см. в разделе Гибкая политика перехода на другой ресурс для автоматического перехода на другой ресурс группы доступности (SQL Server).
Принцип работы автоматической отработки отказа
Автоматический переход на другой ресурс включает в себя следующие действия.
Если экземпляр сервера, на котором размещена текущая первичная реплика, все еще работает, он изменяет состояние баз данных-источников на DISCONNECTED и отсоединяет всех клиентов.
Если в очередях восстановления целевой вторичной реплики существуют ожидающие записи журнала, вторичная реплика применит оставшиеся записи журнала, чтобы завершить накат баз данных-получателей.
Примечание
Длительность применения журнала к заданной базе данных зависит от скорости системы, текущего уровня загрузки и количества записей журнала в очереди восстановления.
Бывшая вторичная реплика переключается на первичную роль. Ее базы данных становятся базами данных-источниками. Новая первичная реплика выполнит откат всех незафиксированных транзакций (этап отката восстановления) как можно скорее. Блокировки изолируют эти незафиксированные транзакции, позволяя выполнить откат в фоновом режиме, давая пользователям возможность работать с базой данных. Этот процесс не выполняет откат каких-либо зафиксированных транзакций.
До момента подключения база данных-получатель временно помечается как NOT_SYNCHRONIZED. Перед началом восстановления с откатом базы данных-получатели могут подключаться к новым базам данных-источникам и быстро переходить в состояние SYNCHRONIZED. Как правило, лучшим вариантом является третья реплика синхронной фиксации, которая остается во вторичной роли после отработки отказа.
Позднее, когда экземпляр сервера, на котором размещена бывшая первичная реплика, перезагрузится, он распознает, что первичная роль теперь принадлежит другой реплике доступности. Бывшая первичная реплика перейдет в роль вторичной, а ее базы данных станут базами данных-получателями. Новая вторичная реплика как можно быстрее установит соединение с текущей первичной репликой и обновит свои базы данных до состояния текущих баз данных-источников. Как только новая вторичная реплика выполнит повторную синхронизацию своих баз данных, отработка отказа снова станет возможной, но уже в обратном направлении.
Настройка автоматического перехода на другой ресурс
Реплика доступности в любой момент может быть настроена на поддержку автоматического перехода на другой ресурс.
To configure automatic failover
Убедитесь, что вторичная реплика настроена на использование режима доступности синхронной фиксации. Дополнительные сведения см. в разделе Изменение режима доступности для реплики доступности (SQL Server).
Задайте автоматический режим перехода на другой ресурс. Дополнительные сведения см. в разделе Изменение режима перехода на другой ресурс для реплики доступности (SQL Server).
Также можно изменить политику гибкой отработки отказа в группе доступности и указать типы сбоев, которые вызывают автоматический переход на другой ресурс. Дополнительные сведения см. в разделе Настройка гибкой политики перехода на другой ресурс для контроля автоматического перехода на другой ресурс (группы доступности AlwaysOn) и Политика перехода на другой ресурс для экземпляров отказоустойчивого кластера.
Запланированный переход на другой ресурс вручную (без потери данных)
При использовании перехода на другой ресурс вручную, вторичная реплика принимает первичную роль после того, как администратор базы данных отдает команду перехода на другой ресурс вручную для экземпляра сервера, на котором размещена целевая вторичная реплика. Для поддержки перехода на другой ресурс вручную во вторичной реплике и текущей первичной реплике должен быть настроен режим синхронной фиксации. Все базы данных-получатели на реплике доступности должны быть соединены с группой доступности и синхронизированы с ее соответствующими базами данных-источниками (то есть вторичная реплика должна быть синхронизирована). Это гарантирует, что все транзакции, зафиксированные в бывшей базе данных-источнике, также будут зафиксированы в новой базе данных-источнике. По этой причине новые базы данных-источники будут идентичны старым базам данных-источникам.
На следующем рисунке показаны этапы запланированной отработки отказа.
Перед отработкой отказа первичная реплика размещается на экземпляре сервера на узле
Node01.Администратор базы данных запускает запланированный переход на другой ресурс. Целью является реплика доступности, размещаемая в экземпляре сервера в узле
Node02.Цель перехода на другой ресурс (в узле
Node02) становится новой первичной репликой. Поскольку это запланированный переход на другой ресурс, бывшая первичная реплика принимает вторичную роль и немедленно переводит свои базы данных в режим «в сети» в качестве баз данных-получателей.
В этом разделе.
Условия для отработки отказа вручную
Для обеспечения поддержки перехода на другой ресурс вручную текущая первичная реплика должна быть настроена на режим синхронной фиксации. Кроме того, вторичная реплика должна удовлетворять следующим условиям.
Она должна быть настроена на работу в режиме синхронной фиксации.
В данный момент она должна быть синхронизирована с первичной репликой.
Чтобы вручную перевести группу доступности на другой ресурс, нужно подключиться ко вторичной реплике, которую планируется сделать первичной.
Как работает запланированный переход на другой ресурс вручную
Запланированный переход на другой ресурс вручную, который должен инициироваться на целевой вторичной реплике, вызывает следующую последовательность действий.
Чтобы не допустить выполнения новых пользовательских транзакций в исходных базах данных-источниках, кластер WSFC отправляет запрос на перевод первичной реплики в режим «вне сети».
Если в очереди восстановления любой базы данных-получателя присутствуют какие либо журналы, вторичная реплика закончит накат для этой базы данных-получателя. Длительность выполнения зависит от скорости системы, текущей рабочей нагрузки и количества записей журнала в очереди восстановления. Для определения текущего размера очереди восстановления используйте счетчик производительности Recovery Queue . Дополнительные сведения см. в статье SQL Server, реплика базы данных.
Примечание
Время отработки отказа можно регулировать путем ограничения размера очереди восстановления. Однако это может привести к замедлению работы первичной реплики, чтобы дать возможность вторичной реплике не отставать.
Вторичная реплика становится новой первичной репликой, а бывшая первичная реплика становится вторичной репликой.
Новая первичная реплика выполняет откат всех незафиксированных транзакций и переводит свои базы данных в режим «в сети» в качестве баз данных-источников. Все базы данных-получатели кратковременно помечаются состоянием NOT SYNCHRONIZED до момента их подключения и повторной синхронизации с новыми базами данных-источниками. Этот процесс не выполняет откат каких-либо зафиксированных транзакций.
Когда бывшая первичная реплика перейдет в режим «в сети», она примет вторичную роль, а бывшая база данных-источник станет базой данных-получателем. Новая вторичная реплика быстро выполнит повторную синхронизацию новых баз данных-получателей с соответствующими базами данных-источниками.
Примечание
Как только новая вторичная реплика выполнит повторную синхронизацию баз данных, отработка отказа снова станет возможной, но уже в обратном направлении.
После отработки отказа клиенты должны повторно подключиться к текущей базе данных-источнику. Дополнительные сведения см. в разделе Прослушиватели групп доступности, возможность подключения клиентов и переход приложений на другой ресурс (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 последней фиксации и времени последней фиксации для каждой базы данных-источника и ее баз данных-получателей следующим образом.
Подключитесь к первичной реплике.
Выполните запрос к столбцам типа last_commit_lsn (номер LSN последней зафиксированной транзакции) и last_commit_time (время последней фиксации) динамического административного представления sys.dm_hadr_database_replica_states .
Сравните значения, возвращаемые для каждой базы данных-источника и каждой из ее баз данных-получателей. Различие между их номерами LSN последней фиксации указывает величину отставания.
Можно инициировать предупреждение, если величина отставания для базы данных или набора баз данных превышает заданное максимальное отставание за определенный период времени. Например, запрос может быть инициирован заданием, которое выполняется каждую минуту на каждой базе данных-источнике. Если различие между last_commit_time базы данных-источника и любой из ее баз данных-получателей превышает целевую точку восстановления (RPO) (например, 5 минут) с момента последнего выполнения задания, задание может инициировать предупреждение.
Важно!
Если кластер WSFC не имеет кворума или кворум был создан принудительно, last_commit_lsn и last_commit_time равны NULL. Дополнительные сведения о предотвращении потери данных после принудительного создания кворума, см. в подразделе "Потенциальные методы предотвращения потери данных после принудительного создания кворума" в разделе Выполнение принудительного перехода на другой ресурс вручную для группы доступности (SQL Server).
Управление возможной потерей данных
После принудительной отработки отказа все базы данных-получатели приостанавливаются. Это относится к бывшим базам данных-источникам, для которых бывшая первичная реплика вновь переходит в режим «в сети» и обнаруживает, что отныне является вторичной репликой. Необходимо вручную возобновить работу каждой приостановленной базы данных во вторичной реплике.
Как только бывшая первичная реплика становится доступной (при условии, что базы данных остались неповрежденными), можно попытаться избежать потенциальной потери данных. Доступные подходы управления возможной потерей данных зависят от того, была ли исходная первичная реплика соединена с новой первичной репликой. Если исходная первичная реплика может обратиться к новому первичному экземпляру, восстановление соединения произойдет автоматически и прозрачно.
Исходная первичная реплика была повторно присоединена
После сбоя бывшая первичная реплика обычно быстро восстанавливает соединение со своим партнером. После повторного подключения, исходная первичная реплика становится вторичной репликой. Ее базы данных становятся базами данных-получателями и переходят в состояние SUSPENDED. Откат новых баз данных-получателей будет нельзя выполнить до тех пор, пока они не будут возобновлены.
Однако приостановленные базы данных являются недоступными, поэтому их нельзя исследовать и определить, какие данные будут потеряны при возобновлении данной базы данных. Таким образом, решение о возобновлении или удалении базы данных-получателя зависит от того, допустима ли потеря данных следующим образом.
Если потеря данных недопустима, следует удалить базы данных из группы доступности, чтобы сохранить их.
Теперь администратор базы данных сможет восстановить бывшие базы данных-источники и попытаться восстановить данные, которые были бы потеряны. Однако когда бывшая база данных-источник станет доступной, она будет отличаться от текущей базы данных-источника, поэтому администратору баз данных придется сделать либо удаленную, либо текущую базу данных-источник недоступной клиентам, чтобы избежать их дальнейшего расхождения и проблем, связанных с переходом на другой ресурс на стороне клиентов.
Если потеря данных будет приемлема для ваших бизнес-целей, можно возобновить базы данных-получатели.
При возобновлении базы данных-получателя, первым шагом ее синхронизации является откат. Если очередь отправки содержала какие-либо записи журнала в момент выхода из строя сервера, соответствующие транзакции будут потеряны, даже если они были зафиксированы.
Исходная первичная реплика не была повторно присоединена
Если вы можете временно предотвратить повторное подключение исходной первичной реплики по сети к новой первичной реплике, у вас будет возможность изучить исходные базы данных-источники и оценить, какие данные будут потеряны при их возобновлении.
Если потенциальная потеря данных допустима
Разрешите исходной первичной реплике повторно подключиться к новой первичной реплике. Повторное подключение приводит к приостановке новых баз данных-получателей. Чтобы начать синхронизацию данных в базе данных, просто возобновите ее. Новая вторичная реплика удалит исходную вилку восстановления для этой базы данных, потеряв все транзакции, которые не были переданы или получены бывшей вторичной репликой.
Потеря данных недопустима
Если исходная база данных-источник содержит важные данные, которые будут потеряны при возобновлении приостановленной базы данных, их можно сохранить в исходной базе данных-источнике, удалив ее из группы доступности. При этом база данных перейдет в состояние RESTORING. В этот момент рекомендуется попытаться выполнить резервное копирование заключительного фрагмента журнала удаленной базы данных. Затем можно обновить текущую базу данных-источник (бывшую базу данных-получатель), экспортировав данные, которые необходимо сохранить, из исходной базы данных-источника и импортировав их в текущую базу данных-источник. При этом рекомендуется как можно скорее создать полную резервную копию обновленной базы данных-источника.
Затем на экземпляре сервера, на котором размещена новая вторичная реплика, можно удалить приостановленную базу данных-получатель и создать новую базу данных-получатель, восстановив эту резервную копию (и по крайней мере одну из последующих резервных копий журнала) с помощью инструкции RESTORE WITH NORECOVERY. Рекомендуется отложить создание дополнительных резервных копий журнала текущих баз данных-источников до возобновления соответствующих баз данных-получателей.
Предупреждение
Если хотя бы одна из баз данных-получателей приостановлена, усечение журнала транзакций в базе данных-источнике откладывается. Кроме того, во время приостановки любой локальной базы данных невозможен переход состояния вторичной реплики с синхронной фиксацией в HEALTHY.
Связанные задачи
Настройка режима перехода на другой ресурс
Смена режима доступности для реплики доступности (SQL Server)
Изменение режима отработки отказа для реплики доступности (SQL Server)
Выполнение перехода на другой ресурс вручную
Выполнение запланированного перехода на другой ресурс вручную для группы доступности (SQL Server)
Выполнение принудительного перехода на другой ресурс вручную для группы доступности (SQL Server)
Использование мастера отработки отказа группы доступности (Среда SQL Server Management Studio)
Управление именами входа и заданиями для баз данных группы доступности (SQL Server)
Настройка конфигурации кворума WSFC
См. также
См. также:
Обзор групп доступности AlwaysOn SQL Server)
Режимы доступности (группы доступности AlwaysOn)
Отказоустойчивая кластеризация Windows Server (WSFC) с SQL Server
Транзакции между базами данных и распределенные транзакции для групп доступности AlwaysOn и зеркального отображения базы данных (SQL Server)
Failover Policy for Failover Cluster Instances
Гибкая политика отработки отказа для автоматического перехода на другой ресурс группы доступности (SQL Server)
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по