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:
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.
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
Use la conmutación por error entre SQL Server y el asistente Instancia administrada en SSMS para conmutar por error la base de datos de la réplica principal a la réplica secundaria.
Puede realizar una conmutación por error planeada desde la réplica principal o secundaria. Para realizar una conmutación por error forzada, conéctese a la réplica secundaria.
Precaución
Antes de realizar la conmutación por error, detenga la carga de trabajo en la base de datos de origen para permitir que la base de datos replicada se ponga completamente al día y realice la conmutación por error sin pérdida de datos. Si realiza una conmutación por error forzada, puede perder datos.
La conmutación por error de una base de datos en SQL Server 2019 y versiones anteriores interrumpe y quita el vínculo entre las dos réplicas. No se puede conmutar por recuperación a la principal inicial.
Para conmutar por error la base de datos, siga estos pasos:
Abra SSMS y conéctese a cualquiera de las réplicas.
En Explorador de objetos, haga clic con el botón derecho en la base de datos, mantenga el puntero sobre el vínculo de Azure SQL Managed Instance y seleccione Conmutación por error… para abrir el asistente de Base de datos de conmutación por error a la Instancia administrada. Si tiene varios vínculos de la misma base de datos, expanda Grupos de disponibilidad en Grupos de disponibilidad AlwaysOn en Explorador de objetos y haga clic con el botón derecho en el grupo de disponibilidad distribuido para el vínculo que desea conmutar por error. Seleccione Conmutación por error... para abrir la conmutación por error entre SQL Server y el asistente Instancia administrada para ese vínculo específico.
En la página Introducción, selecciona Siguiente.
En la página Elegir tipo de conmutación por error se muestran detalles sobre cada réplica, el rol de la base de datos seleccionada y los tipos de conmutación por error admitidos. Puede iniciar la conmutación por error desde cualquier réplica. Si elige una conmutación por error forzada, debe activar la casilla para indicar que puede haber una posible pérdida de datos. Seleccione Siguiente.
Nota:
Si va a migrar a Azure SQL Managed Instance, elija Conmutación por error planeada.
En la página Inicio de sesión en Azure e instancia remota:
Seleccione Iniciar sesión para proporcionar sus credenciales e iniciar sesión en su cuenta de Azure.
En función del tipo de conmutación por error seleccionado en la página anterior, la opción Iniciar sesión funciona de forma diferente. Para una conmutación por error planeada, es obligatorio iniciar sesión en la instancia remota (SQL Server o SQL Managed Instance). Para una conmutación por error forzada, la firma es opcional, ya que se admiten los dos escenarios siguientes:
Recuperación ante desastres verdadera: dado que la instancia principal no está disponible normalmente durante un desastre verdadero, no es posible iniciar sesión y el usuario debe conmutar por error a la instancia secundaria inmediatamente, lo que la convierte en la nueva instancia principal. Una vez resuelta la interrupción, el vínculo se encuentra en un estado incoherente, ya que ambas réplicas están ahora en el rol principal (escenario de cerebro dividido).
Exploración en profundidad de recuperación ante desastres: no se recomienda realizar simulacros de recuperación ante desastres con conmutación por error forzada, ya que podría provocar una posible pérdida de datos. Pero durante un simulacro, como la instancia principal está disponible, se admite el inicio de sesión y se le da la opción de invertir roles para ambas réplicas a fin de evitar el escenario de cerebro dividido.
En la página Operaciones posteriores a la conmutación por error, las opciones varían entre SQL Server 2022 y versiones anteriores, y también si pudo conectarse a la instancia principal.
Para SQL Server 2022, puede optar por detener la replicación entre réplicas, que anula el vínculo y el grupo de disponibilidad distribuido una vez completada la conmutación por error. Si desea mantener el vínculo y continuar replicando datos entre réplicas, deje la casilla desactivada. Si decide quitar el vínculo, también puede activar la casilla para quitar el grupo de disponibilidad si lo creó únicamente para replicar la base de datos en Azure y ya no la necesita. Active las casillas que se ajusten a su escenario y, a continuación, seleccione Siguiente.
Para SQL Server 2019 y versiones anteriores, la opción para Quitar el vínculo está activada de manera predeterminada y no se puede desactivar, ya que la conmutación por error a SQL Managed Instance detiene la replicación, interrumpe el vínculo y quita el grupo de disponibilidad distribuido. Active la casilla para indicar que comprende que se quitará el vínculo y, a continuación, seleccione Siguiente.
(Opcionalmente) Si pudo iniciar sesión en la instancia de SQL Server en la página anterior, también tiene la opción de eliminar el grupo de disponibilidad en la instancia de SQL Server después de una conmutación por error forzada; para ello, active la casilla en la sección Limpieza.
En la página Resumen, revise las acciones. Opcionalmente, seleccione Script para generar un script para que pueda conmutar por error fácilmente la base de datos con el mismo vínculo en el futuro. Seleccione Finalizar cuando esté listo para conmutar por error la base de datos.
Una vez finalizados todos los pasos, en la página Results (Resultados) se muestran marcas de comprobación junto a las acciones completadas correctamente. Ahora puede cerrar la ventana.
Si decide mantener el vínculo para SQL Server 2022, la base de datos secundaria se convierte en la nueva principal, el vínculo sigue activo y puede conmutar por recuperación a la secundaria.
Si está en SQL Server 2019 y versiones anteriores, o si decide quitar el vínculo de SQL Server 2022, el vínculo se quita y ya no existe después de que se complete la conmutación por error. La base de datos de origen y la base de datos de destino en cada réplica pueden ejecutar ambas una carga de trabajo de lectura/escritura. Son completamente independientes.
Importante
Tras una conmutación por error exitosa a SQL Managed Instance, vuelva a apuntar manualmente la cadena de conexión de su(s) aplicación(es) al FQDN de SQL Managed Instance para completar el proceso de migración o conmutación por error y continuar su ejecución en Azure.
Para conmutar por error, primero debe cambiar los modos de replicación de la instancia de SQL Server mediante Transact-SQL (T-SQL).
Después, puede conmutar por error y cambiar roles mediante PowerShell.
Cambio del modo de replicación (de Conmutación por error a SQL MI)
La replicación entre SQL Server y SQL Managed Instance es asincrónica de manera predeterminada. Si realiza la conmutación por error de SQL Server a Azure SQL Managed Instance, antes de conmutar por error la base de datos, cambie el vínculo al modo sincrónico en SQL Server mediante Transact-SQL (T-SQL).
Nota:
Omita este paso si realiza la conmutación por error desde SQL Managed Instance a SQL Server 2022.
La replicación sincrónica a través de grandes distancias de red puede ralentizar las transacciones en la réplica principal.
Ejecute el siguiente script de T-SQL en SQL Server para cambiar el modo de replicación del grupo de disponibilidad distribuido de async a sync. Reemplace:
<DAGName> por el nombre del grupo de disponibilidad distribuido (que se ha usado para crear el vínculo).
<AGName> por el nombre del grupo de disponibilidad creado en SQL Server (que se ha usado para crear el vínculo).
<ManagedInstanceName> por el nombre de la instancia administrada.
-- Run on SQL Server
-- Sets the distributed availability group to a synchronous commit.
-- ManagedInstanceName example: 'sqlmi1'
USE master
GO
ALTER AVAILABILITY GROUP [<DAGName>]
MODIFY
AVAILABILITY GROUP ON
'<AGName>' WITH
(AVAILABILITY_MODE = SYNCHRONOUS_COMMIT),
'<ManagedInstanceName>' WITH
(AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);
Para confirmar que ha cambiado correctamente el modo de replicación del vínculo, use la siguiente vista de administración dinámica. Los resultados indican el estado SYNCHRONOUS_COMMIT.
-- Run on SQL Server
-- Verifies the state of the distributed availability group
SELECT
ag.name, ag.is_distributed, ar.replica_server_name,
ar.availability_mode_desc, ars.connected_state_desc, ars.role_desc,
ars.operational_state_desc, ars.synchronization_health_desc
FROM
sys.availability_groups ag
join sys.availability_replicas ar
on ag.group_id=ar.group_id
left join sys.dm_hadr_availability_replica_states ars
on ars.replica_id=ar.replica_id
WHERE
ag.is_distributed=1
Ahora que ha cambiado SQL Server al modo de confirmación sincrónica, la replicación entre las dos instancias es sincrónica. Si necesita invertir este estado, siga los mismos pasos y establezca AVAILABILITY_MODE en ASYNCHRONOUS_COMMIT.
Comprobación de los valores LSN en SQL Server y SQL Managed Instance
Para completar la conmutación por error o la migración, confirme que la replicación a la instancia secundaria ha finalizado. Para ello, debe asegurarse de que los LSN (números de secuencia de registro) en las entradas de registro para SQL Server y SQL Managed Instance sean iguales.
Inicialmente, se espera que el LSN en la base de datos principal sea mayor que el LSN en la base de datos secundaria. La latencia de red puede provocar que la replicación se retrase un poco detrás de la principal. Dado que la carga de trabajo se ha detenido en la principal, pasado un tiempo los LSN coincidirán y dejarán de cambiar.
Use la siguiente consulta T-SQL en SQL Server para leer el número de secuencia de registro del último registro de transacciones registrado. Sustituya:
<DatabaseName> por el nombre de la base de datos, y busque el último número de secuencia de registro de seguridad (LSN) protegido.
-- Run on SQL Server
-- Obtain the last hardened LSN for the database on SQL Server.
SELECT
ag.name AS [Replication group],
db.name AS [Database name],
drs.database_id AS [Database ID],
drs.group_id,
drs.replica_id,
drs.synchronization_state_desc AS [Sync state],
drs.end_of_log_lsn AS [End of log LSN],
drs.last_hardened_lsn AS [Last hardened LSN]
FROM
sys.dm_hadr_database_replica_states drs
inner join sys.databases db on db.database_id = drs.database_id
inner join sys.availability_groups ag on drs.group_id = ag.group_id
WHERE
ag.is_distributed = 1 and db.name = '<DatabaseName>'
Use la siguiente consulta T-SQL en SQL Managed Instance para leer el último número de secuencia de registro de la base de datos. Reemplace <DatabaseName> por el nombre de su base de datos.
Esta consulta funciona en una SQL Managed Instance de uso general. Para una SQL Managed Instance crítica para la empresa, quite la marca de comentario and drs.is_primary_replica = 1 al final del script. En el nivel de servicio Crítico para la empresa, este filtro garantiza que los detalles solo se lean de la réplica principal.
-- Run on SQL managed instance
-- Obtain the LSN for the database on SQL Managed Instance.
SELECT
db.name AS [Database name],
drs.database_id AS [Database ID],
drs.group_id,
drs.replica_id,
drs.synchronization_state_desc AS [Sync state],
drs.end_of_log_lsn AS [End of log LSN],
drs.last_hardened_lsn AS [Last hardened LSN]
FROM
sys.dm_hadr_database_replica_states drs
inner join sys.databases db on db.database_id = drs.database_id
WHERE
db.name = '<DatabaseName>'
-- for Business Critical, add the following as well
-- AND drs.is_primary_replica = 1
Como alternativa, también podría utilizar el comando Get-AzSqlInstanceLink de PowerShell o az sql mi link show de la CLI de Azure para obtener la propiedad LastHardenedLsn de su enlace en SQL Managed Instance para proporcionar la misma información que la consulta T-SQL anterior.
Importante
Verifique una vez más que su carga de trabajo está detenida en la principal. Compruebe que los LSN de SQL Server y SQL Managed Instance coinciden, y que permanecen coincidentes y sin cambios durante algún tiempo. Los LSN estables en ambas instancias indican que el registro final se ha replicado en la secundaria y que la carga de trabajo se ha detenido correctamente.
Conmutación por error de una base de datos
Si quiere usar PowerShell para conmutar por error una base de datos entre SQL Server 2022 y SQL Managed Instance mientras mantiene el vínculo, o para realizar una conmutación por error con pérdida de datos para cualquier versión de SQL Server, use el asistente para la conmutación por error entre SQL Server e Instancia administrada en SSMS a fin de generar el script para su entorno. Puede realizar una conmutación por error planeada desde la réplica principal o secundaria. Para realizar una conmutación por error forzada, conéctese a la réplica secundaria.
Para interrumpir el vínculo y detener la replicación al conmutar por error o migrar la base de datos independientemente de la versión de SQL Server, use el comando Remove-AzSqlInstanceLink de PowerShell o az sql mi link delete de la CLI de Azure.
Precaución
Antes de realizar la conmutación por error, detenga la carga de trabajo en la base de datos de origen para permitir que la base de datos replicada se ponga completamente al día y realice la conmutación por error sin pérdida de datos. Si realiza una conmutación por error forzada o si interrumpe el vínculo antes de que coincidan los LSN, podría perder datos.
La conmutación por error de una base de datos en SQL Server 2019 y versiones anteriores interrumpe y quita el vínculo entre las dos réplicas. No se puede conmutar por recuperación a la principal inicial.
El siguiente script de ejemplo interrumpe el vínculo y finaliza la replicación entre las réplicas, lo que hace que la base de datos lea y escriba en ambas instancias. Sustituya:
<ManagedInstanceName> por el nombre de la instancia administrada.
<DAGName> por el nombre del vínculo con el que se realiza la conmutación por error (salida de la propiedad Name del comando Get-AzSqlInstanceLink ejecutado anteriormente).
# Run in Azure Cloud Shell (select PowerShell console)
# =============================================================================
# POWERSHELL SCRIPT TO FAIL OVER OR MIGRATE DATABASE TO AZURE
# ===== Enter user variables here ====
# Enter your managed instance name – for example, "sqlmi1"
$ManagedInstanceName = "<ManagedInstanceName>"
$LinkName = "<DAGName>"
# ==== Do not customize the following cmdlet ====
# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName
# Failover the specified link
Remove-AzSqlInstanceLink -ResourceGroupName $ResourceGroup |
-InstanceName $ManagedInstanceName -Name $LinkName -Force
Cuando el proceso de conmutación por error funciona, el vínculo se anula y deja de existir. Tanto la base de datos de SQL Server como la base de datos de SQL Managed Instance pueden ejecutar cargas de trabajo de lectura y escritura porque ahora son completamente independientes.
Importante
Tras una conmutación por error exitosa a SQL Managed Instance, vuelva a apuntar manualmente la cadena de conexión de su(s) aplicación(es) al FQDN de SQL Managed Instance para completar el proceso de migración o conmutación por error y continuar su ejecución en Azure.
Después de quitar el vínculo, puede mantener el grupo de disponibilidad en SQL Server, pero debe quitar el grupo de disponibilidad distribuido para quitar los metadatos de vínculo de SQL Server. Este paso adicional solo es necesario cuando se realiza la conmutación por error mediante PowerShell, ya que SSMS realiza esta acción automáticamente.
Para anular el grupo de disponibilidad distribuido, reemplace el siguiente valor y, después, ejecute el código T-SQL de ejemplo:
<DAGName> por el nombre del grupo de disponibilidad distribuido en SQL Server (que se ha usado para crear el vínculo).
-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <DAGName>
GO
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
Azure SQL Managed Instance