Compartir vía

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

  • Artículo

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 réplica de disponibilidad. Una conmutación por error planeada, al igual que cualquier conmutación por error de un grupo de disponibilidad AlwaysOn, realiza la transición de una réplica secundaria a un rol principal. Al mismo tiempo, la conmutación por error realiza la transición de la réplica principal antigua al rol secundario.

Una conmutación por error manual planeada 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 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

Existen procedimientos específicos para la conmutación por error de un grupo de disponibilidad de escalado de lectura sin administrador de clústeres. 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 e administración dinámica sys.dm_hadr_database_replica_cluster_states. O bien, puede examinar la columna Preparación de la conmutación por error del panel de grupos AlwaysOn.

  • 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 requieren los permisos CONTROL AVAILABILITY GROUP, ALTER ANY AVAILABILITY GROUP o CONTROL SERVER.

Use 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 hospede una réplica secundaria del grupo de disponibilidad que es necesario conmutar 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 grupo de disponibilidad de conmutación por error (SQL Server Management Studio).

Uso de Transact-SQL

Para realizar la 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 instrucción ALTER AVAILABILITY GROUP del siguiente modo:

    ALTER AVAILABILITY GROUP group_name FAILOVER

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

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

    ALTER AVAILABILITY GROUP MyAg FAILOVER;

Uso de PowerShell

Para realizar la 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 produjo fuera del grupo de disponibilidad de conjunto de conmutación automática por error, ajuste los votos de cuórum de los nodos de clúster de Windows Server para reflejar 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.

Conmutación por error de la réplica principal en un grupo de disponibilidad de 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 habitual, el administrador de clústeres 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 efectuar una conmutación por error de la réplica principal en un grupo de disponibilidad de 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. Antes de emitir la conmutación por error manual, asegúrese de que la réplica secundaria de destino está actualizada para evitar una posible pérdida de datos.

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

  1. Establezca las réplicas de destino principal y secundaria actuales 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 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);

    Este valor garantiza que todas las transacciones activas se confirman en la réplica principal y en, al menos, una réplica secundaria sincrónica.

    Nota

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

  4. Establezca la réplica principal y las réplicas secundarias que no participan en la conmutación por error sin conexión para prepararse para 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 cliente de escucha original apunta a la réplica principal anterior, suéltela y vuelva a crearla para que apunte a la nueva réplica 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 justo en ese momento, deberá forzar una conmutación por error en la 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 discrepancias en los estados de las réplicas, quite la principal original del grupo de disponibilidad tras haber forzado la conmutación por error 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 de la réplica principal N1 a la 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), quite la principal original (N1):

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

  3. Valide que el tráfico de todas las aplicaciones apunte al cliente de escucha o la nueva réplica principal.

  4. Si la principal original (N1) está en línea, desconecte el grupo de disponibilidad AGRScale de la principal original (N1) de inmediato:

    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. Luego, quite el grupo de disponibilidad de la 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 quiere, ahora puede volver a agregar N1 como nueva réplica secundaria al grupo de disponibilidad AGRScale.

Consulte también