Realice una conmutación por error manual planificada de un grupo de disponibilidad de Always On (SQL Server)

Se aplica a:SQL Server

En este tema se describe cómo realizar una conmutación por error manual sin pérdida de datos (una conmutación por error manual planeada) en un grupo de disponibilidad AlwaysOn mediante SQL Server Management Studio, Transact-SQL o PowerShell en SQL Server. Un grupo de disponibilidad realiza la conmutación por error en el nivel de una réplica de disponibilidad. Una conmutación por error manual programada, como cualquier conmutación por error de un grupo de disponibilidad Always On, convierte una réplica secundaria al rol principal. Al mismo tiempo, la conmutación por error convierte la réplica principal anterior en la réplica secundaria.

Una conmutación por error manual planificada solo se admite cuando la réplica principal y la réplica secundaria de destino se ejecutan en modo de confirmación sincrónica y están actualmente sincronizadas. Una conmutación por error manual planeada conserva todos los datos de las bases de datos secundarias que se unen al grupo de disponibilidad en la réplica secundaria de destino. Después de que la réplica principal antigua realiza la transición al rol secundario, sus bases de datos se convierten en bases de datos secundarias. A continuación, pueden empezar a sincronizarse con las bases de datos principales. Después de que todas realicen la transición al estado SYNCHRONIZED, la nueva réplica secundaria es apta para actuar como destino de una conmutación por error manual planeada futura.

Nota

Si las replicas principal y secundaria están ambas configuradas para el modo de conmutación automática por error, una vez que la réplica secundaria se sincroniza, también puede servir como destino de una conmutación automática por error. Para más información, consulte Modos de disponibilidad (grupos de disponibilidad AlwaysOn).

Antes de empezar

Importante

Hay procedimientos específicos para realizar la conmutación por error de un grupo de disponibilidad de escalado de lectura sin un administrador de clúster. Cuando un grupo de disponibilidad tiene CLUSTER_TYPE = NONE, siga los procedimientos que se describen en Conmutación por error de la réplica principal en un grupo de disponibilidad de escalado de lectura.

Limitaciones y restricciones

Requisitos previos y restricciones

  • La réplica secundaria de destino y la réplica principal deben ejecutarse en modo de disponibilidad de confirmación sincrónica.

  • Actualmente, la réplica secundaria de destino debe estar sincronizada con la réplica principal. Todas las bases de datos secundarias de esta réplica secundaria deben estar unidas al grupo de disponibilidad. También deben estar sincronizadas con sus bases de datos principales correspondientes (es decir, las bases de datos secundarias locales deben estar SINCRONIZADAS).

    Sugerencia

    Para determinar la preparación para la conmutación por error de una réplica secundaria, consulte la columna is_failover_ready en la vista de administración dinámica sys.dm_hadr_database_replica_cluster_states. O bien puede consultar la columna Preparación de la conmutación por error del panel del grupo Always On.

  • Esta tarea solo se admite en la réplica secundaria de destino. Debe estar conectado a la instancia del servidor que hospeda la réplica secundaria de destino.

Seguridad

Permisos

Se requiere el permiso ALTER AVAILABILITY GROUP en el grupo de disponibilidad. También se requiere el permiso CONTROL AVAILABILITY GROUP , el permiso ALTER ANY AVAILABILITY GROUP o el permiso CONTROL SERVER.

Uso de SQL Server Management Studio

Para realizar la conmutación por error manual de un grupo de disponibilidad:

  1. En el Explorador de objetos, conéctese a una instancia de servidor que albergue una réplica secundaria del grupo de disponibilidad sobre el que debe realizarse la conmutación por error. Expanda el árbol de servidores.

  2. Expanda los nodos Alta disponibilidad de AlwaysOn y Grupos de disponibilidad .

  3. Haga clic con el botón derecho en el grupo de disponibilidad que se va a conmutar por error y seleccione el comando Conmutación por error.

  4. Se inicia el asistente para la conmutación por error de grupos de disponibilidad. Para más información, consulte Usar el Asistente para el grupo de disponibilidad de conmutación por error (SQL Server Management Studio).

Uso de Transact-SQL

Para realizar una conmutación por error manual de un grupo de disponibilidad:

  1. Conéctese a la instancia del servidor que hospeda la réplica secundaria de destino.

  2. Use la ALTER AVAILABILITY GROUP sentencia, como se indica a continuación:

    ALTER AVAILABILITY GROUP group_name CONMUTACIÓN POR ERROR

    En la instrucción, group_name es el nombre del grupo de disponibilidad.

    En el ejemplo siguiente se realiza una conmutación por error manual del grupo de disponibilidad MyAg a la réplica secundaria conectada:

    ALTER AVAILABILITY GROUP MyAg FAILOVER;

Uso de PowerShell

Para realizar una conmutación por error manual de un grupo de disponibilidad:

  1. Cambie el directorio (cd) a la instancia del servidor que hospeda la réplica secundaria de destino.

  2. Use el cmdlet Switch-SqlAvailabilityGroup .

    Nota

    Para ver la sintaxis de un cmdlet, use el cmdlet Get-Help en el entorno de SQL Server PowerShell. Para más información, consulte Obtener ayuda de SQL Server PowerShell.

    En el ejemplo siguiente, se realiza manualmente una conmutación por error del grupo de disponibilidad MyAg a la réplica secundaria que tiene la ruta de acceso especificada:

    Switch-SqlAvailabilityGroup -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg

    Para configurar y usar el proveedor de SQL Server PowerShell:

Seguimiento: después de conmutar por error manualmente un grupo de disponibilidad

Si la conmutación por error se realizó fuera del conjunto de conmutación automática por error del grupo de disponibilidad, ajuste los votos de cuórum de los nodos del clúster de conmutación por error de Windows Server para que reflejen la nueva configuración del grupo de disponibilidad. Para más información, consulte Clústeres de conmutación por error de Windows Server (WSFC) con SQL Server.

Conmutar por error la réplica principal en un grupo de disponibilidad para escalado de lectura

Cada grupo de disponibilidad tiene solo una réplica principal. La réplica principal permite lecturas y escrituras. Para cambiar la réplica principal, puede efectuar una conmutación por error. En un grupo de disponibilidad típico, el administrador del clúster automatiza el proceso de conmutación por error. En un grupo de disponibilidad con el tipo de clúster NONE, el proceso de conmutación por error es manual.

Hay dos maneras de realizar la conmutación por error de la réplica principal en un grupo de disponibilidad con tipo de clúster NONE:

  • Conmutación por error manual sin pérdida de datos
  • Conmutación por error manual forzada con pérdida de datos

Conmutación por error manual sin pérdida de datos

Use este método si la réplica principal está disponible, pero necesita modificar temporal o permanentemente la instancia que hospeda dicha réplica principal. Para evitar una posible pérdida de datos, antes de iniciar la conmutación por error manual, asegúrese de que la réplica secundaria de destino esté actualizada.

Para realizar la conmutación por error manual sin pérdida de datos:

  1. Establezca la réplica principal actual y la réplica secundaria de destino en SYNCHRONOUS_COMMIT.

    ALTER AVAILABILITY GROUP [AGRScale] 
     MODIFY REPLICA ON N'<node2>' 
     WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);

  2. Ejecute la consulta siguiente para identificar que las transacciones activas se confirman en la réplica principal y en al menos una réplica secundaria sincrónica:

    SELECT ag.name, 
   drs.database_id, 
   drs.group_id, 
   drs.replica_id, 
   drs.synchronization_state_desc, 
   ag.sequence_number
FROM sys.dm_hadr_database_replica_states drs, sys.availability_groups ag
WHERE drs.group_id = ag.group_id;

    La réplica secundaria se sincroniza si synchronization_state_desc es SYNCHRONIZED.

  3. Actualice REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT a la versión 1.

    El siguiente script establece REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT en 1 en un grupo de disponibilidad denominado ag1. Antes de ejecutar el siguiente script, reemplace ag1 por el nombre del grupo de disponibilidad:

    ALTER AVAILABILITY GROUP [AGRScale] 
     SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 1);

    Esta configuración garantiza que cada transacción activa se confirme tanto en la réplica principal como en, al menos, una réplica secundaria sincrónica.

    Nota

    Esta configuración no es específica de la conmutación por error y debe establecerse en función de los requisitos del entorno.

  4. Ponga sin conexión la réplica principal y las réplicas secundarias que no participan en la conmutación por error para preparar el cambio de rol:

    ALTER AVAILABILITY GROUP [AGRScale] OFFLINE

  5. Ascienda la réplica secundaria de destino a principal.

    ALTER AVAILABILITY GROUP AGRScale FORCE_FAILOVER_ALLOW_DATA_LOSS;

  6. Actualice el rol de la réplica principal antigua y otras réplicas secundarias a SECONDARY, ejecute el comando siguiente en la instancia de SQL Server en la que se hospeda la réplica principal anterior:

    ALTER AVAILABILITY GROUP [AGRScale] 
     SET (ROLE = SECONDARY);

    Nota

    Para eliminar un grupo de disponibilidad, use DROP AVAILABILITY GROUP. Para un grupo de disponibilidad creado con el tipo de clúster NONE o EXTERNAL, ejecute el comando en todas las réplicas que forman parte del grupo de disponibilidad.

  7. Reanude el movimiento de datos, ejecute el siguiente comando para cada base de datos del grupo de disponibilidad en la instancia de SQL Server que hospeda la réplica principal:

    ALTER DATABASE [db1]
     SET HADR RESUME

  8. Vuelva a crear cualquier cliente de escucha que haya creado para fines de escalado de lectura y que no esté administrado por un administrador de clústeres. Si el listener original apunta al antiguo servidor principal, elimínelo y vuelva a crearlo para que apunte al nuevo servidor principal.

Conmutación por error manual forzada con pérdida de datos

Si la réplica principal no está disponible y no se puede recuperar de inmediato, debe forzar una conmutación por error a la réplica secundaria con pérdida de datos. Sin embargo, si la réplica principal original se recupera tras la conmutación por error, pasará a ostentar el rol principal. Para evitar que cada réplica esté en un estado diferente, quite la réplica principal original del grupo de disponibilidad después de una conmutación por error forzada con pérdida de datos. Una vez que la principal original vuelva a estar en línea, quite el grupo de disponibilidad al completo.

Para forzar una conmutación por error manual con pérdida de datos desde la réplica principal N1 hasta la réplica secundaria N2, siga estos pasos:

  1. En la réplica secundaria (N2), inicie una conmutación por error forzada:

    ALTER AVAILABILITY GROUP [AGRScale] FORCE_FAILOVER_ALLOW_DATA_LOSS;

  2. En la nueva réplica principal (N2), elimine la réplica principal original (N1):

    ALTER AVAILABILITY GROUP [AGRScale]
REMOVE REPLICA ON N'N1';

  3. Compruebe que todo el tráfico de la aplicación se dirija al listener y/o a la nueva réplica principal.

  4. Si el servidor principal original (N1) vuelve a estar en línea, ponga de inmediato fuera de línea el grupo de disponibilidad AGRScale en el servidor principal original (N1):

    ALTER AVAILABILITY GROUP [AGRScale] OFFLINE

  5. Si hay datos o cambios sin sincronizar, conserve dichos datos por medio de copias de seguridad u otras opciones de replicación de datos, en consonancia con los requisitos de su empresa.

  6. A continuación, elimine el grupo de disponibilidad del nodo principal original (N1):

    DROP AVAILABILITY GROUP [AGRScale];

  7. Anule la base de datos del grupo de disponibilidad de la réplica principal original (N1):

    USE [master]
GO
DROP DATABASE [AGDBRScale]
GO

  8. (Opcional) Si lo desea, ahora puede volver a agregar N1 como nueva réplica secundaria al grupo de disponibilidad AGRScale.

Consulte también

  • Last updated on