Conmutación por error manual iniciada por el usuario en SQL Managed Instance

  • Artículo

Se aplica a:Azure SQL Managed Instance

En este artículo se explica cómo realizar una conmutación por error manual de un nodo principal en los niveles de servicio De uso general (GP) y Crítico para la empresa (BC) de SQL Managed Instance, y cómo realizar una conmutación por error manual de un nodo de réplica de solo lectura secundario únicamente en el nivel de servicio BC.

Nota:

Este artículo no está relacionado con las conmutaciones por error entre regiones en grupos de conmutación por error.

Cuando se debe usar la conmutación por error manual

La alta disponibilidad es una parte fundamental de la plataforma SQL Managed Instance que funciona de modo transparente para las aplicaciones de base de datos. Las conmutaciones por error desde nodos principales a secundarios en caso de degradación del nodo o de detección de errores, o durante las actualizaciones de software mensuales habituales son hechos esperados para todas las aplicaciones que usan SQL Managed Instance en Azure.

Puede considerar la posibilidad de ejecutar una conmutación por error manual en SQL Managed Instance por algunos de los siguientes motivos:

  • Probar la resistencia de la conmutación por error de la aplicación antes de realizar la implementación en producción
  • Probar la resistencia frente a errores de sistemas de un extremo a otro en conmutaciones por error automáticas
  • Probar cómo afecta la conmutación por error a las sesiones de base de datos existentes
  • Comprobar si una conmutación por error cambia el rendimiento de un extremo a otro debido a los cambios en la latencia de la red
  • En algunos casos de degradación del rendimiento de las consultas, la conmutación por error manual puede ayudar a mitigar el problema de rendimiento.

Nota:

Asegurarse de que las aplicaciones sean resistentes a la conmutación por error antes de la implementación en producción ayuda a mitigar el riesgo de errores de la aplicación en producción y contribuye a la disponibilidad de la aplicación para los clientes. Puedes encontrar más información sobre cómo probar la preparación de las aplicaciones para la nube con la grabación de vídeo Prueba de la preparación de las aplicaciones en la nube para la resistencia a la conmutación por error con SQL Managed Instance.

Inicio manual de la conmutación por error en SQL Managed Instance

Se requieren permisos de RBAC de Azure

Los usuarios que inician una conmutación por error deben tener uno de los roles de Azure siguientes:

  • Rol Propietario de la suscripción, o
  • Rol de colaborador de SQL Managed Instance o
  • Rol personalizado con el siguiente permiso:
    • Microsoft.Sql/managedInstances/failover/action

Usar PowerShell

La versión mínima de Az.Sql debe ser v2.9.0. Considere la posibilidad de usar Azure Cloud Shell del Azure Portal que siempre tiene disponible la versión más reciente de PowerShell.

Como requisito previo, use el siguiente script de PowerShell para instalar los módulos de Azure necesarios. Además, selecciona la suscripción en la que se encuentra la instancia administrada de SQL Managed Instance de la que quieres realizar la conmutación por error.

$subscription = 'enter your subscription ID here'
Install-Module -Name Az
Import-Module Az.Accounts
Import-Module Az.Sql

Connect-AzAccount
Select-AzSubscription -SubscriptionId $subscription

Use el comando de PowerShell Invoke-AzSqlInstanceFailover con el ejemplo siguiente para iniciar la conmutación por error del nodo principal, aplicable al nivel de servicio BC y GP.

$ResourceGroup = 'enter resource group of your MI'
$ManagedInstanceName = 'enter MI name'
Invoke-AzSqlInstanceFailover -ResourceGroupName $ResourceGroup -Name $ManagedInstanceName

Usa el siguiente comando de PowerShell para conmutar por error el nodo secundario de lectura, aplicable solo al nivel de servicio BC.

$ResourceGroup = 'enter resource group of your MI'
$ManagedInstanceName = 'enter MI name'
Invoke-AzSqlInstanceFailover -ResourceGroupName $ResourceGroup -Name $ManagedInstanceName -ReadableSecondary

Uso de CLI

Asegúrese de tener instalados los scripts más recientes de la CLI.

Use el comando az sql mi failover de la CLI con el siguiente ejemplo para iniciar la conmutación por error del nodo principal, aplicable al nivel de servicio BC y GP.

az sql mi failover -g myresourcegroup -n myinstancename

Use el siguiente comando de la CLI para conmutar por error el nodo secundario de lectura, aplicable solo al nivel de servicio BC.

az sql mi failover -g myresourcegroup -n myinstancename --replica-type ReadableSecondary

Uso de la API de REST

Para los usuarios avanzados, que quizás necesiten automatizar las conmutaciones por error de sus SQL Managed Instance con el fin de implementar una canalización de pruebas continua, o mitigadores de rendimiento automatizados, esta función se puede lograr mediante el inicio de la conmutación por error a través de una llamada de API. Consulta Instancias administradas de SQL Managed Instances: API de REST de conmutación por error para obtener más información.

Para iniciar la conmutación por error mediante una llamada API de REST, primero genere el token de autenticación con el cliente de API de su elección. El token de autenticación generado se usa como propiedad de autorización en el encabezado de la solicitud de API y es obligatorio.

El siguiente código es un ejemplo de URI de API de llamada:

POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Sql/managedInstances/{managedInstanceName}/failover?api-version=2019-06-01-preview

Las siguientes propiedades deben pasarse en la llamada API:

Propiedad de API Parámetro
subscriptionId Id. de suscripción en el que se implementa la instancia administrada.
resourceGroupName Grupo de recursos que contiene la instancia administrada.
managedInstanceName Nombre de instancia administrada.
replicaType (Opcional) (Primary o ReadableSecondary). Estos parámetros representan el tipo de réplica que se va a conmutar por error: principal o secundaria legible. Si no se especifica, la conmutación por error se inicia en la réplica principal de forma predeterminada.
api-version Valor estático y actualmente debe ser "2019-06-01-preview".

La API responde con una de las dos siguientes:

  • 202 - Aceptado
  • Uno de los errores de solicitud 400.

Se puede realizar un seguimiento del estado de la operación mediante la revisión de las respuestas de la API en los encabezados de respuesta. Para obtener más información, consulte Estado de las operaciones asincrónicas de Azure.

Supervisión de la conmutación por error

Para supervisar el progreso de la conmutación por error iniciada por el usuario para la instancia de BC, ejecute la siguiente consulta T-SQL en su cliente favorito (como SSMS) en SQL Managed Instance. Lee la vista del sistema sys.dm_hadr_fabric_replica_states y las réplicas de informe disponibles en la instancia. Actualice la misma consulta después de iniciar la conmutación por error manual.

SELECT DISTINCT replication_endpoint_url, fabric_replica_role_desc FROM sys.dm_hadr_fabric_replica_states

Antes de iniciar la conmutación por error, el resultado indica la réplica principal actual en el nivel de servicio de BC que contiene una principal y tres secundarias en el grupo de disponibilidad Always On. Tras la ejecución de una conmutación por error, para volver a ejecutar esta consulta necesitará indicar un cambio del nodo principal.

No podrás ver el mismo resultado con el nivel de servicio GP que el anterior que se muestra para BC. Esto se debe a que el nivel de servicio GP se basa en un solo nodo. Puede usar una consulta T-SQL alternativa que muestre la hora en que se inició el proceso SQL en el nodo de la instancia de nivel de servicio de GP:

SELECT sqlserver_start_time, sqlserver_start_time_ms_ticks FROM sys.dm_os_sys_info

La breve pérdida de conectividad del cliente durante la conmutación por error, que normalmente dura menos de un minuto, es la indicación de la ejecución de la conmutación por error independientemente del nivel de servicio.

Nota:

La finalización del proceso de conmutación por error (no de la breve falta de disponibilidad real) puede tardar varios minutos en el caso de cargas de trabajo de alta intensidad. Esto se debe a que el motor de la instancia se encarga de todas las transacciones actuales en la principal y se pone al día en el nodo secundario, antes de poder realizar la conmutación por error.

Importante

Limitaciones funcionales de la conmutación por error manual iniciada por el usuario:

  • Podría haber una (1) conmutación por error iniciada en la misma instancia administrada de SQL Managed Instance cada 15 minutos.
  • En el caso de las instancias de BC, debe existir cuórum de réplicas para que se acepte la solicitud de conmutación por error.
  • En el caso de las instancias de BC, no es posible especificar en qué réplica secundaria legible se iniciará la conmutación por error.
  • No se permitirá la conmutación por error hasta que los sistemas de copia de seguridad automatizada completen la primera copia de seguridad completa para una nueva base de datos.
  • No se permitirá la conmutación por error si existe una restauración de la base de datos en curso.

Pasos siguientes