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 Azure SQL Managed Instance mediante la realización de una conmutación por error manual iniciada por el usuario en un nodo de proceso secundario 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 al inicio del proceso del motor de base de datos de SQL Server en un nodo secundario y no está relacionado con la conmutación por error entre regiones de los grupos 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 en el nodo de proceso principal y se pone en línea en un nodo de proceso secundario. Normalmente, las conmutaciones por error entre los nodos de proceso de SQL Managed Instance son automáticas y están administradas por la plataforma cuando se detecta un error, un nodo se ha degradado o durante las actualizaciones de software mensuales normales.
Toda la operación de conmutación por error consiste en poner en línea el proceso del motor de base de datos de SQL Server en un nodo secundario, validar el estado de la base de datos y, después, redirigir las conexiones de cliente al nuevo nodo principal. Las conexiones de cliente solo producen un error durante un breve período de tiempo, normalmente por debajo 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 en un nodo diferente 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 los 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 esperado de conmutación por error | 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 (versión preliminar) (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) |
La réplica secundaria aleatoria se promueve a principal. | N/D |
| Crítico para la empresa | Redundancia de zona (varias zonas de disponibilidad) |
La réplica secundaria aleatoria se promueve a la 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 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
Reinicio de una instancia con una conmutación por error manual
Puede reiniciar una instancia con una conmutación por error manual mediante PowerShell, la CLI de Azure o la API REST.
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
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, use:
- 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_statespara 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 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.
Nivel de servicio 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. El tiempo se reinicia 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 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 (1) conmutación por error iniciada en la misma instancia administrada de SQL Managed Instance 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.
- Para las instancias del nivel de servicio Crítico para la empresa:
- Debe existir cuórum de réplicas para que se acepte la solicitud de conmutación por error.
- No es posible especificar en qué réplica secundaria legible se iniciará la conmutación por error.
Contenido relacionado
- 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.
- Obtenga más información sobre la alta disponibilidad de la instancia administrada en Alta disponibilidad para Azure SQL Managed Instance.
- Para obtener información general, consulte ¿Qué es Azure SQL Managed Instance?.