Diferencias entre los modos de disponibilidad para un grupo de disponibilidad Always OnDifferences between availability modes for an Always On availability group

SE APLICA A: síSQL Server noAzure SQL Database noAzure Synapse Analytics (SQL DW) noAlmacenamiento de datos paralelos APPLIES TO: yesSQL Server noAzure SQL Database noAzure Synapse Analytics (SQL DW) noParallel Data Warehouse

En Grupos de disponibilidad AlwaysOnAlways On availability groups, el modo de disponibilidad es una propiedad de réplica que determina si una réplica de disponibilidad determinada puede ejecutarse en modo de confirmación sincrónica.In Grupos de disponibilidad AlwaysOnAlways On availability groups, the availability mode is a replica property that determines whether a given availability replica can run in synchronous-commit mode. En cada réplica de disponibilidad se debe configurar el modo de disponibilidad para el modo de confirmación sincrónica, el modo de confirmación asincrónica o el modo de solo configuración.For each availability replica, the availability mode must be configured for either synchronous-commit mode, asynchronous-commit, or configuration only mode. Si la réplica principal se configura para el modo de confirmación asincrónica, no espera a que ninguna réplica secundaria escriba las entradas del registro de transacciones entrantes en el disco ( se fortalece el registro).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). Si una réplica secundaria dada se configura para el modo de confirmación asincrónica, la réplica principal no espera a que esa réplica secundaria proteja el registro.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. Si la réplica principal y una réplica secundaria determinada se configuran ambas para el modo de confirmación sincrónica, la réplica principal espera a que la réplica secundaria confirme que ha reforzado el registro (a menos que la réplica secundaria no pueda hacer ping a la réplica principal en el período de tiempo de espera de sesiónde la principal).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).

Nota

Si el período de tiempo de espera de sesión de la réplica principal es superado por una réplica secundaria, la replicación principal pasa temporalmente al modo de confirmación asincrónicoa para esa replicación secundaria.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. Cuando la replicación secundaria vuelva a conectarse con la replicación primaria, se reanuda el modo de confirmación sincrónica.When the secondary replica reconnects with the primary replica, they resume synchronous-commit mode.

Modos de disponibilidad admitidosSupported Availability Modes

Grupos de disponibilidad AlwaysOnAlways On availability groups admite tres modos de disponibilidad: el modo de confirmación asincrónica, el modo de confirmación sincrónica y el modo de solo configuración, como se indica a continuación:supports three availability modes-asynchronous-commit mode, synchronous-commit mode, and configuration only mode as follows:

  • Modo de confirmación asincrónica es una solución de recuperación ante desastres que funciona bien cuando las réplicas de disponibilidad se distribuyen a distancias considerables.Asynchronous-commit mode is a disaster-recovery solution that works well when the availability replicas are distributed over considerable distances. Si cada réplica secundaria se está ejecutando en modo de confirmación asincrónica, la réplica principal no espera ninguna réplica secundaria para proteger el registro.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. En su lugar, inmediatamente después de escribir el registro en el archivo de registro local, la réplica principal envía la confirmación de la transacción al cliente.Rather, immediately after writing the log record to the local log file, the primary replica sends the transaction confirmation to the client. La réplica principal se ejecuta con la mínima latencia de transacciones respecto a una réplica secundaria que se configura para el modo de confirmación asincrónica.The primary replica runs with minimum transaction latency in relation to a secondary replica that is configured for asynchronous-commit mode. Si la principal actual se configura para el modo de disponibilidad de confirmación asincrónica, confirmará las transacciones de forma asincrónica para todas las réplicas secundarias independientemente de su configuración del modo de disponibilidad individual.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.

    Para obtener más información, vea Modo de disponibilidad de confirmación asincrónica, más adelante en este tema.For more information, see Asynchronous-Commit Availability Mode, later in this topic.

  • Elmodo de confirmación sincrónica establece prioridades de alta disponibilidad sobre el rendimiento, pero a costa de aumentar la latencia de las transacciones.Synchronous-commit mode emphasizes high availability over performance, at the cost of increased transaction latency. En modo de confirmación sincrónica, las transacciones esperan a enviar la confirmación de transacción al cliente hasta que la réplica secundaria ha protegido el registro en el disco.Under synchronous-commit mode, transactions wait to send the transaction confirmation to the client until the secondary replica has hardened the log to disk. Cuando la sincronización de datos comienza en una base de datos secundaria, la réplica secundaria comienza a aplicar los registros entrantes desde la base de datos principal correspondiente.When data synchronization begins on a secondary database, the secondary replica begins applying incoming log records from the corresponding primary database. En cuanto se protege cada entrada del registro, la base de datos secundaria entra en el estado de SYNCHRONIZED.As soon as every log record has been hardened, the secondary database enters the SYNCHRONIZED state. Después, la réplica secundaria protege cada nueva transacción antes de que se escriba la entrada de registro en el archivo de registro local.Thereafter, every new transaction is hardened by the secondary replica before the log record is written to the local log file. Cuando todas las bases de datos secundarias de una réplica secundaria se sincronizan, el modo de confirmación sincrónica admite la conmutación por error manual y, opcionalmente, la conmutación automática por error.When all the secondary databases of a given secondary replica are synchronized, synchronous-commit mode supports manual failover and, optionally, automatic failover.

    Para obtener más información, vea Modo de disponibilidad de confirmación sincrónica, más adelante en este tema.For more information, see Synchronous-Commit Availability Mode, later in this topic.

  • El modo de solo configuración se aplica a los grupos de disponibilidad que no están en un clúster de conmutación por error de Windows Server.Configuration only mode applies to availability groups that are not on a Windows Server Failover Cluster. Una réplica en modo de solo configuración no contiene datos de usuario.A replica in configuration only mode does not contain user data. En el modo de solo configuración, la base de datos maestra de la réplica almacena metadatos de configuración del grupo de disponibilidad.In configuration only mode, the replica master database stores availability group configuration metadata. Para más información, vea Availability group with configuration only replica (Grupo de disponibilidad con réplica de solo configuración).For more information see Availability group with configuration only replica.

En la ilustración siguiente se muestra un grupo de disponibilidad con cinco réplicas de disponibilidad.The following illustration shows an availability group with five availability replicas. La réplica principal y una réplica secundaria se configuran para el modo de confirmación sincrónica con conmutación automática por error.The primary replica and one secondary replica are configured for synchronous-commit mode with automatic failover. Se configura otra réplica secundaria para el modo de confirmación sincrónica con conmutación por error manual planeada únicamente y se configuran dos réplicas secundarias para el modo de confirmación asincrónica, que solo admite la conmutación por error manual forzada (denominada normalmente conmutación por error forzada).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).

Modos de disponibilidad y conmutación por error de las réplicasAvailability and failover modes of replicas

El comportamiento de sincronización y de conmutación por error entre dos réplicas de disponibilidad depende del modo de disponibilidad de ambas réplicas.The synchronization and failover behavior between two availability replicas depends on the availability mode of both replicas. Por ejemplo, para que tenga lugar la confirmación sincrónica, la réplica principal actual y la réplica secundaria en cuestión se debe configurar para la confirmación sincrónica.For example, for synchronous commit to occur, both the current primary replica and the secondary replica in question must be configured for synchronous commit. Asimismo, para que se produzca la conmutación por error automática, ambas réplicas deben configurarse para la conmutación automática por error.Likewise, for automatic failover to occur, both replicas need to be configured for automatic failover. Por lo tanto, el comportamiento para el escenario de implementación mostrado anteriormente se puede resumir en la tabla siguiente, en la que se explora el comportamiento con cada réplica principal potencial: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:

Réplica principal actualCurrent Primary Replica Destinos de conmutación por error automáticaAutomatic Failover Targets Comportamiento de modo de confirmación sincrónica conSynchronous-Commit Mode Behavior With Comportamiento de modo de confirmación asincrónica conAsynchronous-Commit Mode Behavior With Conmutación por error automática posibleAutomatic failover possible
0101 0202 02 y 0302 and 03 0404 Yes
0202 0101 01 y 0301 and 03 0404 Yes
0303 01 y 0201 and 02 0404 NoNo
0404 01, 02 y 0301, 02, and 03 NoNo

Normalmente, el nodo 04 como réplica de confirmación asincrónica, se implementa en un sitio de recuperación ante desastres.Typically, Node 04 as an asynchronous-commit replica, is deployed in a disaster recovery site. El hecho de que los nodos 01, 02, 03 se mantengan en el modo de confirmación asincrónica después de conmutar por error al nodo 04 ayuda a evitar la degradación del rendimiento potencial en el grupo de disponibilidad debido a la alta latencia de red entre los dos sitios.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

En el modo de confirmación asincrónica, la réplica secundaria nunca se sincroniza con la réplica principal.Under asynchronous-commit mode, the secondary replica never becomes synchronized with the primary replica. Aunque una base de datos secundaria puede tener acceso a la base de datos principal correspondiente, cualquier base de datos secundaria podría retrasarse en cualquier momento.Though a given secondary database might catch up to the corresponding primary database, any secondary database could lag behind at any point. El modo de confirmación asincrónica puede resultar útil en un escenario de recuperación de desastres en el que la réplica principal y la réplica secundaria están separadas por una distancia significativa, y donde no se desean errores pequeños que puedan afectar a la réplica principal, o en situaciones donde es más importante el rendimiento que la protección de los datos sincronizados.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. Además, puesto que la réplica principal no espera reconocimientos de la réplica secundaria, los problemas de la réplica secundaria nunca afectan a la réplica principal.Furthermore, since the primary replica does not wait for acknowledgements from the secondary replica, problems on the secondary replica never impact the primary replica.

Una réplica secundaria de confirmación asincrónica intenta hacer frente a las entradas de registro recibidas de la réplica principal.An asynchronous-commit secondary replica attempts to keep up with the log records received from the primary replica. Pero en modo de confirmación asincrónica, las bases de datos secundarias permanecen sin sincronizar y es más probable que se retrasen detrás las bases de datos principales.But asynchronous-commit secondary databases always remain unsynchronized and are likely to lag somewhat behind the corresponding primary databases. Normalmente, la diferencia entre una base de datos secundaria de confirmación asincrónica y la base de datos principal correspondiente es pequeña.Typically the gap between an asynchronous-commit secondary database and the corresponding primary database is small. Pero la diferencia puede ser considerable si el servidor que hospeda la replicación secundaria está sobrecargado o la red es lenta.But the gap can become substantial if the server hosting the secondary replica is over loaded or the network is slow.

El único formato de conmutación por error que admite el modo de confirmación asincrónica es conmutación por error forzada (con posible pérdida de datos).The only form of failover supported by asynchronous-commit mode is forced failover (with possible data loss). Forzar la conmutación es un último recurso destinado únicamente para situaciones en las que la réplica principal actual permanece disponible durante un período prolongado y la disponibilidad inmediata de las bases de datos principales es más importante que el riesgo de posibles pérdidas de datos. El destino de la conmutación por error debe ser una réplica cuyo rol esté en el estado SECONDARY o 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. El destino de la conmutación por error asume el rol principal y sus copias de las bases de datos se convierten en la base de datos principal.The failover target transitions to the primary role, and its copies of the databases become the primary database. Cualquier base de datos secundaria restante, junto con las bases de datos principales anteriores, una vez que estén disponibles, se suspende hasta que se reanuden de forma manual e individualmente.Any remaining secondary databases, along with the former primary databases, once they become available, are suspended until you manually resume them individually. En el modo de confirmación asincrónica, se pierde cualquier registro de transacciones que la replicación principal original no hubiera enviado a la replicación secundaria anterior.Under asynchronous-commit mode, any transaction logs that the original primary replica had not yet sent to the former secondary replica are lost. Esto significa que algunas o todas las nuevas bases de datos principales podrían carecer de las transacciones confirmadas recientemente.This means that some or all of the new primary databases might be lacking recently committed transactions. Para obtener más información sobre el funcionamiento de la conmutación por error forzada y los procedimientos recomendados para usarla, vea Conmutación por error y modos de conmutación por error (grupos de disponibilidad 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

En modo de disponibilidad de confirmación sincrónica (modo de confirmación sincrónica), al unirse a un grupo de disponibilidad, una base de datos secundaria se pone al mismo nivel que la base de datos principal correspondiente y entra en el estado 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. Las bases de datos secundarias permanecen en ese estado mientras continúa la sincronización de datos.The secondary database remains SYNCHRONIZED as long as data synchronization continues. Esto garantiza que cada transacción confirmada en la base de datos principal dada también se ha confirmado en la nueva base de datos secundaria correspondiente.This guarantees that every transaction that is committed on a given primary database has also been committed on the corresponding secondary database. Cuando se sincroniza cada base de datos secundaria de una réplica secundaria determinada, el estado de sincronización de dicha réplica en su conjunto es 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.

En esta sección:In This Section:

Factores que interrumpen la sincronización de datosFactors That Disrupt Data Synchronization

Una vez que todas las bases de datos están sincronizadas, la réplica secundaria entra en el estado HEALTHY.Once all of its databases are synchronized, a secondary replica enters the HEALTHY state. La réplica secundaria sincronizada permanecerá en este estado a menos que ocurra lo siguiente:The synchronized secondary replica will remain healthy unless one of the following occurs:

  • Un retraso de la red o del equipo o, o una interferencia provoca que se agote el tiempo de espera de la sesión entre la réplica secundaria y la réplica principal.A network or computer delay or glitch causes the session between the secondary replica and primary replica to timeout.

    Nota

    Para obtener más información sobre la propiedad session-time de las réplicas de disponibilidad, vea Información general de los grupos de disponibilidad AlwaysOn (SQL Server).For information about the session-time property of availability replicas, see Overview of Always On Availability Groups (SQL Server).

  • Se suspende una base de datos secundaria en la réplica secundaria.You suspend a secondary database on the secondary replica. La réplica secundaria deja de estar sincronizada y su estado de sincronización se marca como NOT_HEALTHY.The secondary replica ceases to be synchronized, and its synchronization-health state is marked as NOT_HEALTHY. La réplica secundaria no puede entrar de nuevo en el estado HEALTHY hasta que la base de datos secundaria suspendida se pospone y se vuelve a sincronizar, o se quita del grupo de disponibilidad.the secondary replica cannot become healthy again until the suspended secondary database is either resumed and resynchronized or removed from the availability group.

  • Agrega una base de datos principal al grupo de disponibilidad.You add a primary database the availability group. Las réplicas secundarias previamente sincronizadas entran en el estado de sincronización NOT_HEALTHY.Previously synchronized secondary replicas enter the NOT_HEALTHY synchronization-health state. Este estado indica que al menos una base de datos tiene el estado de sincronización NOT SYNCHRONIZING.This state indicates that at least one database is in the NOT SYNCHRONIZING synchronization state. Una réplica secundaria determinada no puede volver a tener el estado HEALTHY hasta que una base de datos secundaria correspondiente se ha preparado en la réplica, se ha unido al grupo de disponibilidad y se ha sincronizado con la nueva base de datos principal.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.

  • Cambia la réplica principal o la réplica secundaria al modo de disponibilidad de confirmación asincrónica.You change the primary replica or the secondary replica to asynchronous-commit availability mode. Después de cambiar al modo de confirmación asincrónica, la réplica secundaria permanecerá en el estado HEALTHY mientras continúe la sincronización de datos.After changing to asynchronous-commit mode, the secondary replica will remain in the HEALTHY synchronization-health state as long as data synchronization continues. Sin embargo, si solo se cambia la réplica principal al modo de confirmación asincrónica, la réplica secundaria en modo de confirmación sincrónica entrará en el estado de sincronización 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. Este estado indica que al menos una base de datos tiene el estado de sincronización SYNCHRONIZING, pero que ninguna de las bases de datos tiene el estado 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.

  • Cambia cualquier réplica secundaria al modo de disponibilidad de confirmación sincrónica.You change any secondary replica to synchronous-commit availability mode. Esto hace que réplica secundaria se marque con un estado de sincronización PARTIALLY_HEALTHY.This causes that secondary replica to be marked as in the PARTIALLY_HEALTHY synchronization-health state. hasta que todas sus bases de datos tengan el estado de sincronización SYNCHRONIZED.until all of its databases are in the SYNCHRONIZED synchronization state.

Sugerencia

Para ver el estado de sincronización de un grupo de disponibilidad, una réplica de disponibilidad o una base de datos de disponibilidad, consulte las columnas synchronization_health o synchronization_health_desc de sys.dm_hadr_availability_group_states, sys.dm_hadr_availability_replica_stateso sys.dm_hadr_database_replica_states, respectivamente.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.

Cómo funciona la sincronización en una réplica secundariaHow Synchronization Works on a Secondary Replica

En modo de confirmación sincrónica, después de que una réplica secundaria se una al grupo de disponibilidad y establezca una sesión con la réplica principal, la réplica secundaria escribe las entradas de registro entrantes en el disco (protege el registro) y envía un mensaje de confirmación a la réplica principal.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. Una vez que el registro protegido de la base de datos secundaria llega al final del registro de la base de datos principal, el estado de la base de datos secundaria se establece en 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. El tiempo necesario para la sincronización depende básicamente de la diferencia entre la base de datos secundaria y la base de datos principal en el momento de iniciar la sesión (diferencia calculada por el número de registros inicialmente recibidos de la réplica principal), la carga de trabajo en la base de datos principal y la velocidad del equipo de la instancia del servidor que hospeda la réplica secundaria.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.

La operación sincrónica se mantiene de la siguiente manera:Synchronous operation is maintained in the following manner:

  1. Al recibir una transacción de un cliente, la réplica principal escribe el registro de la transacción en el registro de transacciones y envía simultáneamente la entrada del registro a las réplicas secundarias.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. Una vez que se ha escrito la entrada de registro en el registro de transacciones de la base de datos principal, la transacción solo se puede deshacer si se produce una conmutación por error en ese momento a una base de datos secundaria que no ha recibido el registro.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. La réplica principal espera la confirmación de la réplica secundaria de confirmación sincrónica.The primary replica waits for confirmation from the synchronous-commit secondary replica.

  3. La réplica secundaria protege el registro y devuelve una confirmación a la réplica principal.The secondary replica hardens the log and returns an acknowledgement to the primary replica.

  4. Al recibir la confirmación de la réplica secundaria, la réplica principal finaliza el proceso de confirmación y envía un mensaje de confirmación al cliente.On receiving the confirmation from the secondary replica, the primary replica finishes the commit processing and sends a confirmation message to the client.

    Nota

    Si se agota el tiempo de espera de una réplica secundaria de confirmación sincrónica sin confirmar que se ha protegido el registro, la principal marca las réplicas secundarias como error.If a synchronous-commit secondary replica times out without confirming that it has hardened the log, the primary marks that secondary replica as failed. El estado conectado de la réplica secundaria cambia a DISCONNECTED, y la réplica principal deja de esperar la confirmación de la réplica secundaria.The connected state of the secondary replica changes to DISCONNECTED, and the primary replica stops waiting for confirmation from the secondary replica. Este comportamiento garantiza que una réplica secundaria de confirmación sincrónica no impida que se proteja el registro de transacciones de la réplica principal.This behavior ensures that a failed synchronous-commit secondary replica does not prevent hardening of the transaction log on the primary replica.

El modo de confirmación sincrónica protege los datos exigiendo que estos estén sincronizados entre dos lugares, a costa de un ligero aumento de la latencia de las transacciones.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.

Modo de confirmación sincrónica con modo de conmutación por error manualSynchronous-Commit Mode with Only Manual Failover

Cuando estas réplicas están conectadas y la base de datos está sincronizada, se admite la conmutación por error manual.When these replicas are connected and the database is synchronized, manual failover is supported. Si la réplica secundaria baja un nivel, la réplica principal no se ve afectada.If the secondary replica goes down, the primary replica is unaffected. La réplica principal se ejecuta expuesta si no existen réplicas SYNCHRONIZED (es decir, sin enviar datos a ninguna réplica secundaria).The primary replica runs exposed if no SYNCHRONIZED replicas exist (that is, without sending data to any secondary replica). Si se pierde la réplica principal, las réplicas secundarias entran en el estado RESOLVING, pero el propietario de la base de datos puede forzar una conmutación por error a la réplica secundaria (con posible pérdida de datos).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). Para obtener más información, vea Conmutación por error y modos de conmutación por error (Grupos de disponibilidad AlwaysOn).For more information, see Failover and Failover Modes (Always On Availability Groups).

Modo de confirmación sincrónica con conmutación automática por errorSynchronous-Commit Mode with Automatic Failover

La conmutación automática por error proporciona alta disponibilidad al asegurar que la base de datos estará de nuevo disponible rápidamente después de la pérdida de la réplica principal.Automatic failover provides high availability by ensuring that the database is quickly made available again after the loss of the primary replica. Para configurar un grupo de disponibilidad para la conmutación automática por error, debe establecer la réplica principal actual y al menos una réplica secundaria en el modo de confirmación sincrónica con conmutación automática por error.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. Puede tener hasta tres réplicas de conmutación por error automática.You can have up to three automatic failover replicas.

Además, para que la conmutación automática por error sea posible en un momento dado, esta réplica secundaria se debe sincronizar con la réplica principal (es decir, todas las bases de datos secundarias están sincronizadas), y los clústeres de conmutación por error de Windows Server (WSFC) deben tener quórum.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. Si la réplica principal no está disponible en estas condiciones, se produce la conmutación automática por error.If the primary replica becomes unavailable under these conditions, automatic failover occurs. La réplica secundaria cambia al rol de principal y ofrece su base de datos como la base de datos principal.The secondary replica switches to the role of primary, and it offers its database as the primary database. Para obtener más información, vea la sección "Conmutación automática por error" del tema Conmutación por error y modos de conmutación por error (Grupos de disponibilidad AlwaysOn).For more information, see the "Automatic Failover " section of the Failover and Failover Modes (Always On Availability Groups) topic.

Nota

Para obtener más información sobre el cuórum WSFC y Grupos de disponibilidad AlwaysOnAlways On availability groups, vea Configuración de los votos y modos de cuórum WSFC (SQL Server).For information about WSFC quorum and Grupos de disponibilidad AlwaysOnAlways On availability groups, see For more information, see WSFC Quorum Modes and Voting Configuration (SQL Server).

Latencia de datos en la réplica secundariaData latency on secondary replica

La implementación del acceso de solo lectura en las réplicas secundarias resulta útil si las cargas de trabajo de solo lectura pueden tolerar cierta latencia de datos.Implementing read-only access to secondary replicas is useful if your read-only workloads can tolerate some data latency. En las situaciones en las que la latencia de datos no es aceptable, considere la posibilidad de ejecutar cargas de trabajo de solo lectura en la réplica principal.In situations where data latency is unacceptable, consider running read-only workloads against the primary replica.

La réplica principal envía las entradas de registro de los cambios en la base de datos principal a las réplicas secundarias.The primary replica sends log records of changes on primary database to the secondary replicas. En cada base de datos secundaria, un subproceso de rehacer dedicado aplica las entradas de registro.On each secondary database, a dedicated redo thread applies the log records. En una base de datos secundaria de acceso de lectura, un cambio determinado de datos no aparece en los resultados de la consulta hasta que la entrada del registro que contiene el cambio se haya aplicado a la base de datos secundaria y la transacción se haya confirmado en la base de datos principal.+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.+

Esto significa que hay latencia, normalmente solo se trata de unos segundos, entre las réplicas principales y secundarias.This means that there is some latency, usually only a matter of seconds, between the primary and secondary replicas. No obstante, en casos excepcionales, por ejemplo, si los problemas de red reducen el rendimiento, la latencia puede ser importante.In unusual cases, however, for example if network issues reduce throughput, latency can become significant. La latencia aumenta cuando se producen cuellos de botella de E/S y cuando se suspende el movimiento de los datos.Latency increases when I/O bottlenecks occur and when data movement is suspended. Para supervisar el movimiento de datos suspendido, puede usar el panel Always On o la vista de administración dinámica 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.

Para obtener más información sobre la investigación de la latencia de fase de puesta al día en la réplica secundaria, vea Solución de problemas: cambios en la réplica principal que no se reflejan en la réplica secundaria.For more information on investigating redo latency on the secondary replica, please see Troubleshoot primary changes not reflected on secondary replica.

Tareas relacionadasRelated Tasks

Para cambiar el modo de disponibilidad y el modo de conmutación por errorTo change the availability mode and failover mode

Para ajustar los votos de quórumTo adjust quorum votes

Para realizar una conmutación manual por errorTo perform a manual failover

Para ver los estados del grupo de disponibilidad, la réplica de disponibilidad y las bases de datosTo view availability group, availability replica, and database states

Contenido relacionadoRelated Content

Consulte tambiénSee Also

Información general de los grupos de disponibilidad AlwaysOn (SQL Server) Overview of Always On Availability Groups (SQL Server)
Conmutación por error y modos de conmutación por error (Grupos de disponibilidad AlwaysOn) Failover and Failover Modes (Always On Availability Groups)
Clústeres de conmutación por error de Windows Server (WSFC) con SQL ServerWindows Server Failover Clustering (WSFC) with SQL Server