Отработка отказа и режимы отработки отказа (группы доступности AlwaysOn)Failover and Failover Modes (Always On Availability Groups)

ОБЛАСТЬ ПРИМЕНЕНИЯ: даSQL Server нетБаза данных SQL AzureнетХранилище данных SQL AzureнетParallel Data WarehouseAPPLIES TO: yesSQL Server noAzure SQL Database noAzure SQL Data Warehouse noParallel Data Warehouse

В контексте группы доступности роли первичной и вторичной реплик доступности обычно являются взаимозаменяемыми в ходе процесса, известного как переход на другой ресурс или отработка отказа.Within the context of an availability group, the primary role and secondary role of availability replicas are typically interchangeable in a process known as failover. Существуют три формы перехода на другой ресурс: автоматический переход на другой ресурс (без потери данных), запланированный переход на другой ресурс вручную (без потери данных) и принудительный переход на другой ресурс вручную (с возможной потерей данных), обычно именуемый принудительным переходом на другой ресурс.Three forms of failover exist: automatic failover (without data loss), planned manual failover (without data loss), and forced manual failover (with possible data loss), typically called forced failover. При автоматическом и запланированном ручном переходе на другой ресурс все данные сохраняются.Automatic and planned manual failover preserve all your data. Группа доступности выполняет переход на другой ресурс на уровне реплики доступности.An availability group fails over at the availability-replica level. Это значит, что при отработке отказа группа доступности переходит на одну из ее вторичных реплик (на текущую цель отработки отказа).That is, an availability group fails over to one of its secondary replicas (the current failover target).

Примечание

Переход группы доступности на другой ресурс не вызывается проблемами на уровне баз данных, например обозначением базы данных как подозрительной в связи с потерей файла данных или повреждением журнала транзакций.Issues at the database level, such as a database becoming suspect due to the loss of a data file, deletion of a database, or corruption of a transaction log, do not cause an availability group to failover.

Во время отработки отказа цель принимает первичную роль, восстанавливает свои базы данных и переводит их в режим «в сети» в качестве новых баз данных-источников.During the failover, the failover target takes over the primary role, recovers its databases, and brings them online as the new primary databases. Бывшая первичная реплика, если она доступна, переключается в роль вторичной, а ее базы данных становятся базами данных-получателями.The former primary replica, when available, switches to the secondary role, and its databases become secondary databases. Возможно многократное переключение ролей между двумя (и большим числом целей обработки отказа) либо в результате многочисленных ошибок, либо в целях администрирования.Potentially, these roles can switch back and forth (or to a different failover target) in response to multiple failures or for administrative purposes.

Виды отработки отказа, которые поддерживает данная реплика доступности, задаются свойством режим отработки отказов .The form(s) of failover that a given availability replica supports is specified by the failover mode property. Возможные режимы отработки отказа определенной реплики доступности зависят от режима доступности реплики следующим образом:For a given availability replica, the possible failover modes depends on the availability mode of the replica, as follows:

  • Реплики синхронной фиксации поддерживают два параметра: автоматически или вручную.Synchronous-commit replicas support two settings-automatic or manual. Параметр «автоматическая» поддерживает как автоматическую так ручную отработку отказа.The "automatic" setting supports both automatic failover and manual failover. Чтобы предотвратить потерю данных, для автоматической отработки отказа и запланированной отработки отказа необходимо, чтобы целью была вторичная реплика синхронной фиксации с работоспособным состоянием синхронизации (это значит, что каждая база данных-получатель в цели отработки отказа синхронизирована с соответствующей базой данных-источником).To prevent data loss, automatic failover and planned failover require that the failover target be a synchronous-commit secondary replica with a healthy synchronization state (this indicates that every secondary database on the failover target is synchronized with its corresponding primary database). Если вторичная реплика не соответствует ни одному из этих условий, то она поддерживает только принудительную ручную отработку отказа.Whenever a secondary replica does not meet both of these conditions, it supports only forced failover. Обратите внимание, что принудительная отработка отказа также поддерживается репликами, роль которых находится в состоянии RESOLVING.Note that forced failover is also supported a replicas whose role is in the RESOLVING state.

  • Реплики асинхронной фиксации поддерживают отработку отказа только вручную.Asynchronous-commit replicas support only the manual failover mode. Кроме того, поскольку они никогда не синхронизированы, они поддерживают только принудительную отработку отказа.Moreover, because they are never synchronized, they support only forced failover.

Примечание

После отработки отказа клиентским приложениям, которым требуется доступ к базам данных-источникам, будет необходимо подключиться к новой первичной реплике.After a failover, client applications that need to access the primary databases must connect to the new primary replica. Кроме того, если новая вторичная реплика настроена на доступ только на чтение, то клиентские приложения с доступом только на чтение могут подключиться к ней.Also, if the new secondary replica is configured to allow read-only access, read-only client applications can connect to it. Дополнительные сведения о подключении клиентов в группе доступности см. в статье Прослушиватели групп доступности, возможность подключения клиентов и отработка отказа приложений (SQL Server).For information about how clients connect to an availability group, see Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server).

Подразделы данного разделаSections in This Topic:

Термины и определенияTerms and Definitions

автоматический переход на другой ресурсAutomatic failover
Отработка отказа, которая выполняется автоматически при потере первичной реплики.A failover that occurs automatically on the loss of the primary replica. Автоматический переход на другой ресурс поддерживается только в ситуации, когда текущая первичная и одна из вторичных реплик настроены на режим перехода на другой ресурс AUTOMATIC, а вторичная реплика в данный момент синхронизована.Automatic failover is supported only when the current primary and one secondary replica are both configured with failover mode set to AUTOMATIC and the secondary replica currently synchronized. Если для первичной или вторичной реплики задан режим отработки отказа MANUAL, автоматический переход на другой ресурс будет невозможен.If the failover mode of either the primary or secondary replica is MANUAL, automatic failover cannot occur.

Запланированный переход на другой ресурс вручную (без потери данных)Planned manual failover (without data loss)
Запланированный переход на другой ресурс вручную или переход на другой ресурс вручнуюобычно осуществляется администратором базы данных в административных целях.Planned manual failover, or manual failover, is a failover that is initiated by a database administrator, typically, for administrative purposes. Запланированный переход на другой ресурс вручную поддерживается лишь в случае, когда первичная и вторичная реплики настроены на режим синхронной фиксации, а вторичная реплика в данный момент синхронизована (находится в состоянии SYNCHRONIZED).A planned manual failover is supported only if both the primary replica and secondary replica are configured for synchronous-commit mode and the secondary replica is currently synchronized (in the SYNCHRONIZED state). Если целевая вторичная реплика синхронизирована, то переход на другой ресурс вручную (без потери данных) возможен даже в случае сбоя первичной реплики, поскольку базы данных-получатели готовы к отработке отказа.When the target secondary replica is synchronized, manual failover (without data loss) is possible even if the primary replica has crashed because the secondary databases are ready for failover. Администратор базы данных вручную запускает переход на другой ресурс.A database administrator manually initiates a manual failover.

Принудительная отработка отказа (с возможной потерей данных)Forced failover (with possible data loss)
Отработка отказа, которая может быть инициирована администратором базы данных, если ни одна вторичная реплика не синхронизирована (SYNCHRONIZED) с первичной репликой либо первичная реплика не запущена и ни одна вторичная реплика не готова к отработке отказа.A failover that can be initiated by a database administrator when no secondary replica is SYNCHRONIZED with the primary replica or the primary replica is not running and no secondary replica is failover ready. Принудительная отработка отказа может привести к потере данных, ее рекомендуется использовать исключительно при аварийном восстановлении.Forced failover risks possible data loss and is recommended strictly for disaster recovery. Принудительная отработка отказа также известна как принудительная отработка отказа вручную, поскольку она может быть инициирована только вручную.Forced failover is also known as forced manual failover because it can only be initiated manually. Это единственная форма отработки отказа, которая поддерживается в режиме доступности асинхронной фиксации.This is the only form of failover supported by in asynchronous-commit availability mode.

Задан автоматический переход на другой ресурсAutomatic failover set

В пределах заданной группы доступности это пара реплик доступности (включая текущую первичную реплику), которые настроены для режима синхронной фиксации с автоматическим переходом на другой ресурс (если они есть).Within a given availability group, a pair of availability replicas (including the current primary replica) that are configured for synchronous-commit mode with automatic failover, if any. задан автоматический переход на другой ресурсautomatic failover set вступает в силу только в случае, если вторичная реплика в настоящее время находится в состоянии SYNCHRONIZED с первичной репликой.An задан автоматический переход на другой ресурсautomatic failover settakes effect only if the secondary replica is currently SYNCHRONIZED with the primary replica.

Задана отработка отказа синхронной фиксацииSynchronous-commit failover set

В пределах заданной группы доступности это набор из двух или трех реплик доступности (включая текущую первичную реплику), в которых, при их наличии, настроен режим синхронной фиксации.Within a given availability group, a set of two or three availability replicas (including the current primary replica) that are configured for synchronous-commit mode, if any. задана отработка отказа синхронной фиксацииsynchronous-commit failover setвступает в силу, только если во вторичных репликах настроен режим перехода на другой ресурс вручную и как минимум одна вторичная реплика находится в состоянии SYNCHRONIZED с первичной репликой.A задана отработка отказа синхронной фиксацииsynchronous-commit failover settakes effect only if the secondary replicas are configured for manual failover mode and at least one secondary replica is currently SYNCHRONIZED with the primary replica.

Задана полная отработка отказаEntire failover set

В данной группе доступности набор всех реплик доступности, состоянием работоспособности которых в данный момент является ONLINE, вне зависимости от режима доступности или режима отработки отказа.Within a given availability group, the set of all availability replicas whose operational state is currently ONLINE, regardless of availability mode and of failover mode. задана полная отработка отказаentire failover setвступает в силу только в случае, если вторичная реплика в настоящее время находится в состоянии SYNCHRONIZED с первичной репликой.The задана полная отработка отказаentire failover setbecomes relevant when no secondary replica is currently SYNCHRONIZED with the primary replica.

Общие сведения об отработке отказаOverview of Failover

Следующая таблица содержит сводные данные о различных видах отработки отказа, поддерживаемых в различных режимах доступности и отработки отказа.The following table summarizes which forms of failover are supported under different availability and failover modes. Для каждой пары действующий режим доступности и отработки отказа определяется как пересечение режимов первичной реплики и режимов одной или нескольких вторичных реплик.For each pairing, the effective availability mode and failover mode is determined by the intersection of the modes of the primary replica plus the modes of one or more secondary replicas.

Режим асинхронной фиксацииAsynchronous-commit mode Режим синхронной фиксации с режимом перехода на другой ресурс вручнуюSynchronous-commit mode with manual-failover mode Режим синхронной фиксации с режимом автоматического перехода на другой ресурсSynchronous-commit mode with automatic-failover mode
автоматический переход на другой ресурсAutomatic failover нетNo нетNo ДаYes
Запланированная отработка отказа вручнуюPlanned manual failover нетNo ДаYes ДаYes
принудительным переходом на другой ресурсForced failover ДаYes ДаYes Да *Yes *

* Если команда принудительного перехода на другой ресурс выполняется в синхронизированной вторичной реплике, то она работает так же, как в случае перехода на другой ресурс вручную.* If you issue a forced failover command on a synchronized secondary replica, the secondary replica behaves the same as for a manual failover.

Время, в течение которого база данных недоступна в ходе отработки отказа, зависит от типа отработки отказа и причины, вызвавшей его.The amount of time that the database is unavailable during a failover depends on the type of failover and its cause.

Важно!

Для обеспечения поддержки клиентских подключений после отработки отказа (за исключением автономных баз данных) имена входа и задания, определенные для всех бывших баз данных-источников, будет необходимо создать вручную для новой первичной базы данных-источника.To support client connections after failover, except for contained databases, logins and jobs defined on any of the former primary databases must be manually recreated on the new primary database. Дополнительные сведения см. в разделе Управление именами входа и заданиями для баз данных группы доступности (SQL Server).For more information, see Management of Logins and Jobs for the Databases of an Availability Group (SQL Server).

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

Формы отработки отказа, которые могут быть реализованы для данной группы доступности, можно называть наборами отработки отказа.The forms of failover that are possible for a given availability group can be understood in terms of failover sets. Набор отработки отказа состоит из первичной и вторичной реплик, поддерживающих данную форму отработки отказа.A failover set consists of the primary replica and secondary replicas that support a given form of failover, as follows:

  • Задан автоматический переход на другой ресурсAutomatic failover set (необязательно): В пределах заданной группы доступности это пара реплик доступности (включая текущую первичную реплику), которые настроены для режима синхронной фиксации с автоматическим переходом на другой ресурс (если они есть).Задан автоматический переход на другой ресурсAutomatic failover set (optional): Within a given availability group, a pair of availability replicas (including the current primary replica) that are configured for synchronous-commit mode with automatic failover, if any. Набор автоматического перехода на другой ресурс учитывается только в случае, если вторичная реплика в настоящее время находится в состоянии SYNCHRONIZED с первичной репликой.An automatic failover set takes effect only if the secondary replica is currently SYNCHRONIZED with the primary replica.

  • Задана отработка отказа синхронной фиксацииSynchronous-commit failover set (необязательно): В пределах заданной группы доступности это набор из двух или трех реплик доступности (включая текущую первичную реплику), в которых, при их наличии, настроен режим синхронной фиксации.Задана отработка отказа синхронной фиксацииSynchronous-commit failover set (optional): Within a given availability group, a set of two or three availability replicas (including the current primary replica) that are configured for synchronous-commit mode, if any. Набор отработки отказа с синхронной фиксаций используется, только если во вторичных репликах настроен режим отработки отказа вручную и как минимум одна вторичная реплика находится в состоянии SYNCHRONIZED с первичной репликой.A synchronous-commit failover set takes effect only if the secondary replicas are configured for manual failover mode and at least one secondary replica is currently SYNCHRONIZED with the primary replica.

  • Задана полная отработка отказаEntire failover set : В данной группе доступности набор всех реплик доступности, состоянием работоспособности которых в данный момент является ONLINE, вне зависимости от режима доступности или режима отработки отказа.Задана полная отработка отказаEntire failover set : Within a given availability group, the set of all availability replicas whose operational state is currently ONLINE, regardless of availability mode and of failover mode. Полный набор отработки отказа используется только в случае, если вторичная реплика в настоящее время находится в состоянии SYNCHRONIZED с первичной репликой.The entire failover set becomes relevant when no secondary replica is currently SYNCHRONIZED with the primary replica.

Если реплика доступности настраивается на синхронную фиксацию с автоматическим переходом на другой ресурс, реплика доступности входит в состав задан автоматический переход на другой ресурсautomatic failover set.When you configure an availability replica as synchronous commit with automatic failover, the availability replica becomes part of the задан автоматический переход на другой ресурсautomatic failover set. Однако функционирование набора зависит от текущей первичной реплики.However whether the set takes effect depends the current primary. То, какие виды перехода на другой ресурс являются доступными в определенный момент, зависит от наборов отработки отказа, действующих на данный момент.The forms of failover that are actually possible at a given time depends on what failover sets are currently in effect.

Например, рассмотрим группу доступности, которая имеет четыре реплики доступности:For example, consider an availability group that has four availability replicas, as follows:

РепликаReplica Настройки режима доступности и режима отработки отказаAvailability Mode and Failover Mode Settings
ОбъектA Синхронная фиксация с автоматической отработкой отказаSynchronous commit with automatic failover
BB Синхронная фиксация с автоматической отработкой отказаSynchronous commit with automatic failover
CC Синхронная фиксация только с плановой отработкой отказа вручнуюSynchronous commit with planned manual failover only
DD Асинхронная фиксация (только с режимом принудительной отработки отказа)Asynchronous commit (with only forced failover)

Поведение отработки отказа каждой из вторичных реплик зависит от того, какая реплика доступности назначена в данный момент первичной.The failover behavior for each secondary replica depends on which availability replica is currently the primary replica. Обычно для данной вторичной реплики отработка отказа— это худший возможный вариант при текущей первичной реплике.Basically, for a given secondary replica, the failover behavior is the worst case given the current primary replica. На следующем рисунке показано, как способ отработки отказа на вторичных репликах зависит от текущей первичной реплики и от того, настроена она на режим асинхронной фиксации (только с принудительным переходом на другой ресурс) или режим синхронной фиксации (с автоматическим переходом на другой ресурс или без него).The following figure illustrates how the failover behavior of secondary replicas varies depending on the current primary replica, and whether it is configured for asynchronous-commit mode (with only forced failover) or synchronous-commit mode (with or without automatic failover).

Влияние конфигурации первичной реплики на отработку отказаHow primary replica configuration affects failover

Automatic FailoverAutomatic Failover

Автоматический переход на другой ресурс вызывает переключение подходящей вторичной реплики в первичную роль после того, как первичная реплика становится недоступной.An automatic failover causes a qualified secondary replica to automatically transition to the primary role after the primary replica becomes unavailable. Автоматический переход на другой ресурс наиболее полезен в случае, если узел WSFC, на котором размещена первичная реплика, является локальным для узла, на котором размещена вторичная реплика.Automatic failover is best suited when the WSFC node that hosts the primary replica is local to the node that hosts the secondary replica. Так происходит потому, что синхронизация данных лучше всего работает при малой задержке сообщений между компьютерами, а клиентские соединения могут оставаться локальными.This is because data synchronization works best with low message latency between computers and because client connections can remain local.

В этом разделе.In This Section:

Необходимые условия для автоматического перехода на другой ресурсConditions Required for an Automatic Failover

Автоматический переход на другой ресурс происходит только при следующих условиях.Automatic failover occurs only under the following conditions:

  • Наличие набора автоматического перехода на другой ресурс.An automatic failover set exists. Этот набор состоит из первичной реплики и вторичной реплики ( цель автоматического перехода на другой ресурс), причем на обеих настроен режим синхронной фиксации и обе реплики имеют режим перехода на другой ресурс AUTOMATIC.This set consists of a primary replica and a secondary replica (the automatic failover target) that are both configured for synchronous-commit mode and set to AUTOMATIC failover. Если для первичной реплики задан режим перехода на другой ресурс MANUAL, автоматический переход на другой ресурс не может быть выполнен, даже если на вторичной реплике задан режим отработки перехода на другой ресурс AUTOMATIC.If the primary replica is set to MANUAL failover, automatic failover cannot occur, even if a secondary replica is set to AUTOMATIC failover.

    Дополнительные сведения см. в разделе Режимы доступности (группы доступности AlwaysOn).For more information, see Availability Modes (Always On Availability Groups).

  • Цель автоматического перехода на другой ресурс имеет нормальное состояние синхронизации (то есть все базы данных-получатели на цели отработки отказа синхронизированы с соответствующей базой данных-источником).The automatic failover target has a healthy synchronization state (this indicates that every secondary database on the failover target is synchronized with its corresponding primary database).

    Совет

    Группы доступности AlwaysOn отслеживают состояние обеих реплик из набора автоматического перехода на другой ресурс.Always On Availability Groups monitors the health of both replicas in an automatic failover set. В случае сбоя одной из реплик состоянию исправности группы доступности задается значение CRITICAL.If either replica fails, the availability group's health state is set to CRITICAL. В случае сбоя вторичной реплики выполнение автоматической отработки отказа невозможно, поскольку цель автоматического перехода на другой ресурс недоступна.If the secondary replica fails, automatic failover is not possible because the automatic failover target is unavailable. В случае сбоя первичной реплики группа доступности выполнит переход на вторичную реплику.If the primary replica fails, the availability group will fail over to the secondary replica. Цель автоматического перехода на другой ресурс будет отсутствовать, пока реплика, которая ранее была первичной, не вернется в режим «в сети».Until the former primary replica comes online, no automatic failover target exists. В любом случае для обеспечения доступности в случае последовательного сбоя (который маловероятен) рекомендуется в качестве цели автоматического перехода на другой ресурс задать другую вторичную реплику.In either case, to ensure availability in the unlikely case of a sequential failure, we recommend that you configure a different secondary replica as the automatic failover target.

    Дополнительные сведения см. в статьях Использование политик AlwaysOn для определения работоспособности группы доступности (SQL Server) и Изменение режима отработки отказа для реплики доступности (SQL Server).For more information, see Use Always On Policies to View the Health of an Availability Group (SQL Server) and Change the Failover Mode of an Availability Replica (SQL Server).

  • Кластер WSFC имеет кворум.The Windows Server Failover Clustering (WSFC) cluster has quorum. Дополнительные сведения см. в статье Режимы кворума и конфигурация голосования WSFC (SQL Server).For more information, see WSFC Quorum Modes and Voting Configuration (SQL Server).

  • Первичная реплика стала недоступной и уровни условий перехода на другой ресурс, заданные гибкой политикой отработки отказа, были удовлетворены.The primary replica has become unavailable, and the failover-condition levels defined by your the flexible failover policy have been met. Дополнительные сведения об уровнях условий перехода на другой ресурс см. в статье Гибкая политика отработки отказа для автоматического перехода на другой ресурс группы доступности (SQL Server).For information about failover-condition levels, see Flexible Failover Policy for Automatic Failover of an Availability Group (SQL Server).

Принцип работы автоматической отработки отказаHow Automatic Failover Works

Автоматический переход на другой ресурс включает в себя следующие действия.An automatic failover initiates the following sequence of actions:

  1. Если экземпляр сервера, на котором размещена текущая первичная реплика, все еще работает, он изменяет состояние баз данных-источников на DISCONNECTED и отсоединяет всех клиентов.If the server instance that is hosting the current primary replica is still running, it changes the state of the primary databases to DISCONNECTED and disconnects all clients.

  2. Если в очередях восстановления целевой вторичной реплики существуют ожидающие записи журнала, вторичная реплика применит оставшиеся записи журнала, чтобы завершить накат баз данных-получателей.If any log records are waiting in recovery queues on the target secondary replica, the secondary replica applies the remaining log records to finish rolling forward the secondary databases.

    Примечание

    Длительность применения журнала к заданной базе данных зависит от скорости системы, текущего уровня загрузки и количества записей журнала в очереди восстановления.The amount of time required to apply the log to a given database depends on the speed of the system, the recent work load, and the amount of log in the recovery queue.

  3. Бывшая вторичная реплика переключается на первичную роль.The former secondary replica transitions to the primary role. Ее базы данных становятся базами данных-источниками.Its databases become the primary databases. Новая первичная реплика выполнит откат всех незафиксированных транзакций (этап отката восстановления) как можно скорее.The new primary replica rolls back any uncommitted transactions (the undo phase of recovery) as quickly as possible. Блокировки изолируют эти незафиксированные транзакции, позволяя выполнить откат в фоновом режиме, давая пользователям возможность работать с базой данных.Locks isolate these uncommitted transactions, allowing roll back to occur in the background while clients use the database. Этот процесс не выполняет откат каких-либо зафиксированных транзакций.This process does not roll back any committed transactions.

    До момента подключения база данных-получатель временно помечается как NOT_SYNCHRONIZED.Until a given secondary database is connected, it is briefly marked as NOT_SYNCHRONIZED. Перед началом восстановления с откатом базы данных-получатели могут подключаться к новым базам данных-источникам и быстро переходить в состояние SYNCHRONIZED.Before the rollback recovery starts, secondary databases can connect to the new primary databases and quickly transition to the SYNCHRONIZED state. Как правило, лучшим вариантом является третья реплика синхронной фиксации, которая остается во вторичной роли после отработки отказа.The best case is usually for a third synchronous-commit replica that remains in the secondary role after the failover.

  4. Позднее, когда экземпляр сервера, на котором размещена бывшая первичная реплика, перезагрузится, он распознает, что первичная роль теперь принадлежит другой реплике доступности.Later, when the server instance that is hosting the former primary replica restarts, it recognizes that another availability replica now owns the primary role. Бывшая первичная реплика перейдет в роль вторичной, а ее базы данных станут базами данных-получателями.The former primary replica transitions to the secondary role, and its databases become secondary databases. Новая вторичная реплика как можно быстрее установит соединение с текущей первичной репликой и обновит свои базы данных до состояния текущих баз данных-источников.The new secondary replica connects to the current primary replica and catches its database up to the current primary databases as quickly as possible. Как только новая вторичная реплика выполнит повторную синхронизацию своих баз данных, отработка отказа снова станет возможной, но уже в обратном направлении.As soon as the new secondary replica has resynchronized its databases, failover is again possible, in the reverse direction.

Настройка автоматического перехода на другой ресурсTo Configure Automatic Failover

Реплика доступности в любой момент может быть настроена на поддержку автоматического перехода на другой ресурс.An availability replica can be configured to support automatic failover at any point.

To configure automatic failoverTo configure automatic failover

  1. Убедитесь, что вторичная реплика настроена на использование режима доступности синхронной фиксации.Ensure that the secondary replica is configured to use the synchronous-commit availability mode. Дополнительные сведения см. в разделе Смена режима доступности для реплики доступности (SQL Server).For more information, see Change the Availability Mode of an Availability Replica (SQL Server).

  2. Задайте автоматический режим перехода на другой ресурс.Set the failover mode to automatic. Дополнительные сведения см. в разделе Смена режима отработки отказа для реплики доступности (SQL Server).For more information, see Change the Failover Mode of an Availability Replica (SQL Server).

  3. Также можно изменить политику гибкой отработки отказа в группе доступности и указать типы сбоев, которые вызывают автоматический переход на другой ресурс.Optionally, change the flexible failover policy of the availability group to specify the sorts of failures that can cause an automatic failover to occur. Дополнительные сведения см. в разделе Настройка гибкой политики отработки отказа для обеспечения контроля над автоматическим переходом на другой ресурс (группы доступности AlwaysOn) и Политика отработки отказа для экземпляров отказоустойчивого кластера.For more information, see Configure the Flexible Failover Policy to Control Conditions for Automatic Failover (Always On Availability Groups) and Failover Policy for Failover Cluster Instances.

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

При использовании перехода на другой ресурс вручную, вторичная реплика принимает первичную роль после того, как администратор базы данных отдает команду перехода на другой ресурс вручную для экземпляра сервера, на котором размещена целевая вторичная реплика.A manual failover causes a synchronized secondary replica to transition to the primary role after a database administrator issues a manual-failover command on the server instance that hosts the target secondary replica. Для поддержки перехода на другой ресурс вручную во вторичной реплике и текущей первичной реплике должен быть настроен режим синхронной фиксации.To support manual failover, the secondary replica and the current primary replica must both be configured for synchronous-commit mode, if any. Все базы данных-получатели на реплике доступности должны быть соединены с группой доступности и синхронизированы с ее соответствующими базами данных-источниками (то есть вторичная реплика должна быть синхронизирована).Every secondary database on the availability replica must be joined to the availability group and synchronized with its corresponding primary database (that is, the secondary replica must be synchronized). Это гарантирует, что все транзакции, зафиксированные в бывшей базе данных-источнике, также будут зафиксированы в новой базе данных-источнике.This guarantees that every transaction that was committed on a former primary database has also been committed on the new primary database. По этой причине новые базы данных-источники будут идентичны старым базам данных-источникам.Therefore, the new primary databases are identical to the old primary databases.

На следующем рисунке показаны этапы запланированной отработки отказа.The following figure illustrates the stages of a planned failover:

  1. Перед отработкой отказа первичная реплика размещается на экземпляре сервера на узле Node01.Before the failover, the primary replica is hosted by the server instance on Node01.

  2. Администратор базы данных запускает запланированный переход на другой ресурс.A database administrator initiates a planned failover. Целью является реплика доступности, размещаемая в экземпляре сервера в узле Node02.The failover target is the availability replica hosted by the server instance on Node02.

  3. Цель перехода на другой ресурс (в узле Node02) становится новой первичной репликой.The failover target (on Node02) becomes the new primary replica. Поскольку это запланированный переход на другой ресурс, бывшая первичная реплика принимает вторичную роль и немедленно переводит свои базы данных в режим «в сети» в качестве баз данных-получателей.Because this is a planned failover, the former primary replica switches to the secondary role during the failover and brings its databases online as secondary databases immediately.

Демонстрация запланированной отработки отказа вручнуюIllustation of a planned manual failover

В этом разделе.In This Section:

Условия для отработки отказа вручнуюConditions Required for a Manual Failover

Для обеспечения поддержки перехода на другой ресурс вручную текущая первичная реплика должна быть настроена на режим синхронной фиксации. Кроме того, вторичная реплика должна удовлетворять следующим условиям.To support a manual failover, the current primary replica must be set to synchronous-commit mode and a secondary replica must be:

  • Она должна быть настроена на работу в режиме синхронной фиксации.Configured for synchronous-commit mode.

  • В данный момент она должна быть синхронизирована с первичной репликой.Currently synchronized with the primary replica.

Чтобы вручную перевести группу доступности на другой ресурс, нужно подключиться ко вторичной реплике, которую планируется сделать первичной.To manually fail over an availability group, you must be connected to the secondary replica that is to become the new primary replica.

Как работает запланированный переход на другой ресурс вручнуюHow a Planned Manual Failover Works

Запланированный переход на другой ресурс вручную, который должен инициироваться на целевой вторичной реплике, вызывает следующую последовательность действий.A planned manual failover, which must be initiated on the target secondary replica, initiates the following sequence of actions:

  1. Чтобы не допустить выполнения новых пользовательских транзакций в исходных базах данных-источниках, кластер WSFC отправляет запрос на перевод первичной реплики в режим «вне сети».To ensure that no new user transactions occur on the original primary databases, the WSFC cluster sends a request to the primary replica to go offline.

  2. Если в очереди восстановления любой базы данных-получателя присутствуют какие либо журналы, вторичная реплика закончит накат для этой базы данных-получателя.If any log is waiting in the recovery queue of any secondary database, the secondary replica finishes rolling forward that secondary database. Длительность выполнения зависит от скорости системы, текущей рабочей нагрузки и количества записей журнала в очереди восстановления.The amount of time required depends on the speed of the system, the recent workload, and the amount of log in the recovery queue. Для определения текущего размера очереди восстановления используйте счетчик производительности Recovery Queue .To learn the current size of the recovery queue, use the Recovery Queue performance counter. Дополнительные сведения см. в статье SQL Server, реплика базы данных.For more information, see SQL Server, Database Replica.

    Примечание

    Время отработки отказа можно регулировать путем ограничения размера очереди восстановления.The failover time can be regulated by limiting the size of the recovery queue. Однако это может привести к замедлению работы первичной реплики, чтобы дать возможность вторичной реплике не отставать.However, this can cause the primary replica to slow down to allow the secondary replica to keep up.

  3. Вторичная реплика становится новой первичной репликой, а бывшая первичная реплика становится вторичной репликой.The secondary replica becomes the new primary replica, and the former primary replica becomes the new secondary replica.

  4. Новая первичная реплика выполняет откат всех незафиксированных транзакций и переводит свои базы данных в режим «в сети» в качестве баз данных-источников. Все базы данных-получатели кратковременно помечаются состоянием NOT SYNCHRONIZED до момента их подключения и повторной синхронизации с новыми базами данных-источниками.The new primary replica rolls back any uncommitted transactions and brings its databases online as the primary databases.All secondary databases are briefly marked as NOT SYNCHRONIZED until they connect and resynchronize to the new primary databases. Этот процесс не выполняет откат каких-либо зафиксированных транзакций.This process does not roll back any committed transactions.

  5. Когда бывшая первичная реплика перейдет в режим «в сети», она примет вторичную роль, а бывшая база данных-источник станет базой данных-получателем.When the former primary replica comes back online, it takes on the secondary role, and the former primary database becomes the secondary database. Новая вторичная реплика быстро выполнит повторную синхронизацию новых баз данных-получателей с соответствующими базами данных-источниками.The new secondary replica quickly resynchronizes the new secondary databases with the corresponding primary databases.

    Примечание

    Как только новая вторичная реплика выполнит повторную синхронизацию баз данных, отработка отказа снова станет возможной, но уже в обратном направлении.As soon as the new secondary replica has resynchronized the databases, failover is again possible, but in the reverse direction.

После отработки отказа клиенты должны повторно подключиться к текущей базе данных-источнику.After failover, clients must reconnect to the current primary database. Дополнительные сведения см. в разделе Прослушиватели групп доступности, возможность подключения клиентов и отработка отказа приложений (SQL Server).For more information, see Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server).

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

Администратор базы данных групп доступности может использовать переходы на другой ресурс вручную для поддержки доступности баз данных при обновлении программного обеспечения или оборудования.The database administrator for your availability groups can use manual failovers to maintain database availability when you upgrade hardware or software. Для использования группы доступности для выполнения программных обновлений экземпляр сервера или узел компьютера, на котором размещена целевая вторичная реплика, должен уже иметь соответствующие обновления.To use an availability group for software upgrades, the server instance and/or computer node that hosts the target secondary replica must have already received the upgrades. Дополнительные сведения см. в статье Обновление экземпляров реплики группы доступности AlwaysOn.For more information, see Upgrading Always On Availability Group Replica Instances.

Принудительная отработка отказа (с возможной потерей данных)Forced Failover (with Possible Data Loss)

Принудительный переход на другой ресурс группы доступности (с возможной потерей данных) — метод аварийного восстановления, позволяющий использовать вторичную реплику в качестве резервного сервера. Поскольку принудительный переход на другой ресурс может привести к потере данных, его следует использовать осторожно и только в случае необходимости.Forcing failover of an availability group (with possible data loss) is a disaster recovery method that allows you to use a secondary replica as a warm standby server.Because forcing failover risks possible data loss, it should be used cautiously and sparingly. Принудительную отработку отказа рекомендуется применять только когда требуется немедленное восстановление доступа к базам данных доступности и допускается риск потери данных.We recommend forcing failover only if you must restore service to your availability databases immediately and are willing to risk losing data. Дополнительные сведения о требованиях и рекомендациях для принудительной отработки отказа, а также пример использования принудительного перехода на другой ресурс для восстановления из ситуации критического сбоя см. в статье Выполнение принудительного перехода на другой ресурс вручную для группы доступности (SQL Server).For more information about the prerequisites and recommendations for forcing failover and for an example scenario that uses a forced failover to recover from a catastrophic failure, see Perform a Forced Manual Failover of an Availability Group (SQL Server).

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

Для принудительной отработки отказа необходим кворум в кластере WSFC.Forcing failover requires that the WSFC cluster have quorum. Дополнительные сведения о настройке кворума и принудительном создании кворума см. в статье Отказоустойчивая кластеризация Windows Server (WSFC) с SQL Server.For information about configuring quorum and forcing quorum, see Windows Server Failover Clustering (WSFC) with SQL Server.

В этом разделе.In This Section:

Принципы работы принудительной отработки отказаHow Forced Failover Works

Принудительная отработка отказа инициирует переход первичной роли целевой реплике, роль которой находится в состоянии SECONDARY или RESOLVING.Forcing failover initiates a transition of the primary role to a target replica whose role is in the SECONDARY or RESOLVING state. Цель отработки отказа становится новой первичной репликой и немедленно доставляет свои копии баз данных клиентам.The failover target becomes the new primary replica and immediately serves its copies of the databases to clients. Если бывшая первичная реплика станет доступной, она переключится в роль вторичной; ее базы данных станут базами данных-получателями.When the former primary replica becomes available, it will transition to the secondary role and its databases will become secondary databases.

Все базы данных-получатели (включая бывшие базы данных-источники, когда они станут доступны) приостановлены.All secondary databases (including the former primary databases, when they become available) are SUSPENDED. В зависимости от предыдущего состояния синхронизации данных в приостановленной базе данных-получателе, возможно, из нее не удастся извлечь отсутствующие зафиксированные данные этой базы данных-источника.Depending on the previous data synchronization state of a suspended secondary database, it might be suitable for salvaging missing committed data for that primary database. Во вторичной реплике, настроенной на доступ только для чтения, можно выполнять запросы к базам данных-получателям для извлечения отсутствующих данных вручную.On a secondary replica that is configured for read-only access, you can query the secondary databases to manually discover missing data. Затем можно выполнить инструкции Transact-SQLTransact-SQL в новых базах данных-источниках для внесения необходимых изменений.Then you can issue Transact-SQLTransact-SQL statements on the new primary databases to make any necessary changes.

Риск использования принудительной отработки отказаRisks of Forcing Failover

Важно понимать, что принудительная отработка отказа может привести к потере данных.It is essential to understand that forcing failover can cause data loss. Возможность потери данных обусловлена тем, что целевая реплика не может взаимодействовать с первичной, поэтому не может гарантировать синхронизацию баз данных.Data loss is possible because the target replica cannot communicate with the primary replica and, therefore, cannot guarantee that the databases are synchronized. Кроме того, принудительная отработка отказа создает новую вилку восстановления.Forcing failover starts a new recovery fork. Поскольку исходные базы данных-источники и базы данных-получатели находятся на разных вилках восстановления, каждая из них содержит данные, отсутствующие в других. Каждая исходная база данных-источник содержит изменения, которые еще не были отправлены из ее очереди отправки в бывшую базу данных-получатель (неотправленный журнал); бывшие базы данных-получатели содержат изменения, внесенные после принудительного перехода на другой ресурс.Because the original primary databases and secondary databases are on different recovery forks, each of them now contains data that the other database does not contain: each original primary database contains whatever changes were not yet sent from its send queue to the former secondary database (the unsent log); the former secondary databases contain whatever changes occur after failover was forced.

Если принудительная отработка отказа выполняется из-за выхода из строя первичной реплики, вероятность потери данных зависит от того, были ли журналы транзакций отправлены во вторичную реплику перед сбоем.If failover is forced because the primary replica has failed, potential data loss depends on whether or not any transaction logs had been sent to the secondary replica before the failure. В режиме асинхронной фиксации всегда возможно накопление журнала неотправленных изменений.Under the asynchronous-commit mode, accumulated unsent log is always a possibility. В режиме синхронной фиксации это возможно только до момента, пока база данных-получатель синхронизирована.Under synchronous-commit mode, this is possible only until the secondary databases become synchronized.

В следующей таблице приведена сводка возможных ситуаций потери данных в конкретной базе данных в реплике, на которую выполняется принудительная отработка отказа.The following table summarizes the possibility of data loss for a particular database on the replica to which you force failover.

Режим доступности вторичной репликиAvailability mode of Secondary Replica База данных синхронизирована?Is database synchronized? Потеря данных возможна?Is data loss possible?
Синхронная фиксацияSynchronous-commit ДаYes нетNo
Синхронная фиксацияSynchronous-commit нетNo ДаYes
Асинхронная фиксацияAsynchronous-commit нетNo ДаYes

Базы данных-получатели отслеживают только две вилки восстановления, поэтому, если выполнить несколько принудительных переходов на другой ресурс, любая база данных-получатель, которая начала синхронизацию данных после предыдущей принудительной отработки отказа, не сможет продолжить работу.Secondary databases track only two recovery forks, so if you perform multiple forced failovers, any secondary database that did start data synchronization with the previous force failover might not be able to resume. Если это происходит, все базы данных-получатели, возобновить работу которых не удастся, потребуется удалить из группы доступности, восстановить на нужный момент времени и повторно присоединить к группе доступности.If this occurs, any secondary databases that cannot be resumed will need to be removed from the availability group, restored to the correct point in time, and rejoined to the availability group. В этом сценарии может наблюдаться ошибка 1408 с состоянием 103 (ошибка: 1408, серьезность: 16, состояние: 103).Error 1408 with state 103 may be observed in this scenario (Error: 1408, Severity: 16, State: 103). Восстановление не работает по нескольким вилкам, поэтому после выполнения дополнительных принудительных отработок отказа необходимо создать резервную копию журнала.A restore will not work across multiple recovery forks, therefore, be sure to perform a log backup after performing more than one forced failover.

Почему принудительная отработка отказа требуется после принудительного создания кворумаWhy Forced Failover is Required After Forcing Quorum

После принудительного создания кворума в кластере WSFC (принудительный кворум) необходимо выполнить принудительную отработку отказа (с возможной потерей данных) для каждой группы доступности.After quorum is forced on the WSFC cluster (forced quorum) you need to perform a forced failover (with possible data loss) on each availability group. Принудительная отработка отказа необходима, поскольку реальное состояние значений кластера WSFC могло быть потеряно.The forced failover is required because the real state of the WSFC cluster values might have been lost. Предотвращение нормальных отработок отказа после принудительного создания кворума необходимо из-за возможности того, что несинхронизированная вторичная реплика будет выглядеть синхронизированной на вновь скомпонованном кластере WSFC.Preventing normal failovers after a forced quorum is required because of the possibility than an unsynchronized secondary replica would appear to be synchronized on the reconfigured WSFC cluster.

Например, рассмотрим кластер WSFC с размещенной на трех узлах группой доступности. Первичная реплика находится на узле A, a на каждом из узлов B и C размещается вторичная реплика.For example, consider a WSFC cluster that hosts an availability group on three nodes: Node A hosts the primary replica and Node B and Node C each hosts a secondary replica. Узел C отключается от кластера WSFC, пока локальная вторичная реплика находится в состоянии SYNCHRONIZED.Node C gets disconnected from the WSFC cluster while the local secondary replica is SYNCHRONIZED. Однако узел A и узел B сохраняют работоспособный кворум, а группа доступности остается подключенной к сети.But Node A and Node B retain a healthy quorum and the availability group remains online. На узле A первичная реплика по-прежнему принимает обновления, а на узле B вторичная реплика продолжает синхронизироваться с первичной репликой.On Node A, the primary replica continues to accept updates, and on Node B, the secondary replica continues to synchronize with the primary replica. На узле C вторичная реплика становится несинхронизированной и все больше отстает от первичной реплики.The secondary replica on Node C becomes unsynchronized and falls increasingly behind the primary replica. Однако, поскольку узел C отключен от сети, реплика остается (неправильно) в состоянии SYNCHRONIZED.However, because Node C is disconnected, the replica remains, incorrectly, in the SYNCHRONIZED state.

Если кворум будет потерян, а затем принудительно создан на узле A, состояние синхронизации группы доступности в кластере WSFC должно быть правильным: вторичная реплика на узле С должна быть показана как несинхронизированная (UNSYNCHRONIZED).If quorum is lost and is then forced on Node A, the synchronization state of the availability group on the WSFC cluster should be correct-with the secondary replica on Node C shown as UNSYNCHRONIZED. Однако, если кворум принудительно создан на узле C, синхронизация группы доступности будет неверной.However, if quorum is forced on Node C, the synchronization of the availability group will be incorrect. Синхронизация на кластере вернется к состоянию, существовавшему в то время, когда узел C был отключен — вторичная реплика на узле C будет неправильно показана как синхронизированная (SYNCHRONIZED).The synchronization state on the cluster will have reverted back to when Node C was disconnected-with the secondary replica on Node C incorrectly shown as SYNCHRONIZED. Поскольку запланированные отработки отказа вручную гарантируют безопасность данных, им запрещено возвращать группу доступности в сеть после принудительного создания кворума.Since planned manual failovers guarantee the safety of the data, they are disallowed for bring an availability group back online after quorum is forced.

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

Если кластер WSFC имеет работоспособный кворум, можно оценить текущую вероятность потери данных в базах данных.When the WSFC cluster has a healthy quorum, you can estimate the current potential for data loss on databases. Для данной вторичной реплики текущая вероятность потери данных зависит от того, насколько сильно локальные базы данных-получатели отстают от соответствующих баз данных-источников.For a given secondary replica, the current potential for data loss depends on how far the local secondary databases are lagging behind the corresponding primary databases. Так как величина запаздывания изменяется со временем, рекомендуется периодически отслеживать потенциальные потери данных для несинхронизированных баз данных-получателей.Because the amount of lag varies over time, we recommend that you periodically track potential data loss for your unsynchronized secondary databases. Журнал отслеживания обеспечивает сравнение номера LSN последней фиксации и времени последней фиксации для каждой базы данных-источника и ее баз данных-получателей следующим образом.Tracking lag involves comparing the Last Commit LSN and Last Commit Time for each primary database and its secondary databases, as follows:

  1. Подключитесь к первичной реплике.Connect to the primary replica.

  2. Выполните запрос к столбцам типа last_commit_lsn (номер LSN последней зафиксированной транзакции) и last_commit_time (время последней фиксации) динамического административного представления sys.dm_hadr_database_replica_states .Query the last_commit_lsn (LSN of the last committed transaction) and last_commit_time (time of the last commit) columns of the sys.dm_hadr_database_replica_states dynamic management view.

  3. Сравните значения, возвращаемые для каждой базы данных-источника и каждой из ее баз данных-получателей.Compare the values returned for each primary database and each of its secondary databases. Различие между их номерами LSN последней фиксации указывает величину отставания.The difference between their Last Commit LSNs indicate the amount of lag.

  4. Можно инициировать предупреждение, если величина отставания для базы данных или набора баз данных превышает заданное максимальное отставание за определенный период времени.You can trigger an alert when the amount of lag on a database or set of databases exceeds your desired maximum lag for a given period of time. Например, запрос может быть инициирован заданием, которое выполняется каждую минуту на каждой базе данных-источнике.For example, the query can be run by a job that executes every minute on each primary database. Если различие между last_commit_time базы данных-источника и любой из ее баз данных-получателей превышает целевую точку восстановления (RPO) (например, 5 минут) с момента последнего выполнения задания, задание может инициировать предупреждение.If the difference between the last_commit_time of a primary database and any of its secondary databases has exceeded the recovery point objective (RPO) (for example, 5 minutes) since the last time the job executed, the job can raise an alert.

Важно!

Если кластер WSFC не имеет кворума или кворум был создан принудительно, last_commit_lsn и last_commit_time равны NULL.When the WSFC cluster lacks quorum or quorum has been forced, last_commit_lsn and last_commit_time are NULL. Дополнительные сведения о том, как избежать потери данных после принудительного создания кворума, см. в подразделе "Потенциальные методы избежания потери данных после принудительного создания кворума" в статье Выполнение принудительного перехода на другой ресурс вручную для группы доступности (SQL Server).For information about how you might be able to avoid data loss after you forced quorum, see "Potential Ways to Avoid Data Loss After Quorum is Forced" in Perform a Forced Manual Failover of an Availability Group (SQL Server).

Управление возможной потерей данныхManaging the Potential Data Loss

После принудительной отработки отказа все базы данных-получатели приостанавливаются.After failover is forced, all secondary databases are suspended. Это относится к бывшим базам данных-источникам, для которых бывшая первичная реплика вновь переходит в режим «в сети» и обнаруживает, что отныне является вторичной репликой.This includes the former primary databases, after the former primary replica comes back online and discovers that it is now a secondary replica. Необходимо вручную возобновить работу каждой приостановленной базы данных во вторичной реплике.You must manually resume each suspended database individually on each secondary replica.

Как только бывшая первичная реплика становится доступной (при условии, что базы данных остались неповрежденными), можно попытаться избежать потенциальной потери данных.Once the former primary replica is available, assuming that its databases are undamaged, you can attempt to manage the potential data loss. Доступные подходы управления возможной потерей данных зависят от того, была ли исходная первичная реплика соединена с новой первичной репликой.The available approach for managing potential data loss depends on whether the original primary replica has connected to the new primary replica. Если исходная первичная реплика может обратиться к новому первичному экземпляру, восстановление соединения произойдет автоматически и прозрачно.Assuming that the original primary replica can access the new primary instance, reconnecting occurs automatically and transparently.

Исходная первичная реплика была повторно присоединенаThe Original Primary Replica Has Reconnected

После сбоя бывшая первичная реплика обычно быстро восстанавливает соединение со своим партнером.Typically, after a failure, when the original primary replica restarts it quickly reconnects to its partner. После повторного подключения, исходная первичная реплика становится вторичной репликой.On reconnecting, the original primary replica becomes the secondary replica. Ее базы данных становятся базами данных-получателями и переходят в состояние SUSPENDED.Its databases becomes the secondary databases and enter the SUSPENDED state. Откат новых баз данных-получателей будет нельзя выполнить до тех пор, пока они не будут возобновлены.The new secondary databases will not be not rolled back unless you resume them.

Однако приостановленные базы данных являются недоступными, поэтому их нельзя исследовать и определить, какие данные будут потеряны при возобновлении данной базы данных.However, the suspended databases are inaccessible, so you cannot inspect them to evaluate what data would be lost if you were to resume a given database. Таким образом, решение о возобновлении или удалении базы данных-получателя зависит от того, допустима ли потеря данных следующим образом.Therefore, the decision on whether to resume or remove a secondary database depends on whether you are willing to accept any data loss, as follows:

  • Если потеря данных недопустима, следует удалить базы данных из группы доступности, чтобы сохранить их.If losing any data would be unacceptable, you should remove the databases from the availability group to salvage them.

    Теперь администратор базы данных сможет восстановить бывшие базы данных-источники и попытаться восстановить данные, которые были бы потеряны.The database administrator can now recover the former primary databases and attempt to recover the data that would have been lost. Однако когда бывшая база данных-источник станет доступной, она будет отличаться от текущей базы данных-источника, поэтому администратору баз данных придется сделать либо удаленную, либо текущую базу данных-источник недоступной клиентам, чтобы избежать их дальнейшего расхождения и проблем, связанных с переходом на другой ресурс на стороне клиентов.However, when a former primary database comes online, it is divergent from the current primary database, so the database administrator needs to make either the removed database or the current primary database inaccessible to clients to avoid further divergence of the databases and to prevent client-failover issues.

  • Если потеря данных будет приемлема для ваших бизнес-целей, можно возобновить базы данных-получатели.If losing data would be acceptable to your business goals, you can resume the secondary databases.

    При возобновлении базы данных-получателя, первым шагом ее синхронизации является откат.Resuming a new secondary database causes it to be rolled back as the first step in synchronizing the database. Если очередь отправки содержала какие-либо записи журнала в момент выхода из строя сервера, соответствующие транзакции будут потеряны, даже если они были зафиксированы.If any log records were waiting in the send queue at the time of failure, the corresponding transactions are lost, even if they were committed.

Исходная первичная реплика не была повторно присоединенаThe Original Primary Replica Has Not Reconnected

Если вы можете временно предотвратить повторное подключение исходной первичной реплики по сети к новой первичной реплике, у вас будет возможность изучить исходные базы данных-источники и оценить, какие данные будут потеряны при их возобновлении.If you can temporarily prevent the original primary replica from reconnecting over the network to the new primary replica, you can inspect the original primary databases to evaluate what data would be lost if they were resumed.

  • Если потенциальная потеря данных допустимаIf the potential data loss is acceptable

    Разрешите исходной первичной реплике повторно подключиться к новой первичной реплике.Allow the original primary replica to reconnect to the new primary replica. Повторное подключение приводит к приостановке новых баз данных-получателей.Reconnecting causes the new secondary databases to be suspended. Чтобы начать синхронизацию данных в базе данных, просто возобновите ее.To start data synchronization on a database, simply resume it. Новая вторичная реплика удалит исходную вилку восстановления для этой базы данных, потеряв все транзакции, которые не были переданы или получены бывшей вторичной репликой.The new secondary replica drops the original recovery fork for that database, losing any transactions that were never sent to or received by the former secondary replica.

  • Потеря данных недопустимаIf the data loss is unacceptable

    Если исходная база данных-источник содержит важные данные, которые будут потеряны при возобновлении приостановленной базы данных, их можно сохранить в исходной базе данных-источнике, удалив ее из группы доступности.If the original primary database contains critical data that would be lost if you resumed the suspended database, you can preserve the data on the original primary database by removing it from the availability group. При этом база данных перейдет в состояние RESTORING.This causes the database to enter the RESTORING state. В этот момент рекомендуется попытаться выполнить резервное копирование заключительного фрагмента журнала удаленной базы данных.At this point, we recommend that you attempt to back up the tail of the removed database's log. Затем можно обновить текущую базу данных-источник (бывшую базу данных-получатель), экспортировав данные, которые необходимо сохранить, из исходной базы данных-источника и импортировав их в текущую базу данных-источник.Then, you can update the current primary (the former secondary database) by exporting the data you want to salvage from the original primary database and importing it into the current primary database. При этом рекомендуется как можно скорее создать полную резервную копию обновленной базы данных-источника.We recommend taking a full database backup of the updated primary database as quickly as possible.

    Затем на экземпляре сервера, на котором размещена новая вторичная реплика, можно удалить приостановленную базу данных-получатель и создать новую базу данных-получатель, восстановив эту резервную копию (и по крайней мере одну из последующих резервных копий журнала) с помощью инструкции RESTORE WITH NORECOVERY.Then, on the server instance that hosts the new secondary replica, you can delete the suspended secondary database and create a new secondary database by restoring this backup (and least one subsequent log backup) using RESTORE WITH NORECOVERY. Рекомендуется отложить создание дополнительных резервных копий журнала текущих баз данных-источников до возобновления соответствующих баз данных-получателей.We recommend delaying additional log backups of the current primary databases until the corresponding secondary databases are resumed.

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

Если хотя бы одна из баз данных-получателей приостановлена, усечение журнала транзакций в базе данных-источнике откладывается.Transaction log truncation is delayed on a primary database while any of its secondary databases is suspended. Кроме того, во время приостановки любой локальной базы данных невозможен переход состояния вторичной реплики с синхронной фиксацией в HEALTHY.Also the synchronization health of a synchronous-commit secondary replica cannot transition to HEALTHY as long as any local database remains suspended.

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

Настройка режима перехода на другой ресурсTo configure failover behavior

Выполнение перехода на другой ресурс вручнуюTo perform a manual fail over

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

См. такжеRelated Content

См. также:See Also

Обзор групп доступности AlwaysOn (SQL Server) Overview of Always On Availability Groups (SQL Server)
Режимы доступности (группы доступности AlwaysOn) Availability Modes (Always On Availability Groups)
Отказоустойчивая кластеризация Windows Server (WSFC) с SQL Server Windows Server Failover Clustering (WSFC) with SQL Server
Транзакции между базами данных и распределенные транзакции для групп доступности AlwaysOn и зеркального отображения базы данных (SQL Server) Cross-Database Transactions and Distributed Transactions for Always On Availability Groups and Database Mirroring (SQL Server)
Политика отработки отказа для экземпляров отказоустойчивого кластера Failover Policy for Failover Cluster Instances
Гибкая политика отработки отказа для автоматического перехода на другой ресурс группы доступности (SQL Server)Flexible Failover Policy for Automatic Failover of an Availability Group (SQL Server)