Различия между режимами доступности для группы доступности Always OnDifferences between availability modes for an Always On availability group

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

В Группы доступности AlwaysOnAlways On availability groups режим доступности — это свойство реплики, которое определяет, способна ли данная реплика доступности работать в режиме синхронной фиксации.In Группы доступности AlwaysOnAlways On availability groups, the availability mode is a replica property that determines whether a given availability replica can run in synchronous-commit mode. Для каждой реплики доступности режим доступности необходимо настроить на режим синхронной или асинхронной фиксации либо только на режим конфигурации.For each availability replica, the availability mode must be configured for either synchronous-commit mode, asynchronous-commit, or configuration only mode. Если первичная реплика настроена на режим асинхронной фиксации, она не ждет, что какая-либо вторичная реплика зафиксирует входящие записи журнала транзакций на диск (для фиксации журнала).If the primary replica is configured for asynchronous-commit mode, it does not wait for any secondary replica to write incoming transaction log records to disk (to harden the log). Если данная вторичная реплика доступности настроена на режим асинхронной фиксации, первичная реплика не ждет, что эта вторичная реплика зафиксирует журнал.If a given secondary replica is configured for asynchronous-commit mode, the primary replica does not wait for that secondary replica to harden the log. Если и первичная, и вторичная реплика настроены на использование режима синхронной фиксации, то первичная реплика ожидает от вторичной реплики подтверждения фиксации журнала (за исключением случая, если вторичная реплика окажется неспособной проверить связь с первичной репликой в течение времени ожидания сеансапервичной реплики).If both the primary replica and a given secondary replica are both configured for synchronous-commit mode, the primary replica waits for the secondary replica to confirm that it has hardened the log (unless the secondary replica fails to ping the primary replica within the primary's session-timeout period).

Примечание

Если вторичная реплика превышает время ожидания сеанса первичной реплики, то последняя реплика временно переходит в режим асинхронной фиксации по отношению к этой вторичной реплике.If primary's session-timeout period is exceeded by a secondary replica, the primary replica temporarily shifts into asynchronous-commit mode for that secondary replica. Когда вторичная реплика восстанавливает соединение с первичной репликой, они снова начинают работать в режиме синхронной фиксации.When the secondary replica reconnects with the primary replica, they resume synchronous-commit mode.

Поддерживаемые режимы доступностиSupported Availability Modes

Группы доступности AlwaysOnAlways On availability groups поддерживает три режима доступности: режим асинхронной фиксации, режим синхронной фиксации, а также режим "только конфигурация".supports three availability modes-asynchronous-commit mode, synchronous-commit mode, and configuration only mode as follows:

  • Режим асинхронной фиксации представляет собой решение аварийного восстановления, которое работает хорошо тогда, когда реплики доступности распределены на значительном расстоянии.Asynchronous-commit mode is a disaster-recovery solution that works well when the availability replicas are distributed over considerable distances. Если каждая вторичная реплика доступности работает в режиме асинхронной фиксации, первичная реплика не ждет, пока какая-либо вторичная реплика зафиксирует журнал.If every secondary replica is running under asynchronous-commit mode, the primary replica does not wait for any of the secondary replicas to harden the log. Вместо этого сразу же после помещения записи журнала в локальный файл журнала первичная реплика отправляет клиенту подтверждение транзакции.Rather, immediately after writing the log record to the local log file, the primary replica sends the transaction confirmation to the client. Первичная реплика работает с минимальной задержкой транзакции в отношении вторичной реплики, настроенной для работы в режиме асинхронной фиксации.The primary replica runs with minimum transaction latency in relation to a secondary replica that is configured for asynchronous-commit mode. Если текущая первичная реплика настроена на работу в режиме асинхронной фиксации, то она фиксирует транзакции асинхронно для всех вторичных реплик, независимо от режимов доступности, заданных в каждой из них.If the current primary is configured for asynchronous commit availability mode, it will commit transactions asynchronously for all secondary replicas regardless of their individual availability mode settings.

    Дополнительные сведения см. далее в подразделе Режим доступности с асинхронной фиксациейдалее в этом разделе.For more information, see Asynchronous-Commit Availability Mode, later in this topic.

  • Режим синхронной фиксации отдает предпочтение высокому уровню доступности и защите данных перед производительностью ценой повышенной задержки транзакций.Synchronous-commit mode emphasizes high availability over performance, at the cost of increased transaction latency. В режиме синхронной фиксации транзакции не отправляют клиенту подтверждение, пока вторичная реплика не зафиксирует журнал на диск.Under synchronous-commit mode, transactions wait to send the transaction confirmation to the client until the secondary replica has hardened the log to disk. Когда в базе данных-получателе начинается синхронизация данных, вторичная реплика начинает применять записи журнала, поступающие от соответствующей базы данных-источника.When data synchronization begins on a secondary database, the secondary replica begins applying incoming log records from the corresponding primary database. Сразу после того, как все записи журнала зафиксированы на диск, база данных-получатель переходит в состояние SYNCHRONIZED.As soon as every log record has been hardened, the secondary database enters the SYNCHRONIZED state. После этого каждая новая транзакция фиксируется вторичной репликой перед помещением записи журнала в локальный файл журнала.Thereafter, every new transaction is hardened by the secondary replica before the log record is written to the local log file. Когда все базы данных-получатели данной вторичной реплики синхронизированы, режим синхронной фиксации поддерживает переход на другой ресурс вручную, а также автоматический переход на другой ресурс.When all the secondary databases of a given secondary replica are synchronized, synchronous-commit mode supports manual failover and, optionally, automatic failover.

    Дополнительные сведения см. далее в подразделе Режим доступности с синхронной фиксациейдалее в этом разделе.For more information, see Synchronous-Commit Availability Mode, later in this topic.

  • Режим только конфигурации применяется к группам доступности, которые не находятся на отказоустойчивом кластере Windows Server.Configuration only mode applies to availability groups that are not on a Windows Server Failover Cluster. Реплика в режиме только конфигурации не содержит данных пользователя.A replica in configuration only mode does not contain user data. В этом режиме реплика базы данных master хранит метаданные конфигурации группы доступности.In configuration only mode, the replica master database stores availability group configuration metadata. Дополнительные сведения см. в разделе Группа доступности с репликой только для конфигурации.For more information see Availability group with configuration only replica.

На следующем рисунке показана группа доступности с пятью репликами доступности.The following illustration shows an availability group with five availability replicas. Первичная реплика и одна вторичная реплика настроены в режиме синхронной фиксации с автоматическим переходом на другой ресурс.The primary replica and one secondary replica are configured for synchronous-commit mode with automatic failover. Другая вторичная реплика настроена для синхронной фиксации только с запланированным переходом на другой ресурс вручную, а две вторичные реплики настроены в режиме асинхронной фиксации, который поддерживает только принудительный переход на другой ресурс вручную (обычно называется принудительной отработкой отказа).Another secondary replica is configured for synchronous-commit mode with only planned manual failover, and two secondary replicas are configured for asynchronous-commit mode, which supports only forced manual failover (typically called forced failover).

Режимы доступности и отработки отказа репликAvailability and failover modes of replicas

Синхронизация и отработка отказа между двумя репликами доступности зависит от режима доступности обеих реплик.The synchronization and failover behavior between two availability replicas depends on the availability mode of both replicas. Например, для синхронной фиксации должны быть настроены обе рассматриваемые реплики: и текущая первичная, и вторичная.For example, for synchronous commit to occur, both the current primary replica and the secondary replica in question must be configured for synchronous commit. Аналогично обе реплики должны быть настроены для автоматического перехода на другой ресурс.Likewise, for automatic failover to occur, both replicas need to be configured for automatic failover. Таким образом, сводку поведения для проиллюстрированного сценария развертывания можно показать в следующей таблице, которая анализирует поведение с каждой потенциальной первичной репликой.Therefore, the behavior for the illustrated deployment scenario above can be summarized in the following table, which explores the behavior with each potential primary replica:

Текущая первичная репликаCurrent Primary Replica Целевые объекты автоматического перехода на другой ресурсAutomatic Failover Targets Режим синхронной фиксации с режимомSynchronous-Commit Mode Behavior With Режим асинхронной фиксации с режимомAsynchronous-Commit Mode Behavior With Автоматическая отработка отказа возможнаAutomatic failover possible
0101 0202 02 и 0302 and 03 0404 ДаYes
0202 0101 01 и 0301 and 03 0404 ДаYes
0303 01 и 0201 and 02 0404 нетNo
0404 01, 02 и 0301, 02, and 03 нетNo

Как правило, узел 04 как реплика с асинхронной фиксацией развернут на сайте аварийного восстановления.Typically, Node 04 as an asynchronous-commit replica, is deployed in a disaster recovery site. Тот факт, что узлы 01, 02 и 03 остаются в режиме асинхронной фиксации после перехода на узел 04, помогает предотвратить потенциальное снижение производительности в группе доступности из-за большой задержки в сети между двумя сайтами.The fact that Nodes 01, 02, and 03 remain at asynchronous-commit mode after failing over to Node 04 helps prevent potential performance degradation in your availability group due to high network latency between the two sites.

Asynchronous-Commit Availability ModeAsynchronous-Commit Availability Mode

В режиме асинхронной фиксациивторичная реплика никогда не бывает синхронизирована с первичной репликой.Under asynchronous-commit mode, the secondary replica never becomes synchronized with the primary replica. Хотя данная база данных-получатель может успевать за соответствующей базой данных-источником, любая другая база данных-получатель в любой момент может отставать.Though a given secondary database might catch up to the corresponding primary database, any secondary database could lag behind at any point. Режим асинхронной фиксации полезен для сценария аварийного восстановления, в котором первичная и вторичная реплики находятся на значительном расстоянии друг от друга, и когда необходимо, чтобы на работу первичной реплики не влияли небольшие ошибки. Также подобный режим полезен в тех ситуациях, когда производительность значительно важнее защиты данных, обеспечиваемой синхронной записью изменений.Asynchronous-commit mode can be useful in a disaster-recovery scenario in which the primary replica and the secondary replica are separated by a significant distance and where you do not want small errors to impact the primary replica or in or situations where performance is more important than synchronized data protection. Более того, поскольку первичная реплика не ждет получения подтверждений от вторичной реплики, проблемы на вторичной реплике никогда не сказываются на работе первичной реплики.Furthermore, since the primary replica does not wait for acknowledgements from the secondary replica, problems on the secondary replica never impact the primary replica.

Вторичная реплика асинхронной фиксации пытается соответствовать записям журнала, получаемых от первичной реплики.An asynchronous-commit secondary replica attempts to keep up with the log records received from the primary replica. Однако базы данных-получатели асинхронной фиксации всегда остаются несинхронизированными и могут несколько отставать от соответствующих баз данных-источников.But asynchronous-commit secondary databases always remain unsynchronized and are likely to lag somewhat behind the corresponding primary databases. Как правило, разрыв между базой данных-получателем асинхронной фиксации и соответствующей базой данных-источником незначителен.Typically the gap between an asynchronous-commit secondary database and the corresponding primary database is small. Однако этот разрыв может стать существенным, если сервер, содержащий вторичную реплику, перегружен или у сети низкая пропускная способность.But the gap can become substantial if the server hosting the secondary replica is over loaded or the network is slow.

В режиме асинхронной фиксации поддерживается только принудительная отработка отказа (с возможной потерей данных).The only form of failover supported by asynchronous-commit mode is forced failover (with possible data loss). Принудительная отработка отказа ― это крайняя мера, предназначенная только для таких ситуаций, когда текущая первичная реплика остается недоступной продолжительное время и немедленная доступность баз данных-источников более важна, чем риск возможной потери данных. Целевым объектом отработки отказа должна быть реплика с ролью в состоянии SECONDARY или RESOLVING.Forcing failover is a last resort intended only for situations in which the current primary replica will remain unavailable for an extended period and immediate availability of primary databases is more critical than the risk of possible data loss.The failover target must be a replica whose role is in the SECONDARY or RESOLVING state. Цель отработки отказа принимает первичную роль, а ее копии баз данных станут при этом базами данных-источниками.The failover target transitions to the primary role, and its copies of the databases become the primary database. Все остальные базы данных-получатели и бывшая база данных-источник (как только она вновь становится доступной) приостанавливаются. Затем потребуется ручное возобновление работы каждой из них.Any remaining secondary databases, along with the former primary databases, once they become available, are suspended until you manually resume them individually. В режиме асинхронной фиксации все журналы транзакций, которые первоначальная первичная реплика не отправила вторичной реплике, будут потеряны.Under asynchronous-commit mode, any transaction logs that the original primary replica had not yet sent to the former secondary replica are lost. Это означает, что в некоторых или во всех новых базах данных-источниках могут отсутствовать транзакции, которые были зафиксированы недавно.This means that some or all of the new primary databases might be lacking recently committed transactions. Дополнительные сведения о том, как выполняется принудительная отработка отказа, и об оптимальных методах ее использования см. в статье Отработка отказа и режимы отработки отказа (группы доступности AlwaysOn).For more information on how forced failover works and on best practices for using it, see Failover and Failover Modes (Always On Availability Groups).

Synchronous-Commit Availability ModeSynchronous-Commit Availability Mode

В режиме доступности с синхронной фиксацией (режим синхронной фиксации) после присоединения к группе доступности база данных-получатель синхронизируется с соответствующей базой данных-источником и переходит в состояние SYNCHRONIZED.Under synchronous-commit availability mode (synchronous-commit mode), after being joined to an availability group, a secondary database catches up to the corresponding primary database and enters the SYNCHRONIZED state. База данных-получатель остается в состоянии SYNCHRONIZED, пока продолжается синхронизация данных.The secondary database remains SYNCHRONIZED as long as data synchronization continues. Это гарантирует, что все транзакции, зафиксированные в данной базе данных-источнике, также будут зафиксированы в соответствующей базе данных-получателе.This guarantees that every transaction that is committed on a given primary database has also been committed on the corresponding secondary database. Когда все базы данных-получатели данной вторичной реплики синхронизированы, вторичная реплика имеет общее состояние работоспособности синхронизации HEALTHY.When every secondary database on a given secondary replica is synchronized, the synchronization-health state of the secondary replica as a whole is HEALTHY.

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

Факторы, нарушающие синхронизацию данныхFactors That Disrupt Data Synchronization

После синхронизации всех баз данных вторичная реплика переходит в состояние HEALTHY.Once all of its databases are synchronized, a secondary replica enters the HEALTHY state. Синхронизированная вторичная реплика остается в исправном состоянии, если не происходят никакие из следующих событий.The synchronized secondary replica will remain healthy unless one of the following occurs:

  • Задержка или сбой сети или компьютера вызывает истечение времени ожидания сеанса между вторичной и первичной репликами.A network or computer delay or glitch causes the session between the secondary replica and primary replica to timeout.

    Примечание

    Сведения о свойстве ожидания сеанса для реплик доступности см. в статье Обзор групп доступности AlwaysOn (SQL Server).For information about the session-time property of availability replicas, see Overview of Always On Availability Groups (SQL Server).

  • Пользователь приостанавливает базу данных-получатель на вторичной реплике.You suspend a secondary database on the secondary replica. Вторичная реплика теряет синхронизацию и переходит в состояние работоспособности синхронизации NOT_HEALTHY.The secondary replica ceases to be synchronized, and its synchronization-health state is marked as NOT_HEALTHY. Вторичная реплика не становится вновь исправной, пока работа приостановленной базы данных-получателя не будет возобновлена и синхронизирована повторно либо удалена из группы доступности.the secondary replica cannot become healthy again until the suspended secondary database is either resumed and resynchronized or removed from the availability group.

  • В группу доступности добавляется база данных-источник.You add a primary database the availability group. Ранее синхронизированные вторичные реплики переходят в состояние работоспособности синхронизации NOT_HEALTHY.Previously synchronized secondary replicas enter the NOT_HEALTHY synchronization-health state. Это состояние показывает, что по крайней мере одна база данных находится в состоянии синхронизации NOT SYNCHRONIZING.This state indicates that at least one database is in the NOT SYNCHRONIZING synchronization state. Данная вторичная реплика может вернуться в состояние HEALTHY только после того, как соответствующая база данных-получатель будет подготовлена в реплике, присоединена к группе доступности и синхронизирована с новой базой данных-источником.A given secondary replica cannot be HEALTHY again until a corresponding secondary database has been prepared on the replica, has been joined to the availability group, and has become synchronized with the new primary database.

  • Пользователь устанавливает для первичной или вторичной реплики режим доступности с асинхронной фиксацией.You change the primary replica or the secondary replica to asynchronous-commit availability mode. После перехода в режим асинхронной фиксации вторичная реплика будет оставаться в состоянии работоспособности синхронизации HEALTHY, пока продолжается синхронизация данных.After changing to asynchronous-commit mode, the secondary replica will remain in the HEALTHY synchronization-health state as long as data synchronization continues. Однако если только первичная реплика переходит в режим асинхронной фиксации, то вторичная реплика синхронной фиксации переходит в состояние работоспособности синхронизации PARTIALLY_HEALTHY.However, if only the primary replica is changed to asynchronous-commit mode, the synchronous-commit secondary replica will enter the PARTIALLY_HEALTHY synchronization-health state. Это состояние показывает, что по крайней мере одна база данных находится в состоянии синхронизации SYNCHRONIZING, но ни одна из баз данных не находится в состоянии NOT SYNCHRONIZING.This state indicates that at least one database is in the SYNCHRONIZING synchronization state, but none of the databases are in the NOT SYNCHRONIZING state.

  • Режим доступности какой-либо вторичной реплики изменяется на режим с синхронной фиксацией.You change any secondary replica to synchronous-commit availability mode. В результате вторичная реплика помечается состоянием работоспособности синхронизации PARTIALLY_HEALTHYThis causes that secondary replica to be marked as in the PARTIALLY_HEALTHY synchronization-health state. до тех пор, пока все ее базы данных не перейдут в состояние синхронизации SYNCHRONIZED.until all of its databases are in the SYNCHRONIZED synchronization state.

Совет

Для просмотра работоспособности синхронизации группы доступности, реплики доступности или базы данных доступности выполните запрос столбца synchronization_health или synchronization_health_desc из sys.dm_hadr_availability_group_states, sys.dm_hadr_availability_replica_statesили sys.dm_hadr_database_replica_statesсоответственно.To view the synchronization health of an availability group, availability replica, or availability database, query the synchronization_health or synchronization_health_desc column of sys.dm_hadr_availability_group_states, sys.dm_hadr_availability_replica_states, or sys.dm_hadr_database_replica_states, respectively.

Как синхронизация работает на вторичной репликеHow Synchronization Works on a Secondary Replica

В режиме с синхронной фиксацией, после того как вторичная реплика присоединяется к группе доступности и устанавливает сеанс с первичной репликой, вторичная реплика сохраняет поступающие записи журнала на диск (фиксирует журнал на диск) и отправляет сообщение с подтверждением первичной реплике.Under the synchronous-commit mode, after a secondary replica joins the availability group and establishes a session with the primary replica, the secondary replica writes incoming log records to disk (hardens the log) and sends a confirmation message to the primary replica. После того как фиксированный журнал в базе данных-получателе достигает конца журнала в базе данных-источнике, база данных-получатель переходит в состояние SYNCHRONIZED.Once the hardened log on the secondary database has caught up the end of log on the primary database, the state of the secondary database is set to SYNCHRONIZED. Время, необходимое для выполнения синхронизации, зависит главным образом от того, насколько база данных-получатель отстала от базы данных-источника в начале сеанса (отставание измеряется числом записей журнала, первоначально полученных от первичной реплики), от рабочей нагрузки на базу данных-источник и от быстродействия компьютера, на котором находится экземпляр сервера, где размещена вторичная реплика.The time required for synchronization depends essentially on how far the secondary database was behind the primary database at the start of the session (measured by the number of log records initially received from the primary replica), the work load on the primary database, and the speed of the computer of the server instance that hosts the secondary replica.

Синхронность операции достигается следующим образом.Synchronous operation is maintained in the following manner:

  1. Получив транзакцию от клиента, первичная реплика помещает запись в журнал транзакции и одновременно отправляет запись журнала во вторичные реплики.On receiving a transaction from a client, the primary replica writes the log for the transaction to the transaction log and concurrently sends the log record to the secondary replicas.

  2. После помещения записи в журнал транзакций базы данных-источника транзакцию можно отменить, только если в этот момент происходит переход на базу данных-получатель, которая не получила журнал.Once a log record is written to the transaction log of the primary database, the transaction can be undone only if there is a failover at this point to a secondary that did not receive the log. Первичная реплика ожидает подтверждения от вторичной реплики синхронной фиксации.The primary replica waits for confirmation from the synchronous-commit secondary replica.

  3. Вторичная реплика фиксирует журнал на диск и возвращает подтверждение первичной реплике.The secondary replica hardens the log and returns an acknowledgement to the primary replica.

  4. Получив подтверждение от вторичной реплики, первичная реплика завершает обработку фиксации и отправляет клиенту сообщение с подтверждением.On receiving the confirmation from the secondary replica, the primary replica finishes the commit processing and sends a confirmation message to the client.

    Примечание

    Если во вторичной реплике, работающей в режиме синхронной фиксации, истекает время ожидания без подтверждения фиксации журнала, то первичная реплика помечает вторичную как сбойную.If a synchronous-commit secondary replica times out without confirming that it has hardened the log, the primary marks that secondary replica as failed. Состояние подключения вторичной реплики меняется на DISCONNECTED, и первичная реплика прекращает ожидание подтверждения от вторичной реплики.The connected state of the secondary replica changes to DISCONNECTED, and the primary replica stops waiting for confirmation from the secondary replica. Это позволяет избежать ситуации, в которой сбойная вторичная реплика синхронной фиксации препятствует фиксации журнала транзакций в первичной реплике.This behavior ensures that a failed synchronous-commit secondary replica does not prevent hardening of the transaction log on the primary replica.

Режим с синхронной фиксацией защищает данные за счет того, что требует их синхронизации между двумя экземплярами. Делается это за счет некоторого увеличения задержки транзакции.Synchronous-commit mode protects your data by requiring the data to be synchronized between two places, at the cost of somewhat increasing the latency of the transaction.

Режим синхронной фиксации только с переходом на другой ресурс вручнуюSynchronous-Commit Mode with Only Manual Failover

Если между этими репликами имеется подключение и база данных синхронизирована, то поддерживается переход на другой ресурс вручную.When these replicas are connected and the database is synchronized, manual failover is supported. Если работа вторичной реплики нарушается, то это никак не сказывается на первичной реплике.If the secondary replica goes down, the primary replica is unaffected. Первичная реплика не защищена, если ни одна реплика не находится в состоянии SYNCHRONIZED (то есть когда она не отправляет данные ни одной вторичной реплике).The primary replica runs exposed if no SYNCHRONIZED replicas exist (that is, without sending data to any secondary replica). Если работа первичной реплики нарушается, вторичные реплики переходят в состояние RESOLVING, но владелец базы данных может принудительно выполнить отработку отказа на вторую реплику (с возможной потерей данных).If the primary replica is lost, the secondary replicas enter the RESOLVING state, but the database owner can force a failover to the secondary replica (with possible data loss). Дополнительные сведения см. далее в подразделе Отработка отказа и режимы отработки отказа (группы доступности AlwaysOn).For more information, see Failover and Failover Modes (Always On Availability Groups).

Режим синхронной фиксации с автоматическим переходом на другой ресурсSynchronous-Commit Mode with Automatic Failover

Автоматический переход на другой ресурс обеспечивает высокий уровень доступности за счет того, что доступ к базам данных быстро восстанавливается после потери первичной реплики.Automatic failover provides high availability by ensuring that the database is quickly made available again after the loss of the primary replica. Чтобы настроить группу доступности для автоматического перехода на другой ресурс, нужно задать для текущей первичной реплики и хотя бы одной вторичной реплики режим синхронной фиксации с автоматическим переходом на другой ресурс.To configure an availability group for automatic failover, you need to set both the current primary replica and at least one secondary replica to synchronous-commit mode with automatic failover. Можно иметь до трех реплик автоматического перехода на другой ресурс.You can have up to three automatic failover replicas.

Кроме того, для автоматического перехода на другой ресурс в заданный момент вторичная реплика должна быть синхронизирована с первичной репликой (это значит, что все базы данных-получатели синхронизированы), а кластер WSFC должен иметь кворум.Furthermore, for an automatic failover to be possible at a given time, this secondary replica must be synchronized with the primary replica (that is, the secondary databases are all synchronized), and the Windows Server Failover Clustering (WSFC) cluster must have quorum. Если первичная реплика становится недоступной при описанных выше условиях, происходит автоматический переход на другой ресурс.If the primary replica becomes unavailable under these conditions, automatic failover occurs. Вторичная реплика переключается в роль первичной и предлагает свои базы данных как базы данных-источники.The secondary replica switches to the role of primary, and it offers its database as the primary database. Дополнительные сведения об автоматической отработке отказа см. в статье Отработка отказа и режимы отработки отказа (группы доступности AlwaysOn).For more information, see the "Automatic Failover " section of the Failover and Failover Modes (Always On Availability Groups) topic.

Примечание

Дополнительные сведения о кворуме WSFC и Группы доступности AlwaysOnAlways On availability groups см. в статье Режимы кворума и конфигурация голосования WSFC (SQL Server).For information about WSFC quorum and Группы доступности AlwaysOnAlways On availability groups, see For more information, see WSFC Quorum Modes and Voting Configuration (SQL Server).

Задержка данных на вторичной репликеData latency on secondary replica

Применение доступа только для чтения ко вторичным репликам полезно, если для нагрузок, связанных с операциями с ними, приемлема некоторая задержка данных.Implementing read-only access to secondary replicas is useful if your read-only workloads can tolerate some data latency. В ситуациях, когда задержка данных неприемлема, рассмотрите возможность выполнения рабочих нагрузок только чтения за счет первичной реплики.In situations where data latency is unacceptable, consider running read-only workloads against the primary replica.

Из основной реплики выполняется отправка журнала изменений в базе данных-источнике на вторичные реплики.The primary replica sends log records of changes on primary database to the secondary replicas. На каждой базе данных-получателе выделенный поток повтора применяет записи журнала.On each secondary database, a dedicated redo thread applies the log records. В базе данных, доступной для чтения, изменение данных не появляется среди результатов запроса до тех пор, пока запись журнала о данном изменении не будет применена к базе данных-получателю, а транзакция не будет зафиксирована в базе данных-источнике.+On a read-access secondary database, a given data change does not appear in query results until the log record that contains the change has been applied to the secondary database and the transaction has been committed on primary database.+

Это означает, что между первичной и вторичной репликами возникает некоторая задержка, обычно порядка нескольких секунд.This means that there is some latency, usually only a matter of seconds, between the primary and secondary replicas. В нетипичных случаях, например в ситуации, когда проблемы с сетью ухудшают пропускную способность, задержка может стать значительной.In unusual cases, however, for example if network issues reduce throughput, latency can become significant. Задержка увеличивается из-за наличия узких мест в системе ввода-вывода и в результате приостановки движения данных.Latency increases when I/O bottlenecks occur and when data movement is suspended. Для отслеживания приостановок перемещения данных можно использовать Панель управления AlwaysOn или динамическое административное представление sys.dm_hadr_database_replica_states.To monitor suspended data movement, you can use the Always On Dashboard or the sys.dm_hadr_database_replica_states dynamic management view.

Дополнительные сведения об изучении задержки повтора на вторичной реплике см. в разделе Устранение неполадок при отсутствии повтора изменений в источнике на вторичной реплике.For more information on investigating redo latency on the secondary replica, please see Troubleshoot primary changes not reflected on secondary replica.

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

Изменение режима доступности и режима отработки отказаTo change the availability mode and failover mode

Настройка голосов кворумаTo adjust quorum votes

Отработки отказа вручнуюTo perform a manual failover

Просмотр состояний групп доступности, реплик доступности и баз данныхTo view availability group, availability replica, and database states

См. такжеRelated Content

См. также:See Also

Обзор групп доступности AlwaysOn (SQL Server) Overview of Always On Availability Groups (SQL Server)
Отработка отказа и режимы отработки отказа (группы доступности AlwaysOn) Failover and Failover Modes (Always On Availability Groups)
Отказоустойчивая кластеризация Windows Server (WSFC) с SQL ServerWindows Server Failover Clustering (WSFC) with SQL Server