Conmutación por error y modos de conmutación por error (grupos de disponibilidad AlwaysOn)Failover and Failover Modes (Always On Availability Groups)

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

Dentro del contexto de un grupo de disponibilidad, el rol principal y el rol secundario de las réplicas de disponibilidad suelen ser intercambiables en un proceso denominado conmutación por error.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. Hay tres formas de conmutación por error: conmutación por error automática (sin pérdida de datos), conmutación por error manual planeada (sin pérdida de datos) y conmutación por error manual forzada (con posible pérdida de datos), normalmente denominada conmutación por error forzada.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. Las conmutaciones por error automáticas o manuales planeadas mantienen todos los datos.Automatic and planned manual failover preserve all your data. Un grupo de disponibilidad realiza la conmutación por error en el nivel de la réplica de disponibilidad.An availability group fails over at the availability-replica level. Es decir, un grupo de disponibilidad conmuta por error a una de sus réplicas secundarias (el destino de conmutación por erroractual).That is, an availability group fails over to one of its secondary replicas (the current failover target).

Nota

Los problemas que se producen en el nivel de la base de datos, como, por ejemplo, en el caso de que una base de datos pase a ser sospechosa debido a la pérdida de un archivo de datos, la eliminación de una base de datos o los daños de un registro de transacciones, no producen la conmutación por error del grupo de disponibilidad.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.

Durante la conmutación por error, el destino de la conmutación por error asume el rol principal, recupera las bases de datos y las pone en línea como las nuevas bases de datos principales.During the failover, the failover target takes over the primary role, recovers its databases, and brings them online as the new primary databases. La réplica principal anterior, cuando está disponible, cambia al rol secundario y sus bases de datos se convierten en bases de datos secundarias.The former primary replica, when available, switches to the secondary role, and its databases become secondary databases. Estos roles podrían conmutarse repetidamente (o usar un destino de conmutación por error distinto) como respuesta a varios errores o con fines administrativos.Potentially, these roles can switch back and forth (or to a different failover target) in response to multiple failures or for administrative purposes.

Las formas de conmutación por error que admite una determinada réplica de disponibilidad se especifican mediante la propiedad modo de conmutación por error .The form(s) of failover that a given availability replica supports is specified by the failover mode property. En una determinada réplica de disponibilidad, los modos de conmutación por error posibles dependen del modo de disponibilidad de la réplica, como sigue:For a given availability replica, the possible failover modes depends on the availability mode of the replica, as follows:

  • Las réplicas de confirmación sincrónica admiten dos valores: automático o manual.Synchronous-commit replicas support two settings-automatic or manual. El valor “automático” admite tanto la conmutación por error automática como la manual.The "automatic" setting supports both automatic failover and manual failover. Para evitar la pérdida de datos, la conmutación automática por error y la conmutación por error planeada requieren que el destino de conmutación por error sea una réplica secundaria de confirmación sincrónica con un estado de sincronización apropiado (esto indica que todas las bases de datos secundarias del destino de conmutación por error están sincronizadas con la base de datos principal correspondiente).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). Siempre que una réplica secundaria no cumple las dos condiciones, solo admite la conmutación por error manual forzada.Whenever a secondary replica does not meet both of these conditions, it supports only forced failover. Tenga en cuenta que la conmutación por error también admite una réplica cuyo rol esté en el estado RESOLVING.Note that forced failover is also supported a replicas whose role is in the RESOLVING state.

  • Lasréplicas de confirmación asincrónica solo admiten el modo de conmutación por error manual.Asynchronous-commit replicas support only the manual failover mode. Además, debido a que nunca se sincronizan, solo admiten la conmutación por error forzada.Moreover, because they are never synchronized, they support only forced failover.

Nota

Después de una conmutación por error, las aplicaciones cliente que necesitan tener acceso a las bases de datos principales deben establecer conexión con la nueva réplica principal.After a failover, client applications that need to access the primary databases must connect to the new primary replica. Además, si la nueva réplica secundaria se configura para permitir el acceso de solo lectura, las aplicaciones cliente de solo lectura pueden conectarse a ella.Also, if the new secondary replica is configured to allow read-only access, read-only client applications can connect to it. Para obtener información sobre cómo se conectan los clientes a un grupo de disponibilidad, vea Agentes de escucha de grupo de disponibilidad, conectividad de cliente y conmutación por error de una aplicación (SQL Server).For information about how clients connect to an availability group, see Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server).

Secciones de este tema:Sections in This Topic:

Términos y definicionesTerms and Definitions

conmutación automática por errorAutomatic failover
Conmutación por error que se produce automáticamente en la pérdida de la réplica principal.A failover that occurs automatically on the loss of the primary replica. La conmutación por error automática solo se admite cuando la réplica principal actual y una réplica secundaria están configuradas con el modo de conmutación por error establecido en AUTOMATIC y la réplica secundaria está sincronizada actualmente.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. Si el modo de conmutación por error de la réplica principal o la réplica secundaria es MANUAL, no puede producirse la conmutación por error automática.If the failover mode of either the primary or secondary replica is MANUAL, automatic failover cannot occur.

Conmutación por error manual planeada (sin pérdida de datos)Planned manual failover (without data loss)
La conmutación por error manual planeada, o conmutación por error manual, es una conmutación por error iniciada por un administrador de bases de datos, normalmente con fines administrativos.Planned manual failover, or manual failover, is a failover that is initiated by a database administrator, typically, for administrative purposes. Una conmutación por error manual planeada solo se admite si tanto la réplica principal como la réplica secundaria se configuran en modo de confirmación sincrónica y la réplica secundaria está sincronizada actualmente (en estado 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). Cuando la réplica secundaria de destino está sincronizada, puede realizarse una conmutación por error manual (sin pérdida de datos) aunque la réplica principal se haya bloqueado, ya que las bases de datos secundarias están listas para la conmutación por error.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. Un administrador de base de datos inicia manualmente una conmutación por error manual.A database administrator manually initiates a manual failover.

Conmutación por error forzada (con posible pérdida de datos)Forced failover (with possible data loss)
Un administrador de bases de datos puede iniciar una conmutación por error cuando no hay ninguna réplica secundaria en estado SYNCHRONIZED con la réplica principal o cuando la réplica principal no se está ejecutando y no hay ninguna réplica secundaria lista para la conmutación por error.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. La conmutación por error forzada puede sufrir pérdida de datos y está recomendada únicamente para la recuperación ante desastres.Forced failover risks possible data loss and is recommended strictly for disaster recovery. La conmutación por error forzada también se conoce como conmutación por error manual forzada porque solo se puede iniciar manualmente.Forced failover is also known as forced manual failover because it can only be initiated manually. Esta es la única forma de conmutación por error admitida en el modo de disponibilidad de confirmación asincrónica.This is the only form of failover supported by in asynchronous-commit availability mode.

Conjunto de conmutación automática por errorAutomatic failover set

Dentro de un grupo de disponibilidad dado, par de réplicas de disponibilidad (incluida la réplica principal actual) que están configuradas para el modo de confirmación sincrónica con conmutación por error automática, si existe.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. Un conjunto de conmutación automática por errorautomatic failover set solo tiene efecto si la réplica secundaria está actualmente en estado SYNCHRONIZED con la réplica principal.An conjunto de conmutación automática por errorautomatic failover settakes effect only if the secondary replica is currently SYNCHRONIZED with the primary replica.

Conjunto de confirmación sincrónica de conmutación por errorSynchronous-commit failover set

Dentro de un grupo de disponibilidad dado, conjunto de dos o tres réplicas de disponibilidad (incluida la réplica principal actual) que están configuradas para el modo de confirmación sincrónica, si lo hubiera.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. Un conjunto de confirmación sincrónica de conmutación por errorsynchronous-commit failover setsolo tiene efecto si las replicas secundarias están configuradas para el modo de conmutación por error manual y al menos una réplica secundaria está actualmente en estado SYNCHRONIZED con la réplica principal.A conjunto de confirmación sincrónica de conmutación por errorsynchronous-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.

Conjunto completo de conmutación por errorEntire failover set

En un grupo de disponibilidad determinado, conjunto de todas las réplicas de disponibilidad cuyo estado operativo es actualmente ONLINE, independientemente del modo de disponibilidad y el modo de conmutación por error.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. El conjunto completo de conmutación por errorentire failover setes muy importante cuando no hay actualmente ninguna réplica secundaria en estado SYNCHRONIZED con la réplica principal.The conjunto completo de conmutación por errorentire failover setbecomes relevant when no secondary replica is currently SYNCHRONIZED with the primary replica.

Información general de la conmutación por errorOverview of Failover

En la siguiente tabla se resumen las formas de conmutación por error admitidas en diferentes modos de disponibilidad y de conmutación por error.The following table summarizes which forms of failover are supported under different availability and failover modes. En cada pareja, el modo de disponibilidad y el modo de conmutación reales vienen determinados por la intersección de los modos de la réplica principal y los modos de una o varias réplicas secundarias.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.

Modo de confirmación asincrónicaAsynchronous-commit mode Modo de confirmación sincrónica con modo de conmutación por error manualSynchronous-commit mode with manual-failover mode Modo de confirmación sincrónica con modo de conmutación por error automáticaSynchronous-commit mode with automatic-failover mode
conmutación automática por errorAutomatic failover NoNo NoNo Yes
Conmutación por error manual planeadaPlanned manual failover NoNo Yes Yes
conmutación por error forzadaForced failover Yes Yes *Yes *

* Si emite un comando de conmutación por error forzada en una réplica secundaria sincronizada, la réplica secundaria se comportará igual que en el caso de una conmutación por error manual.* If you issue a forced failover command on a synchronized secondary replica, the secondary replica behaves the same as for a manual failover.

El período de tiempo que la base de datos no está disponible durante una conmutación por error depende del tipo de conmutación por error y su causa.The amount of time that the database is unavailable during a failover depends on the type of failover and its cause.

Importante

Para admitir las conexiones de cliente después de la conmutación por error, excepto en las bases de datos independientes, los inicios de sesión y los trabajos definidos en cualquiera de las bases de datos principales anteriores se deben volver a crear manualmente en la nueva base de datos principal.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. Para obtener más información, vea Administración de inicios de sesión y de trabajos para las bases de datos de un grupo de disponibilidad (SQL Server).For more information, see Management of Logins and Jobs for the Databases of an Availability Group (SQL Server).

Conjuntos de conmutación por errorFailover Sets

Las formas de conmutación por error posibles para un grupo de disponibilidad determinado se pueden considerar como conjuntos de conmutación por error.The forms of failover that are possible for a given availability group can be understood in terms of failover sets. Un conjunto de conmutación por error consta de una réplica principal y varias réplicas secundarias que admiten una determinada forma de conmutación, de la manera siguiente:A failover set consists of the primary replica and secondary replicas that support a given form of failover, as follows:

  • Conjunto de conmutación automática por errorAutomatic failover set (opcional): Dentro de un grupo de disponibilidad dado, par de réplicas de disponibilidad (incluida la réplica principal actual) que están configuradas para el modo de confirmación sincrónica con conmutación por error automática, si existe.Conjunto de conmutación automática por errorAutomatic 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. Un conjunto de conmutación automática por error solo tiene efecto si la réplica secundaria está actualmente en estado SYNCHRONIZED con la réplica principal.An automatic failover set takes effect only if the secondary replica is currently SYNCHRONIZED with the primary replica.

  • Conjunto de confirmación sincrónica de conmutación por errorSynchronous-commit failover set (opcional): Dentro de un grupo de disponibilidad dado, conjunto de dos o tres réplicas de disponibilidad (incluida la réplica principal actual) que están configuradas para el modo de confirmación sincrónica, si lo hubiera.Conjunto de confirmación sincrónica de conmutación por errorSynchronous-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. Un conjunto de confirmación sincrónica de conmutación automática por error solo tiene efecto si las réplicas secundarias están configuradas para el modo de conmutación por error manual y al menos una réplica secundaria está actualmente en estado SYNCHRONIZED con la réplica principal.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.

  • Conjunto completo de conmutación por errorEntire failover set: En un grupo de disponibilidad determinado, conjunto de todas las réplicas de disponibilidad cuyo estado operativo es actualmente ONLINE, independientemente del modo de disponibilidad y el modo de conmutación por error.Conjunto completo de conmutación por errorEntire 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. El conjunto completo de conmutación por error es importante cuando no hay actualmente ninguna réplica secundaria en estado SYNCHRONIZED con la réplica principal.The entire failover set becomes relevant when no secondary replica is currently SYNCHRONIZED with the primary replica.

Al configurar una réplica de disponibilidad como confirmación sincrónica con conmutación por error automática, la réplica de disponibilidad forma parte de conjunto de conmutación automática por errorautomatic failover set.When you configure an availability replica as synchronous commit with automatic failover, the availability replica becomes part of the conjunto de conmutación automática por errorautomatic failover set. Sin embargo, que el conjunto tenga efecto dependerá de la réplica principal actual.However whether the set takes effect depends the current primary. Las formas de conmutación por error que son actualmente posibles en un momento determinado dependen de qué conjuntos de conmutación estén actualmente activos.The forms of failover that are actually possible at a given time depends on what failover sets are currently in effect.

Por ejemplo, considere el caso de un grupo de disponibilidad con cuatro réplicas de disponibilidad, del siguiente modo:For example, consider an availability group that has four availability replicas, as follows:

RéplicaReplica Configuración de disponibilidad y modo de conmutación por errorAvailability Mode and Failover Mode Settings
UnA Confirmación sincrónica con conmutación por error automáticaSynchronous commit with automatic failover
BB Confirmación sincrónica con conmutación por error automáticaSynchronous commit with automatic failover
CC Confirmación sincrónica con solo conmutación por error manual planeadaSynchronous commit with planned manual failover only
DD Confirmación asincrónica (con solo conmutación por error forzada)Asynchronous commit (with only forced failover)

El comportamiento de conmutación por error para cada réplica secundaria dependerá de qué réplica de disponibilidad sea actualmente la réplica principal.The failover behavior for each secondary replica depends on which availability replica is currently the primary replica. Básicamente, para una réplica secundaria dada, el comportamiento de conmutación por error es el peor caso dada la réplica principal actual.Basically, for a given secondary replica, the failover behavior is the worst case given the current primary replica. En la ilustración siguiente se muestra cómo el comportamiento de la conmutación por error de réplicas secundarias varía en función de la réplica principal actual y si está configurada para el modo de confirmación asincrónica (con solo conmutación por error forzada) o el modo de confirmación sincrónica (con o sin conmutación automática por error).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).

Cómo la configuración de la réplica principal afecta a la conmutación por errorHow primary replica configuration affects failover

Automatic FailoverAutomatic Failover

Una conmutación por error automática hace que una réplica secundaria calificada realice la transición automática al rol principal después de que la réplica principal deje de estar disponible.An automatic failover causes a qualified secondary replica to automatically transition to the primary role after the primary replica becomes unavailable. La conmutación por error automática es más apropiada cuando el nodo de WSFC que hospeda la réplica principal es local para el nodo que hospeda la réplica secundaria.Automatic failover is best suited when the WSFC node that hosts the primary replica is local to the node that hosts the secondary replica. Esto se debe a que la sincronización de datos funciona mejor con una latencia de mensajes baja entre equipos y a que las conexiones de cliente pueden seguir siendo locales.This is because data synchronization works best with low message latency between computers and because client connections can remain local.

En esta sección:In This Section:

Condiciones requeridas para una conmutación automática por errorConditions Required for an Automatic Failover

La conmutación por error automática solo aparece en las siguientes condiciones:Automatic failover occurs only under the following conditions:

  • Ya existe un conjunto de conmutación por error automática.An automatic failover set exists. Este conjunto consta de una réplica principal y una secundaria (el destino de conmutación automática por error) que están configuradas para el modo de confirmación sincrónica y también para la conmutación AUTOMÁTICA por error.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. Si la réplica principal se establece en modo de conmutación por error MANUAL, no puede producirse la conmutación por error automática aunque se establezca una réplica secundaria en el modo de conmutación AUTOMÁTICA por error.If the primary replica is set to MANUAL failover, automatic failover cannot occur, even if a secondary replica is set to AUTOMATIC failover.

    Para obtener más información, vea Modos de disponibilidad (grupos de disponibilidad AlwaysOn).For more information, see Availability Modes (Always On Availability Groups).

  • El destino de la conmutación por error automática tiene un estado de sincronización correcto (esto indica que cada base de datos secundaria del destino de la conmutación por error se sincroniza con la base de datos principal correspondiente).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).

    Sugerencia

    Los grupos de disponibilidad AlwaysOn supervisan el estado de ambas réplicas de un conjunto de conmutación automática por error.Always On Availability Groups monitors the health of both replicas in an automatic failover set. Si se produce un error en alguna de las réplicas, el estado del grupo de disponibilidad se establece en CRITICAL.If either replica fails, the availability group's health state is set to CRITICAL. Si se produce un error en la réplica secundaria, la conmutación por error automática no es posible debido a que el destino de esta no está disponible.If the secondary replica fails, automatic failover is not possible because the automatic failover target is unavailable. Si se produce un error en la réplica principal, el grupo de disponibilidad realizará una conmutación por error a la réplica secundaria.If the primary replica fails, the availability group will fail over to the secondary replica. No existirá ningún destino de conmutación por error automática hasta que la réplica principal anterior se ponga en línea.Until the former primary replica comes online, no automatic failover target exists. De todas maneras, para garantizar la disponibilidad en el caso improbable de un fallo secuencial, se recomienda configurar una réplica secundaria diferente como destino de la conmutación por error automática.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.

    Para obtener más información, vea Usar directivas de AlwaysOn para ver el estado de un grupo de disponibilidad (SQL Server) y Cambiar el modo de conmutación por error de una réplica de disponibilidad (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).

  • El clúster del servicio de clústeres de conmutación por error (WSFC) tiene quórum.The Windows Server Failover Clustering (WSFC) cluster has quorum. Para obtener más información, vea Configuración de los votos y modos de cuórum WSFC (SQL Server).For more information, see WSFC Quorum Modes and Voting Configuration (SQL Server).

  • La réplica principal ha dejado de estar disponible y se han cumplido los niveles de condición de conmutación por error de la directiva de conmutación por error flexible.The primary replica has become unavailable, and the failover-condition levels defined by your the flexible failover policy have been met. Para obtener más información sobre los niveles de condición de conmutación por error, vea Directiva de conmutación por error flexible para conmutación automática por error de un grupo de disponibilidad (SQL Server).For information about failover-condition levels, see Flexible Failover Policy for Automatic Failover of an Availability Group (SQL Server).

Cómo funciona la conmutación automática por errorHow Automatic Failover Works

Una conmutación automática por error inicia la siguiente secuencia de acciones:An automatic failover initiates the following sequence of actions:

  1. Si la instancia del servidor que hospeda la réplica principal actual sigue en ejecución, cambia el estado de las bases de datos principales a DISCONNECTED y desconecta todos los clientes.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. Si las entradas del registro están esperando en colas de recuperación en la réplica secundaria de destino, la réplica secundaria aplica las entradas del registro restantes para terminar la puesta al día de las bases de datos secundarias.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.

    Nota

    La cantidad de tiempo que requiere la aplicación del registro a una base de datos dada depende de la velocidad del sistema, la carga de trabajo reciente y la cantidad de registro en la cola de cola de recuperación.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. Las réplica secundaria anterior realiza la transición al rol principal.The former secondary replica transitions to the primary role. Sus bases de datos se convierten en las bases de datos principales.Its databases become the primary databases. La nueva réplica principal revierte las transacciones no confirmadas (fase de reversión de recuperación) lo más rápidamente posible.The new primary replica rolls back any uncommitted transactions (the undo phase of recovery) as quickly as possible. Los bloqueos aíslan las transacciones no confirmadas, permitiendo que se produzca la reversión en segundo plano mientras los clientes usan la base de datos.Locks isolate these uncommitted transactions, allowing roll back to occur in the background while clients use the database. Este proceso no revierte las transacciones confirmadas.This process does not roll back any committed transactions.

    Hasta que se conecta una determinada base de datos secundaria, se marca brevemente como NOT_SYNCHRONIZED.Until a given secondary database is connected, it is briefly marked as NOT_SYNCHRONIZED. Antes de que la recuperación de reversión se inicie, las bases de datos secundarias pueden conectarse a las bases de datos principales y pasar rápidamente al estado SYNCHRONIZED.Before the rollback recovery starts, secondary databases can connect to the new primary databases and quickly transition to the SYNCHRONIZED state. El caso que mejor suele funcionar es aquel en el que hay una tercera réplica de confirmación sincrónica que permanece en el rol secundario después de la conmutación por error.The best case is usually for a third synchronous-commit replica that remains in the secondary role after the failover.

  4. Posteriormente, cuando la instancia del servidor que hospeda la réplica principal anterior se reinicia, reconoce que otra réplica de disponibilidad posee el rol principal.Later, when the server instance that is hosting the former primary replica restarts, it recognizes that another availability replica now owns the primary role. La réplica principal anterior realiza la transición al rol secundario y sus bases de datos se convierten en bases de datos secundarias.The former primary replica transitions to the secondary role, and its databases become secondary databases. La nueva réplica secundaria se conecta a la réplica principal actual y detecta su base de datos en las bases de datos principales actuales lo más rápidamente posible.The new secondary replica connects to the current primary replica and catches its database up to the current primary databases as quickly as possible. Tan pronto como la nueva réplica secundaria haya vuelto a sincronizar sus bases de datos, la conmutación por error vuelve a ser posible, pero en dirección inversa.As soon as the new secondary replica has resynchronized its databases, failover is again possible, in the reverse direction.

Para configurar la conmutación automática por errorTo Configure Automatic Failover

Una réplica de disponibilidad se puede configurar para admitir la conmutación por error automática en cualquier momento.An availability replica can be configured to support automatic failover at any point.

To configure automatic failoverTo configure automatic failover

  1. Asegúrese de que la réplica secundaria esté configurada para utilizar el modo de disponibilidad de confirmación sincrónica.Ensure that the secondary replica is configured to use the synchronous-commit availability mode. Para obtener más información, vea Cambiar el modo de disponibilidad de una réplica de disponibilidad (SQL Server).For more information, see Change the Availability Mode of an Availability Replica (SQL Server).

  2. Establezca el modo de conmutación por error a automático.Set the failover mode to automatic. Para obtener más información, vea Cambiar el modo de conmutación por error de una réplica de disponibilidad (SQL Server).For more information, see Change the Failover Mode of an Availability Replica (SQL Server).

  3. Si lo desea, también puede cambiar la directiva de conmutación por error flexible del grupo de disponibilidad para especificar los tipos de errores que pueden causar una conmutación automática por error.Optionally, change the flexible failover policy of the availability group to specify the sorts of failures that can cause an automatic failover to occur. Para obtener más información, vea Configurar la directiva de conmutación por error flexible para controlar las condiciones de la conmutación automática por error (grupos de disponibilidad AlwaysOn) y Directiva de conmutación por error para instancias de clústeres de conmutación por error.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.

Conmutación por error manual planeada (sin pérdida de datos)Planned Manual Failover (Without Data Loss)

Una conmutación por error manual produce la transición de una réplica secundaria al rol principal después de que un administrador de bases de datos emita un comando de conmutación por error manual en la instancia del servidor que hospeda la réplica secundaria de destino.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. Para admitir la conmutación por error manual, la réplica secundaria y la réplica principal actual se deben configurar en modo de confirmación sincrónica, si lo hubiera.To support manual failover, the secondary replica and the current primary replica must both be configured for synchronous-commit mode, if any. Cada base de datos secundaria de la réplica de disponibilidad debe unirse al grupo de disponibilidad y sincronizarse con la base de datos principal correspondiente (es decir, la réplica secundaria se debe sincronizar).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). Esto garantiza que cada transacción confirmada en una base de datos principal anterior también se ha confirmado en la nueva base de datos principal.This guarantees that every transaction that was committed on a former primary database has also been committed on the new primary database. Por tanto, las nuevas bases de datos principales son idénticas a las bases de datos principales antiguas.Therefore, the new primary databases are identical to the old primary databases.

En la siguiente ilustración se muestran las fases de una conmutación por error planeada:The following figure illustrates the stages of a planned failover:

  1. Antes de la conmutación por error, la instancia del servidor hospeda la réplica principal en Node01.Before the failover, the primary replica is hosted by the server instance on Node01.

  2. Un administrador de bases de datos inicia una conmutación por error planeada.A database administrator initiates a planned failover. El destino de la conmutación por error es la réplica de disponibilidad hospedada por la instancia de servidor en Node02.The failover target is the availability replica hosted by the server instance on Node02.

  3. El destino de la conmutación por error (en Node02) se convierte en la nueva réplica principal.The failover target (on Node02) becomes the new primary replica. Como se trata de una conmutación por error planeada, la réplica principal anterior se cambia al rol secundario durante la conmutación por error y pone inmediatamente sus bases de datos en línea como bases de datos secundarias.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.

Imagen de una conmutación por error manual planeadaIllustation of a planned manual failover

En esta sección:In This Section:

Condiciones requeridas para una conmutación por error manualConditions Required for a Manual Failover

Para admitir una conmutación por error manual, la réplica principal actual debe establecerse en modo de confirmación sincrónica y una réplica secundaria debe estar:To support a manual failover, the current primary replica must be set to synchronous-commit mode and a secondary replica must be:

  • Configurada para el modo de confirmación sincrónica.Configured for synchronous-commit mode.

  • Sincronizada actualmente con la réplica principal.Currently synchronized with the primary replica.

Para realizar la conmutación por error manual en un grupo de disponibilidad, debe conectarse a la réplica secundaria que se va a convertir en la nueva réplica principal.To manually fail over an availability group, you must be connected to the secondary replica that is to become the new primary replica.

Cómo funciona la conmutación por error manual planeadaHow a Planned Manual Failover Works

Una conmutación por error manual planeada, que se debe iniciar en la réplica secundaria de destino, inicia la siguiente secuencia de acciones:A planned manual failover, which must be initiated on the target secondary replica, initiates the following sequence of actions:

  1. Para asegurarse de que se producen transacciones de ningún usuario nuevo en las bases de datos principales originales, el clúster de WSFC envía una solicitud a la réplica principal para pasar a modo sin conexión.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. Si un registro está esperando en la cola de recuperación de cualquier base de datos secundaria, la réplica secundaria finaliza las puesta al día de esa base de datos secundaria.If any log is waiting in the recovery queue of any secondary database, the secondary replica finishes rolling forward that secondary database. La cantidad de tiempo que se necesita para ello depende de la velocidad del sistema, la carga de trabajo reciente y la cantidad de registro en la cola de recuperación.The amount of time required depends on the speed of the system, the recent workload, and the amount of log in the recovery queue. Para conocer el tamaño actual de la cola de recuperación, utilice el contador de rendimiento Cola de recuperación .To learn the current size of the recovery queue, use the Recovery Queue performance counter. Para obtener más información, vea SQL Server, Database Replica (SQL Server, réplica de base de datos).For more information, see SQL Server, Database Replica.

    Nota

    El tiempo de conmutación por error se puede regular limitando el tamaño de la cola de recuperación.The failover time can be regulated by limiting the size of the recovery queue. Sin embargo, esto puede hacer que la réplica principal se ralentice para permitir que la réplica secundaria no se retrase.However, this can cause the primary replica to slow down to allow the secondary replica to keep up.

  3. La réplica secundaria se convierte en la nueva réplica principal y la réplica principal anterior se convierte en la nueva réplica secundaria.The secondary replica becomes the new primary replica, and the former primary replica becomes the new secondary replica.

  4. La nueva réplica principal revierte las transacciones no confirmadas y pone sus bases de datos en línea como bases de datos principales. Todas las bases de datos secundarias se marcan brevemente como NOT SYNCHRONIZED hasta que se conectan y vuelven a sincronizar con las nuevas bases de datos principales.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. Este proceso no revierte las transacciones confirmadas.This process does not roll back any committed transactions.

  5. Cuando la réplica principal anterior vuelve a estar en línea, toma el rol secundario y la base de datos principal anterior se convierte en la base de datos secundaria.When the former primary replica comes back online, it takes on the secondary role, and the former primary database becomes the secondary database. La nueva réplica secundaria vuelve a sincronizar rápidamente las nuevas bases de datos secundarias con las bases de datos principales correspondientes.The new secondary replica quickly resynchronizes the new secondary databases with the corresponding primary databases.

    Nota

    Tan pronto como la nueva réplica secundaria haya vuelto a sincronizar las bases de datos, la conmutación por error vuelve a ser posible, pero en dirección inversa.As soon as the new secondary replica has resynchronized the databases, failover is again possible, but in the reverse direction.

Tras la conmutación por error, los clientes deben volver a conectarse a la base de datos principal actual.After failover, clients must reconnect to the current primary database. Para obtener más información, vea Agentes de escucha de grupo de disponibilidad, conectividad de cliente y conmutación por error de una aplicación (SQL Server).For more information, see Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server).

Mantener la disponibilidad durante las actualizacionesMaintaining Availability During Upgrades

El administrador de base de datos para sus grupos de disponibilidad puede utilizar conmutaciones por error manuales para mantener la disponibilidad de la base de datos al actualizar el hardware o el software.The database administrator for your availability groups can use manual failovers to maintain database availability when you upgrade hardware or software. Para utilizar un grupo de disponibilidad para actualizaciones de software, la instancia del servidor y/o el nodo del equipo que hospeda la réplica secundaria de destino deben haber recibido ya las actualizaciones.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. Para obtener más información, vea Actualización de instancias de la réplica del grupo de disponibilidad AlwaysOn.For more information, see Upgrading Always On Availability Group Replica Instances.

Conmutación por error forzada (con posible pérdida de datos)Forced Failover (with Possible Data Loss)

La acción de forzar una conmutación por error de un grupo de disponibilidad (con posible pérdida de datos) es un método de recuperación ante desastres que permite usar una réplica secundaria como servidor en espera semiactiva. Puesto que forzar la conmutación por error puede suponer una posible pérdida de datos, se debe hacer con precaución y moderación.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. Se recomienza que la conmutación por error solo se fuerce si es necesario restaurar el servicio en las bases de datos de disponibilidad inmediatamente y es aceptable el riesgo de perder algunos datos.We recommend forcing failover only if you must restore service to your availability databases immediately and are willing to risk losing data. Para obtener más información sobre los requisitos previos y las recomendaciones para forzar la conmutación por error y para ver un escenario de ejemplo que usa una conmutación por error forzada para recuperarse de un error grave, vea Realizar una conmutación por error manual forzada de un grupo de disponibilidad (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).

Advertencia

La acción de forzar una conmutación por error requiere que el clúster de WSFC tenga quórum.Forcing failover requires that the WSFC cluster have quorum. Para obtener información sobre cómo configurar y forzar el cuórum, vea Clústeres de conmutación por error de Windows Server (WSFC) con SQL Server.For information about configuring quorum and forcing quorum, see Windows Server Failover Clustering (WSFC) with SQL Server.

En esta sección:In This Section:

Cómo funciona la conmutación por error forzadaHow Forced Failover Works

Forzar la conmutación por error inicia una migración del rol principal a una réplica de destino cuyo rol está en el estado SECONDARY o RESOLVING.Forcing failover initiates a transition of the primary role to a target replica whose role is in the SECONDARY or RESOLVING state. El destino de la conmutación por error se convierte en la nueva réplica principal y sirve inmediatamente sus copias de las bases de datos a los clientes.The failover target becomes the new primary replica and immediately serves its copies of the databases to clients. Cuando la réplica principal anterior está disponible, realizará la transición al rol secundario y sus bases de datos se convertirán en bases de datos secundarias.When the former primary replica becomes available, it will transition to the secondary role and its databases will become secondary databases.

Todas las bases de datos secundarias (incluidas las bases de datos principales anteriores cuando están disponibles) cambian al estado SUSPENDED.All secondary databases (including the former primary databases, when they become available) are SUSPENDED. Según el estado de sincronización de datos anterior de una base de datos secundaria suspendida podría ser conveniente para recuperar los datos confirmados que faltan para esa base de datos principal.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. En una réplica secundaria configurada para el acceso de solo lectura se pueden consultar las bases de datos secundarias para detectar manualmente los datos que faltan.On a secondary replica that is configured for read-only access, you can query the secondary databases to manually discover missing data. A continuación, se pueden emitir instrucciones Transact-SQLTransact-SQL en las nuevas bases de datos principales para realizar los cambios necesarios.Then you can issue Transact-SQLTransact-SQL statements on the new primary databases to make any necessary changes.

Riesgos de forzar la conmutación por errorRisks of Forcing Failover

Es esencial tener en cuenta que si se fuerza la conmutación por error se pueden perder datos.It is essential to understand that forcing failover can cause data loss. La pérdida de datos es posible porque la réplica de destino no puede comunicarse con la réplica principal y, por lo tanto, no se puede garantizar que las bases de datos estén sincronizadas.Data loss is possible because the target replica cannot communicate with the primary replica and, therefore, cannot guarantee that the databases are synchronized. Al forzar la conmutación por error se inicia una nueva bifurcación de recuperación.Forcing failover starts a new recovery fork. Puesto que la base de datos principal original y las bases de datos secundarias están en bifurcaciones de recuperación diferentes, cada una de ellas contiene ahora datos que las otras bases de datos no contienen: cada base de datos principal original contiene los cambios que aún no se han enviado desde su cola de envío a la base de datos secundaria anterior (registro sin enviar); las bases de datos secundarias anteriores contienen los cambios que se han producido después de forzar la conmutación por error.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.

Si la conmutación por error se fuerza debido a que la réplica principal no funcionó, la posible pérdida de datos depende de si se ha enviado o no algún registro de transacciones a la réplica secundaria antes del problema.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. En el modo de confirmación asincrónica, la acumulación del registro sin enviar siempre es una posibilidad.Under the asynchronous-commit mode, accumulated unsent log is always a possibility. En modo de confirmación sincrónica, esto solo es posible hasta que las bases de datos secundarias estén sincronizadas.Under synchronous-commit mode, this is possible only until the secondary databases become synchronized.

En la tabla siguiente se resume la posibilidad de perder datos para una base de datos determinada en la réplica en la que se fuerza la conmutación por error.The following table summarizes the possibility of data loss for a particular database on the replica to which you force failover.

Modo de disponibilidad de una réplica secundariaAvailability mode of Secondary Replica ¿Está sincronizada la base de datos?Is database synchronized? ¿Es posible que se pierdan datos?Is data loss possible?
Confirmación sincrónicaSynchronous-commit Yes NoNo
Confirmación sincrónicaSynchronous-commit NoNo Yes
Confirmación asincrónicaAsynchronous-commit NoNo Yes

Las bases de datos secundarias realizan el seguimiento solo en dos bifurcaciones de recuperación, por lo que, si se realizan varias conmutaciones por error forzadas, no podrá reanudarse ninguna de las bases de datos secundarias que comenzaron la sincronización de datos con la conmutación por error forzada anterior.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. Si esto se produce, las bases de datos secundarias que no puedan reanudarse tendrán que quitarse del grupo de disponibilidad, restaurarse en el punto de tiempo preciso y unirse de nuevo al grupo de disponibilidad.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. En este escenario, se puede observar el error 1408 con el estado 103 (error: 1408, gravedad: 16, estado: 103).Error 1408 with state 103 may be observed in this scenario (Error: 1408, Severity: 16, State: 103). Una restauración no funcionará entre varias bifurcaciones de recuperación; por tanto, asegúrese de realizar una copia de seguridad de registros después de realizar varias conmutaciones por error forzadas.A restore will not work across multiple recovery forks, therefore, be sure to perform a log backup after performing more than one forced failover.

Por qué se requiere la conmutación por error después de forzar el quórumWhy Forced Failover is Required After Forcing Quorum

Después de forzar el cuórum en el clúster WSFC (cuórum forzado), debe realizarse una conmutación por error forzada (con posible pérdida de datos) en todos los grupos de disponibilidad.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. La conmutación por error forzada es necesaria porque el estado real de los valores del clúster WSFC puede haberse perdido.The forced failover is required because the real state of the WSFC cluster values might have been lost. Es necesario evitar las conmutaciones por error normales después de un quórum forzado debido a la posibilidad de que una réplica secundaria no sincronizada parezca sincronizada en el clúster WSFC reconfigurado.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.

Por ejemplo, considere la posibilidad de un clúster WSFC que hospeda un grupo de disponibilidad en tres nodos: el nodo A hospeda la réplica principal y los nodos B y C hospedan una réplica secundaria cada uno.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. El nodo C se desconecta del clúster WSFC mientras la réplica secundaria local se sincroniza.Node C gets disconnected from the WSFC cluster while the local secondary replica is SYNCHRONIZED. Pero los nodos A y B conservan un quórum correcto y el grupo de disponibilidad sigue en línea.But Node A and Node B retain a healthy quorum and the availability group remains online. En el nodo A, la réplica principal continúa aceptando actualizaciones y, en el nodo B, la réplica secundaria continúa sincronizándose con la réplica principal.On Node A, the primary replica continues to accept updates, and on Node B, the secondary replica continues to synchronize with the primary replica. La réplica secundaria del nodo C se desincroniza y se encuentra cada vez más retrasada respecto de la réplica principal.The secondary replica on Node C becomes unsynchronized and falls increasingly behind the primary replica. Sin embargo, debido a que el nodo C está desconectado, la réplica permanece incorrectamente en el estado SYNCHRONIZED.However, because Node C is disconnected, the replica remains, incorrectly, in the SYNCHRONIZED state.

Si se pierde el quórum y después se fuerza en el nodo A, el estado de sincronización del grupo de disponibilidad del clúster WSFC debería ser correcto y la réplica secundaria del nodo C debería mostrarse como 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. Sin embargo, si se fuerza el quórum en el nodo C, la sincronización del grupo de disponibilidad será incorrecta.However, if quorum is forced on Node C, the synchronization of the availability group will be incorrect. El estado de sincronización del clúster se habrá revertido al estado que tenía cuando el nodo C estaba desconectado y la réplica secundaria del nodo C se mostraría incorrectamente como 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. Dado que las conmutaciones por error manuales planeadas garantizan la seguridad de los datos, no están permitidas para poner un grupo de disponibilidad de nuevo en línea después de forzar el quórum.Since planned manual failovers guarantee the safety of the data, they are disallowed for bring an availability group back online after quorum is forced.

Seguimiento de la posible pérdida de datosTracking Potential Data Loss

Cuando el clúster WSFC tiene un quórum correcto, se puede calcular el potencial actual de pérdida de datos en las bases de datos.When the WSFC cluster has a healthy quorum, you can estimate the current potential for data loss on databases. Para una réplica secundaria dada, el potencial actual de pérdida de datos depende de lo retrasadas que estén las bases de datos secundarias locales respecto de las bases de datos principales correspondientes.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. Debido a que la cantidad de retardo varía con el tiempo, se recomienda que realice un seguimiento periódico del potencial de pérdida de datos de las bases de datos secundarias no sincronizadas.Because the amount of lag varies over time, we recommend that you periodically track potential data loss for your unsynchronized secondary databases. El seguimiento del retardo implica comparar el Último LSN de confirmación y la Última hora de confirmación de cada base de datos principal y de sus bases de datos secundarias, de la forma siguiente:Tracking lag involves comparing the Last Commit LSN and Last Commit Time for each primary database and its secondary databases, as follows:

  1. Conéctese a la réplica principal.Connect to the primary replica.

  2. Consulte las columnas last_commit_lsn (LSN de la última transacción confirmada) y last_commit_time (hora de la última confirmación) de la vista de administración dinámica 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 los valores devueltos para cada base de datos principal y cada una de sus bases de datos secundarias.Compare the values returned for each primary database and each of its secondary databases. La diferencia entre sus últimos LSN de confirmación indican el tiempo de retardo.The difference between their Last Commit LSNs indicate the amount of lag.

  4. Puede desencadenar una alerta cuando el tiempo de retardo en una base de datos o conjunto de base de datos supere el retardo máximo deseado durante un período de tiempo determinado.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. Por ejemplo, un trabajo que se ejecute cada minuto en cada base de datos principal puede realizar la consulta.For example, the query can be run by a job that executes every minute on each primary database. Si la diferencia entre el valor de last_commit_time de una base de datos principal y cualquiera de sus bases de datos secundarias ha superado el objetivo de punto de recuperación (RPO) (por ejemplo, 5 minutos) desde la última vez que se ejecutó el trabajo, este puede generar una alerta.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.

Importante

Cuando el clúster de WSFC carece de cuórum o cuando este último se ha forzado, last_commit_lsn y last_commit_time tienen el valor NULL.When the WSFC cluster lacks quorum or quorum has been forced, last_commit_lsn and last_commit_time are NULL. Para obtener información sobre cómo podría evitar la pérdida de datos después de forzar el cuórum, vea "Formas posibles de evitar la pérdida de datos después de forzar el cuórum" en Realizar una conmutación por error manual forzada de un grupo de disponibilidad (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).

Administrar la potencial pérdida de datosManaging the Potential Data Loss

Después de forzar una conmutación por error, se suspenden todas las bases de datos secundarias.After failover is forced, all secondary databases are suspended. Esto incluye las bases de datos principales antiguas, después de que la réplica principal anterior vuelva a estar en línea y detecte que ahora es una réplica secundaria.This includes the former primary databases, after the former primary replica comes back online and discovers that it is now a secondary replica. Debe reanudar manualmente y de forma individual cada una de las bases de datos suspendidas en cada réplica secundaria.You must manually resume each suspended database individually on each secondary replica.

Una vez que esté disponible la réplica principal anterior y en el supuesto de que sus bases de datos no estén dañadas, se puede intentar administrar la potencial pérdida de datos.Once the former primary replica is available, assuming that its databases are undamaged, you can attempt to manage the potential data loss. El enfoque disponible para administrar la posible pérdida de datos depende de si la réplica principal original se ha conectado a la nueva réplica principal.The available approach for managing potential data loss depends on whether the original primary replica has connected to the new primary replica. Suponiendo que la réplica principal original pueda tener acceso a la nueva instancia principal, la reconexión se produce de forma automática y transparente.Assuming that the original primary replica can access the new primary instance, reconnecting occurs automatically and transparently.

La réplica principal original se ha vuelto a conectarThe Original Primary Replica Has Reconnected

Generalmente, después de un problema, cuando la réplica principal original se reinicia, se vuelve a conectar rápidamente a su asociado.Typically, after a failure, when the original primary replica restarts it quickly reconnects to its partner. Al volver a conectarse, la réplica principal original se convierte en la réplica secundaria.On reconnecting, the original primary replica becomes the secondary replica. Las bases de datos se convierten en bases de datos secundarias y entran en estado SUSPENDED.Its databases becomes the secondary databases and enter the SUSPENDED state. Las nuevas bases de datos secundarias no se no se revertirán a menos que se reanuden.The new secondary databases will not be not rolled back unless you resume them.

Sin embargo, las bases de datos suspendidas son inaccesibles; por lo tanto, no se pueden inspeccionar para evaluar qué datos se perderían si se reanudara una base de datos dada.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. Por lo tanto, la decisión de si ha de reanudar o quitar una base de datos secundaria depende de si se está dispuesto a aceptar una pérdida de datos, del siguiente modo: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:

  • Si una pérdida de datos es inaceptable, debe quitar las bases de datos del grupo de disponibilidad para protegerlas.If losing any data would be unacceptable, you should remove the databases from the availability group to salvage them.

    El administrador de base de datos puede ahora recuperar las bases de datos principales anteriores e intentar recuperar los datos que se habrían perdido.The database administrator can now recover the former primary databases and attempt to recover the data that would have been lost. Sin embargo, cuando una base de datos principal anterior se pone en línea, es divergente de la base de datos principal actual, por lo que el administrador de base de datos debe hacer que la base de datos quitada o la base de datos principal actual no sea accesible a los clientes para evitar la divergencia posterior de las bases de datos y los problemas de conmutación por error del cliente.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.

  • Si la pérdida de datos es aceptable para sus objetivos empresariales, puede reanudar las bases de datos secundarias.If losing data would be acceptable to your business goals, you can resume the secondary databases.

    Al reanudar una nueva base de datos secundaria se produce su reversión como primer paso en su sincronización.Resuming a new secondary database causes it to be rolled back as the first step in synchronizing the database. Si alguna entrada del registro estuviera esperando en la cola de envío en el momento del problema, se perderían las transacciones correspondientes, incluso si se hubieran confirmado.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.

La réplica principal original no se ha vuelto a conectarThe Original Primary Replica Has Not Reconnected

Si puede impedir temporalmente que la réplica principal original se vuelva a conectar a través de la red a la nueva réplica principal, puede inspeccionar las bases de datos principales originales para evaluar qué datos se perderían si se reanudaran.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.

  • Si la posible pérdida de datos es aceptableIf the potential data loss is acceptable

    Permita que la réplica principal original se vuelva a conectar a la nueva réplica principal.Allow the original primary replica to reconnect to the new primary replica. La acción de volver a conectarse hace que las nuevas bases de datos secundarias se suspendan.Reconnecting causes the new secondary databases to be suspended. Para iniciar la sincronización de datos en una base de datos, solo tiene que reanudarla.To start data synchronization on a database, simply resume it. La nueva réplica secundaria quita la bifurcación de recuperación original para esa base de datos, con lo que se pierden las transacciones que no se han enviado nunca a la réplica secundaria anterior o no se han recibido de ella.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.

  • Si la pérdida de datos es inaceptableIf the data loss is unacceptable

    Si la base de datos principal original contiene datos esenciales que se perderían si se reanudara la base de datos suspendida, puede preservar los datos de la base de datos principal original quitándola del grupo de disponibilidad.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. Esto hace que la base de datos entre en estado RESTORING.This causes the database to enter the RESTORING state. Llegados a esta situación, se recomienda intentar realizar una copia de seguridad del final del registro de la base de datos quitada.At this point, we recommend that you attempt to back up the tail of the removed database's log. Después, puede actualizar la base de datos principal actual (base de datos secundaria anterior) exportando los datos que desea proteger de la base de datos principal original e importándolos a la base de datos principal actual.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. Se recomienda realizar una copia de seguridad completa de la base de datos principal actualizada tan pronto como sea posible.We recommend taking a full database backup of the updated primary database as quickly as possible.

    A continuación, en la instancia del servidor que hospeda la nueva réplica secundaria, puede eliminar la base de datos secundaria suspendida y crear una nueva base de datos secundaria restaurando esta copia de seguridad (y al menos una copia de seguridad de registros posterior) utilizando 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. Se recomienda retrasar la realización de copias de seguridad de registros adicionales de las bases de datos principales actuales hasta que se reanuden las bases de datos secundarias correspondientes.We recommend delaying additional log backups of the current primary databases until the corresponding secondary databases are resumed.

Advertencia

El truncamiento del registro de transacciones se retrasa en una base de datos principal mientras cualquiera de sus bases de datos secundarias está suspendida.Transaction log truncation is delayed on a primary database while any of its secondary databases is suspended. Además, el estado de sincronización de una réplica secundaria de confirmación sincrónica no puede pasar a HEALTHY siempre que alguna base de datos local se suspende.Also the synchronization health of a synchronous-commit secondary replica cannot transition to HEALTHY as long as any local database remains suspended.

Tareas relacionadasRelated Tasks

Para configurar el comportamiento de la conmutación por errorTo configure failover behavior

Para realizar una conmutación por error manualTo perform a manual fail over

Para establecer la configuración de quórum de WSFCTo configure WSFC Quorum Configuration

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)
Modos de disponibilidad (grupos de disponibilidad AlwaysOn) Availability Modes (Always On Availability Groups)
Clústeres de conmutación por error de Windows Server (WSFC) con SQL Server Windows Server Failover Clustering (WSFC) with SQL Server
Transacciones entre bases de datos y transacciones distribuidas para la creación de reflejo de la base de datos o grupos de disponibilidad AlwaysOn (SQL Server) Cross-Database Transactions and Distributed Transactions for Always On Availability Groups and Database Mirroring (SQL Server)
Directiva de conmutación por error para instancias de clústeres de conmutación por error Failover Policy for Failover Cluster Instances
Directiva de conmutación por error flexible para conmutación automática por error de un grupo de disponibilidad (SQL Server)Flexible Failover Policy for Automatic Failover of an Availability Group (SQL Server)