Ler en inglés

Compartir por


Vínculo de conmutación por error: Azure SQL Managed Instance

Se aplica a: Azure SQL Managed Instance

Este artículo le enseña a conmutar por error una base de datos vinculada entre SQL Server y Azure SQL Managed Instance mediante SQL Server Management Studio (SSMS) o PowerShell a efectos de recuperación ante desastres o migración.

Requisitos previos

Para conmutar por error las bases de datos a la réplica secundaria mediante el vínculo, necesita los siguientes requisitos previos:

Detener carga de trabajo

Si está a punto para conmutar por error la base de datos a la réplica secundaria, detenga primero las cargas de trabajo de la aplicación en la réplica principal durante las horas de mantenimiento. Esto permite que la replicación de base de datos se actualice en la base de datos secundaria para que pueda conmutar por error a la base de datos secundaria sin pérdida de datos. Asegúrese de que las aplicaciones no confirman transacciones en la principal antes de conmutar por error.

Conmutación por error de una base de datos

Puede conmutar por error una base de datos vinculada mediante Transact-SQL (T-SQL), SQL Server Management Studio o PowerShell.

Puede conmutar por error el vínculo mediante Transact-SQL a partir de SQL Server 2022 CU13 (KB5036432).

Para realizar un conmutación por error planeada para un vínculo, use el siguiente comando de T-SQL en la réplica principal:

ALTER AVAILABILITY GROUP [<DAGname>] FAILOVER

Para realizar una conmutación por error forzada, use el siguiente comando de T-SQL en la réplica secundaria:

ALTER AVAILABILITY GROUP [<DAGname>] FORCE_FAILOVER_ALLOW_DATA_LOSS

Ver la base de datos tras la conmutación por error

En SQL Server 2022, si decide mantener el vínculo, puede comprobar que el grupo de disponibilidad distribuido existe en Grupos de disponibilidad, en el Explorador de objetos en SQL Server Management Studio.

Si anuló el vínculo durante la conmutación por error, puede usar Explorador de objetos para confirmar que el grupo de disponibilidad distribuido ya no existe. Si decide mantener el grupo de disponibilidad, la base de datos seguirá estando Sincronizada.

Limpieza después de la conmutación por error

A menos que se seleccione Quitar vínculo después de la conmutación por error correcta, la conmutación por error con SQL Server 2022 no interrumpe el vínculo. Puede mantener el vínculo después de la conmutación por error, que deja activos el grupo de disponibilidad y el grupo de disponibilidad distribuido. No es necesario realizar ninguna acción adicional.

Anular el vínculo solo anula el grupo de disponibilidad distribuido y deja activo el grupo de disponibilidad. Puede decidir mantener el grupo de disponibilidad o anularlo.

Si decide anular el grupo de disponibilidad, reemplace el siguiente valor y, luego, ejecute el código T-SQL de ejemplo:

  • <AGName> por el nombre del grupo de disponibilidad en SQL Server (que se ha usado para crear el vínculo).
-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <AGName> 
GO

Estado incoherente después de la conmutación por error forzada

Después de una conmutación por error forzada, podría encontrarse con un escenario de cerebro dividido en el que ambas réplicas están en el rol principal, dejando el vínculo en un estado incoherente. Esto puede ocurrir si conmuta por error a la réplica secundaria durante un desastre y, a continuación, la réplica principal vuelve a estar en línea.

En primer lugar, confirme que está en un escenario de cerebro dividido. Para ello, puede usar Transact-SQL (T-SQL) o SQL Server Management Studio (SSMS).

Conéctese tanto a SQL Server como a SQL Managed Instance en SSMS y, a continuación, en Explorador de objetos, expanda Réplicas de disponibilidad en el nodo Grupo de disponibilidad en Alta disponibilidad AlwaysOn. Si se muestran dos réplicas diferentes como (principal), se encuentra en un escenario de cerebro dividido.

Como alternativa, puede ejecutar el siguiente script de T-SQL en ambos, SQL Server y SQL Managed Instance, para comprobar el rol de las réplicas:

-- Execute on SQL Server and SQL Managed Instance 

declare @link_name varchar(max) = '<DAGName>' 
USE MASTER 
GO

SELECT
   ag.name [Link name], 
   rs.role_desc [Link role] 
FROM
   sys.availability_groups ag 
   join sys.dm_hadr_availability_replica_states rs 
   on ag.group_id = rs.group_id 
WHERE 
   rs.is_local = 1 and ag.name = @link_name 
GO

Si ambas instancias muestran una principal diferente en la columna Vincular rol, se encuentra en un escenario de cerebro dividido.

Para resolver el estado del cerebro dividido, primero realice una copia de seguridad en la réplica que sea la principal original. Si la principal original era SQL Server, realice una copia de seguridad del final del registro. Si la principal original era SQL Managed Instance, realice una copia de seguridad completa de solo copia. Una vez completada la copia de seguridad, establezca el grupo de disponibilidad distribuido en el rol secundario de la réplica que solía ser la principal original, pero ahora será la nueva secundaria.

Por ejemplo, en caso de un desastre verdadero, suponiendo que ha forzado una conmutación por error de la carga de trabajo de SQL Server a Azure SQL Managed Instance, y tiene previsto seguir ejecutando la carga de trabajo en SQL Managed Instance, realice una copia de seguridad del final del registro en SQL Server y, a continuación, establezca el grupo de disponibilidad distribuido en el rol secundario en SQL Server, como el ejemplo siguiente:

--Execute on SQL Server 
USE MASTER

ALTER availability group [<DAGName>] 
SET (role = secondary) 
GO 

A continuación, ejecute una conmutación por error manual planeada de SQL Managed Instance a SQL Server mediante el vínculo, como el ejemplo siguiente:

--Execute on SQL Managed Instance 
USE MASTER

ALTER availability group [<DAGName>] FAILOVER 
GO 

Para usar el vínculo:

Para más información sobre el vínculo:

Para otros escenarios de replicación y migración, considere lo siguiente: