Compartir a través de

Reinicio de una instancia con una conmutación por error manual iniciada por el usuario: Azure SQL Managed Instance

Se aplica a:Azure SQL Managed Instance

En este artículo se explica cómo reiniciar Instancia administrada de Azure SQL mediante la realización de una conmutación por error manual iniciada por el usuario mediante PowerShell, la CLI de Azure o la API REST.

Es posible realizar una conmutación por error de un nodo principal en los niveles de servicio De uso general (GP) y Crítico para la empresa (BC) y realizar una conmutación por error manual de un nodo de réplica de solo lectura secundario en el nivel de servicio BC.

Nota:

La conmutación por error de este artículo hace referencia a reiniciar el proceso del motor de base de datos de SQL Server y no está relacionado con la conmutación por error entre regiones de un grupo de conmutación por error.

Cuando se debe usar la conmutación por error manual

La disponibilidad, una parte fundamental de la plataforma de SQL Managed Instance, funciona de forma transparente para las aplicaciones de base de datos proporcionando nodos de proceso en espera locales para hospedar el proceso del motor de base de datos de SQL Server. Se produce una conmutación por error cuando el proceso del motor de base de datos de SQL Server se desconecta y se pone en línea en el mismo nodo de ejecución u otro nodo de ejecución. Normalmente, las conmutaciones por error son automáticas y administradas por la plataforma Azure cuando se detecta un error, un nodo se ha degradado o durante las actualizaciones del servicio.

Toda la operación de conmutación por falla consiste en activar el proceso del motor de base de datos de SQL Server, validar el estado de la base de datos y, finalmente, redirigir las conexiones de cliente al nuevo proceso de SQL Server. Las conexiones de cliente solo fallan durante un breve período de tiempo, normalmente menos de un minuto, durante el paso final de la operación de conmutación por error.

Puede ejecutar una conmutación por error manual para reiniciar el proceso del motor por los siguientes motivos:

  • Inicios de sesión con errores o lentitud debido a problemas de rendimiento.
  • Pruebe la resistencia de la conmutación por error de la aplicación antes de realizar la implementación en producción.
  • Pruebe la resistencia frente a errores de sistemas de un extremo a otro en conmutaciones por error automáticas.
  • Pruebe cómo afecta la conmutación por error a las sesiones de base de datos existentes.
  • Degradación del rendimiento de las consultas (reiniciar la instancia puede ayudar a mitigar el problema de rendimiento).

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. Obtenga más información sobre cómo probar las aplicaciones para la preparación de la nube con el vídeo siguiente:

En la tabla siguiente se describe el comportamiento esperado de SQL Managed Instance durante una operación de conmutación por error en función del nivel de servicio y del modelo de disponibilidad:

Nivel de servicio Modelo de disponibilidad Comportamiento de conmutación por error esperado Posible comportamiento de conmutación por error (excepciones)
Uso general Redundancia local
(Zona de disponibilidad única)		 El proceso de SQL se reinicia en la misma máquina virtual. El proceso de SQL se reinicia en una máquina virtual diferente.
Uso general Redundancia de zona
(varias zonas de disponibilidad)		 El proceso de SQL se reinicia en la misma máquina virtual. El proceso de SQL se reinicia en una máquina virtual diferente.
Crítico para la empresa Redundancia local
(Zona de disponibilidad única)		 El proceso de SQL se reinicia en la réplica principal o se promueve una réplica secundaria aleatoria a principal. N/D
Crítico para la empresa Redundancia de zona
(varias zonas de disponibilidad)		 El procedimiento de SQL se reinicia en la réplica principal o la réplica secundaria aleatoria se promueve a principal, ya sea en la misma zona de disponibilidad o en otra. N/D

Permisos

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

  • 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

Reinicio de una instancia con una conmutación por error manual

Puede reiniciar una instancia con un failover manual mediante PowerShell, Azure CLI o REST API.

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, seleccione la suscripción en la que se encuentra la SQL Managed Instance de la que quiere 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

Use 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

Supervisión de la conmutación por error

La supervisión del progreso de una conmutación por error iniciada por el usuario difiere en las instancias de los niveles de servicio De uso general y Crítico para la empresa.

Para supervisar el progreso de una conmutación por error iniciada por el usuario, utilice:

  • sys.dm_os_sys_info para comprobar el tiempo de actividad del sistema para el nivel de servicio De uso general.
  • sys.dm_hadr_fabric_replica_states para comprobar las réplicas disponibles para el nivel de servicio Crítico para la empresa.

El último paso del proceso de conmutación por error es la redirección de las conexiones de cliente al nuevo nodo principal. La breve pérdida de conectividad del cliente durante la conmutación por error, que suele durar menos de un minuto, indica que la conmutación por error se ha realizado correctamente, independientemente del nivel de servicio.

Nivel de servicio de uso general

En el ejemplo de T-SQL siguiente se muestra el tiempo de actividad del proceso SQL en el nodo para el nivel de servicio De uso general:

SELECT sqlserver_start_time, sqlserver_start_time_ms_ticks FROM sys.dm_os_sys_info

La hora de inicio del proceso de SQL es la hora en que se inició el proceso del motor de base de datos de SQL Server en el nodo, que se actualiza después de cada conmutación por error. Ejecute esta consulta antes y después de iniciar una conmutación por error de una instancia en el nivel de servicio De uso general para supervisar el progreso de la operación de conmutación por error.

Nivel de servicio Crítico para la empresa

En el siguiente ejemplo de T-SQL se indica qué nodo es actualmente la réplica principal del nivel de servicio Crítico para la empresa:

SELECT DISTINCT replication_endpoint_url, fabric_replica_role_desc FROM sys.dm_hadr_fabric_replica_states

El nodo que hospeda la réplica principal cambia una vez completada la conmutación por error. Ejecute esta consulta antes y después de iniciar una conmutación por error de una instancia en el nivel de servicio Crítico para la empresa para supervisar el progreso de la operación de conmutación por error.

Nota:

El proceso de conmutación por error completa puede tardar varios minutos en completarse durante cargas de trabajo de alta intensidad, ya que el motor de instancia garantiza que las transacciones en el nodo secundario se detecten en las transacciones del nodo principal antes de iniciar la conmutación por error.

Limitaciones

Tenga en cuenta las siguientes limitaciones funcionales de la conmutación por error manual iniciada por el usuario:

  • Solo puede haber una conmutación por error (1) iniciada en la misma instancia administrada de SQL cada 15 minutos.
  • No se permiten conmutaciones por error:
    • Hasta que los sistemas de copia de seguridad automatizada completen la primera copia de seguridad completa para una nueva base de datos.
    • si hay una restauración de la base de datos en curso.
  • Por ejemplo, en el nivel de servicio Crítico para la empresa:
    • Las réplicas deben tener un cuórum antes de que se acepte una solicitud de conmutación por error.
    • El comando Invoke-AzSqlInstanceFailover conmuta la réplica principal a menos que se especifique -ReadableSecondary, en cuyo caso se conmuta la réplica secundaria legible. Las réplicas secundarias ilegibles no realizan conmutación por error cuando se emite este comando.

Contenido relacionado