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.
Para conmutar por error las bases de datos a la réplica secundaria mediante el vínculo, necesita los siguientes requisitos previos:
- Una suscripción de Azure activa. En caso de no tener ninguna, cree una cuenta gratuita.
- Versión compatible de SQL Server con la actualización de servicio necesaria instalada.
- Vínculo configurado entre la réplica principal y la secundaria.
- Puede conmutar por error el vínculo mediante Transact-SQL a partir de SQL Server 2022 CU13 (KB5036432).
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.
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
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.
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
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:
- Preparación del entorno para el vínculo de instancia administrada
- Configuración del vínculo entre SQL Server y SQL Managed Instance con SSMS
- Configuración del vínculo entre SQL Server y SQL Managed Instance con scripts
- Migración con el vínculo
- Procedimientos recomendados para el mantenimiento del vínculo
Para más información sobre el vínculo:
- Vínculo de Instancia administrada: información general
- Recuperación ante desastres con vínculo de instancia administrada
Para otros escenarios de replicación y migración, considere lo siguiente: