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

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

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

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

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

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

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

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

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

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

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

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

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

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

Комплект для переключения при сбое

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

Обзор обработки отказа

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Существует набор автоматической отработки отказа. Этот набор состоит из первичной реплики и вторичной реплики ( целевого объекта автоматической отработки отказа), настроенных как для режима синхронной фиксации, так и для автоматической отработки отказа. ГИПЕРССЫЛКА "file:///C:\\Users\\marshow\\AppData\\Local\\Temp\\DxEditor\\DduePreview\\Default\\6fe88e12-4df1-4025-ba24-7579635ccecf\\HTM\\html\\29e0ac5d-eb58-4801-82b9-e278f08db920" Если первичная реплика настроена на РУЧНОЕ переключение, автоматическое переключение не может произойти, даже если для вторичной реплики настроено автоматическое переключение.

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

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

  Подсказка

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

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

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

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

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

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

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

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

   Замечание

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

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

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

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

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

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

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

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

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

3. При необходимости измените политику гибкого аварийного переключения группы высокой доступности, чтобы указать типы сбоев, которые могут привести к автоматическому переключению. Дополнительные сведения см., в статье Настройка гибкой политики отработки отказа для управления условиями автоматической отработки отказа (группы доступности AlwaysOn) гиперссылка "file:///C:\\Users\\marshow\\AppData\\Local\\Temp\\DxEditor\\DduePreview\\Default\\6a8d98a9-6e6a-40d1-9809-efa9013d7452\\HTM\\html\\1ed564b4-9835-4245-ae35-9ba67419a4ce" и Политика отработки отказа для экземпляров отказоустойчивого кластера.

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

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

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

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

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

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

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

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

• Настроен для режима синхронного подтверждения.

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

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

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

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

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

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

   Замечание

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

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

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

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

   Замечание

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

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

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

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

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

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

Как работает принудительный переход на резерв

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

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

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

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

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

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

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

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

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

Например, рассмотрим кластер WSFC, на котором размещена группа доступности на трёх узлах: узел A размещает первичную реплику, а узлы B и C — по одной вторичной реплике. Узел C отключается от кластера WSFC во время синхронизации локальной вторичной реплики. Поэтому узел A и узел B сохраняют работоспособный кворум, и группа доступности остается в рабочем состоянии. На узле A первичная реплика продолжает принимать обновления, а на узле B вторичная реплика продолжает синхронизироваться с первичной репликой. Вторичная реплика на узле C становится несинхронизированной и все чаще отступает от основной реплики. Однако, поскольку узел C отключен, реплика ошибочно остается в состоянии SYNCHRONIZED.

Если кворум потерян и затем принудительно устанавливается на узле A, состояние синхронизации группы доступности в кластере WSFC должно быть корректным, при этом вторичная реплика на узле C отображается как НЕСИНХРОНИЗИРОВАННАЯ. Однако если кворум принудительно применяется на узле C, синхронизация группы доступности будет неправильной. Состояние синхронизации в кластере было возвращено к состоянию после отключения узла C, при этом вторичная реплика на узле C неправильно показана как СИНХРОНИЗИРОВАНО. Так как запланированные отработки отказа вручную гарантируют безопасность данных, они запрещены для восстановления работы группы доступности после принудительного установления кворума.

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

Если в кластере 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 минут) с момента последнего выполнения задания, задание может вызвать оповещение.

Управление потенциальной потерей данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Изменение режима доступности реплики (SQL Server)

• Изменение режима отказоустойчивости реплики доступности (SQL Server)

• Настройка гибкой политики аварийного переключения для управления условиями автоматического переключения (AlwaysOn Availability Groups)

Чтобы выполнить ручное переключение

• Выполнение запланированного аварийного переключения вручную для группы доступности (SQL Server)

• Принудительное ручное переключение группы доступности (SQL Server)

• Используйте мастер переключения при отказе для группы доступности (SQL Server Management Studio)

• Управление логинами и заданиями для баз данных группы доступности (SQL Server)

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

• Настройка параметров NodeWeight для кворума кластера

• Просмотр параметров NodeWeight кворума кластера

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

Связанные материалы

• Руководство по решениям Microsoft SQL Server AlwaysOn для обеспечения высокой доступности и аварийного восстановления

• Блог группы SQL Server AlwaysOn: официальный блог группы SQL Server AlwaysOn

См. также

Общие сведения о группах доступности AlwaysOn (SQL Server)
Режимы доступности (группы доступности AlwaysOn)
Отказоустойчивая кластеризация Windows Server (WSFC) с использованием SQL Server
Транзакции между базами данных не поддерживаются для зеркального отображения базы данных или групп доступности AlwaysOn (SQL Server)
Политика отработки отказа для экземпляров отказоустойчивого кластера
Гибкая политика переключения при отказе для автоматического переключения группы доступности (SQL Server)