Introducción a los grupos de conmutación por error automática y procedimientos recomendados (Azure SQL Managed Instance)

SE APLICA A: Migración a Azure SQL Managed Instance

La característica de los grupos de conmutación por error automática permite administrar la replicación y la conmutación por error en otra región de Azure de todas las bases de datos de usuario de una instancia administrada. Este artículo se centra en el uso de la característica de grupo de conmutación por error automática con Azure SQL Managed Instance y algunos procedimientos recomendados.

Para empezar, consulte el artículo sobre la configuración de grupos de conmutación por error automática. Si desea una experiencia completa, consulte el tutorial sobre los grupos de conmutación por error automática.

Nota:

En este artículo, se describen los grupos de conmutación por error automática para Azure SQL Managed Instance. Para Azure SQL Database, consulte el artículo sobre los grupos de conmutación por error automática en SQL Database.

Información general

La característica de los grupos de conmutación por error automática permite administrar la replicación y la conmutación por error en otra región de Azure de un grupo de bases de datos en un servidor o de todas las bases de datos de usuario de una instancia administrada. Se trata de una abstracción declarativa sobre la característica de replicación geográfica activa, diseñada para simplificar la implementación y administración de bases de datos con replicación geográfica a gran escala.

Conmutación por error automática

Puede iniciar la conmutación por error geográfica manualmente o puede delegarla en el servicio de Azure según una directiva definida por el usuario. La última opción le permite recuperar automáticamente varias bases de datos relacionadas en una región secundaria después de errores catastróficos u otros eventos no planeados que generen una pérdida total o parcial de la disponibilidad de SQL Database o Instancia administrada de SQL en la región primaria. Normalmente, se trata de interrupciones que la infraestructura de alta disponibilidad integrada no puede mitigar automáticamente. Entre los ejemplos de desencadenadores de conmutación por error geográfica se incluyen los desastres naturales o los incidentes a causa de un inquilino o un anillo de control fuera de servicio debido a una fuga de memoria del kernel del SO en los nodos de ejecución. Para más información, consulte Alta disponibilidad de Azure SQL.

Descarga de cargas de trabajo de solo lectura

Para reducir el tráfico a sus bases de datos principales, también puede utilizar las bases de datos secundarias de un grupo de conmutación por error para descargar cargas de trabajo de solo lectura. Utilice el cliente de escucha de solo lectura para dirigir el tráfico de solo lectura a una base de datos secundaria legible.

Redireccionamiento de punto de conexión

Los grupos de conmutación por error automática proporcionan puntos de conexión de agentes de escucha de lectura-escritura y de solo lectura que no se modifican durante las conmutaciones por error con replicación geográfica. Esto significa que no es necesario cambiar la cadena de conexión de la aplicación después de una conmutación por error geográfica, porque las conexiones se enrutan automáticamente a la región primaria actual. Por lo tanto, ya sea que use la activación de conmutación por error automática o manual, la conmutación por error geográfica cambia todas las bases de datos secundarias del grupo al rol principal. Después de que la conmutación por error geográfica finaliza, el registro de DNS se actualiza automáticamente para redirigir los puntos de conexión a la nueva región. Para obtener información sobre RPO y RTO de la conmutación por error geográfica, consulte Introducción a la continuidad empresarial.

Recuperación de una aplicación

Para lograr una continuidad empresarial completa, agregar redundancia de base de datos regional es solo una parte de la solución. Para recuperar una aplicación (un servicio) de un extremo a otro tras un error catastrófico, es necesario recuperar todos los componentes que constituyen el servicio y cualquier servicio dependiente. Algunos ejemplos de estos componentes son el software cliente (por ejemplo, un explorador con JavaScript personalizado), los front-end web, el almacenamiento y DNS. Es fundamental que todos los componentes sean resistentes a los mismos errores y que estén disponibles en el plazo del objetivo de tiempo de recuperación (RTO) de la aplicación. Por lo tanto, debe identificar todos los servicios dependientes y comprender las garantías y capacidades que ofrecen. A continuación, debe seguir los pasos adecuados para asegurarse de que el servicio funcione durante la conmutación por error de los servicios de los que depende.

Terminología y funcionalidades

  • Grupo de conmutación por error (FOG)

    Un grupo de conmutación por error permite que todas las bases de datos de usuario de una instancia administrada conmuten por error como una unidad en otra región de Azure en caso de que la instancia administrada principal deje de estar disponible debido a una interrupción de la región primaria. Como los grupos de conmutación por error automática para SQL Managed Instance contiene todas las bases de datos de usuario de la instancia, solo se puede configurar un grupo de conmutación por error en una instancia.

    Importante

    El nombre del grupo de conmutación por error debe ser único globalmente en el dominio .database.windows.net.

  • Principal

    Instancia administrada que hospeda las bases de datos principales del grupo de conmutación por error.

  • Secundario

    Instancia administrada que hospeda las bases de datos secundarias del grupo de conmutación por error. La base de datos secundaria no puede estar en la misma región de Azure que la principal.

  • Zona DNS

    Identificador único que se genera automáticamente cuando se crea una Instancia administrada de SQL. Se aprovisiona un certificado de varios dominios (SAN) para esta instancia a fin de autenticar las conexiones de cliente a cualquier instancia de la misma zona DNS. Las dos instancias administradas en el mismo grupo de conmutación por error deben compartir la zona DNS.

  • Agente de escucha de lectura-escritura de grupo de conmutación por error

    Un registro CNAME de DNS que apunta a la base de datos principal actual. Se crea automáticamente cuando se crea el grupo de conmutación por error y permite que la carga de trabajo de lectura y escritura se vuelva a conectar de forma transparente a la principal cuando esta cambia después de la conmutación por error. Cuando se crea el grupo de conmutación por error en Instancia administrada de SQL, el registro CNAME de DNS para la dirección URL del cliente de escucha tiene el formato <fog-name>.<zone_id>.database.windows.net.

  • Agente de escucha de solo lectura de grupo de conmutación por error

    Un registro CNAME de DNS que apunta a la base de datos secundaria actual. Se crea automáticamente cuando se crea el grupo de conmutación por error y permite que la carga de trabajo de SQL de solo lectura se vuelva a conectar de forma transparente a la secundaria cuando la secundaria cambia después de la conmutación por error. Cuando se crea el grupo de conmutación por error en Instancia administrada de SQL, el registro CNAME de DNS para la dirección URL del cliente de escucha tiene el formato <fog-name>.secondary.<zone_id>.database.windows.net.

  • Directiva de conmutación por error automática

    De manera predeterminada, un grupo de conmutación por error se configura con una directiva de conmutación por error automática. El sistema desencadena una conmutación por error geográfica una vez detectado el error y si el período de gracia ha expirado. El sistema debe comprobar que la interrupción no se pueda mitigar mediante la infraestructura de alta disponibilidad integrada, por ejemplo, debido a la escala del impacto. Si desea controlar el flujo de trabajo de la conmutación por error geográfica desde la aplicación o manualmente, puede desactivar la directiva de conmutación automática por error.

    Nota:

    Dado que la comprobación de la escala de la interrupción y la rapidez con que se puede mitigar conllevan acciones humanas, el período de gracia no se puede establecer por debajo de una hora. Esta limitación se aplica a todas las bases de datos del grupo de conmutación por error, independientemente de su estado de sincronización de datos.

  • Directiva de conmutación por error de solo lectura

    De forma predeterminada, se deshabilita la conmutación por error del agente de escucha de solo lectura. Se asegura de que el rendimiento de la réplica principal no se ve afectado cuando la base de datos secundaria está sin conexión. En cambio, también significa que las sesiones de solo lectura no podrán conectarse hasta que se recupere la base de datos secundaria. Si no puede tolerar tiempo de inactividad en las sesiones de solo lectura pero sí, usar la base de datos principal para el tráfico de solo lectura y el de lectura y escritura a costa de la posible degradación del rendimiento de esta, puede habilitar la conmutación por error para el agente de escucha de solo lectura mediante la configuración de la propiedad AllowReadOnlyFailoverToPrimary. En ese caso, el tráfico de solo lectura se redirigirá automáticamente a la base de datos principal si la secundaria no está disponible.

    Nota:

    La propiedad AllowReadOnlyFailoverToPrimary solo surte efecto si la directiva de conmutación automática por error está habilitada y si se ha desencadenado una conmutación por error geográfica de manera automática. En ese caso, si la propiedad se establece en true, la nueva base de datos principal atenderá a las sesiones de lectura y escritura, y de solo lectura.

  • Conmutación por error planeada

    La conmutación por error planeada realiza una sincronización de datos completa entre las bases de datos principales y secundarias antes de que el rol principal pase a la secundaria. De esta manera se garantiza que no hay pérdida de datos. La conmutación por error planeada se usa en los siguientes escenarios:

    • Realizar simulacros de recuperación ante desastres (DR) en producción cuando no es aceptable la pérdida de datos
    • Reubicar las bases de datos a una región diferente
    • Devolver las bases de datos a la región primaria después de que se ha corregido la interrupción (conmutación por recuperación)
  • Conmutación por error no planeada

    La conmutación por error no planeada o forzada cambia inmediatamente el rol secundario al rol primario sin tener que esperar a que los cambios recientes se propaguen desde el rol primario. Esta operación puede ocasionar pérdida de datos. La conmutación por error no planeada se usa como método de recuperación durante las interrupciones cuando no es posible acceder a la base de datos principal. Cuando se mitiga la interrupción, la base de datos principal anterior se vuelve a conectar automáticamente y se convierte en una nueva base de datos secundaria. Asimismo, se puede ejecutar una conmutación por error planeada para realizar una conmutación por recuperación y devolver las réplicas a sus roles principal y secundario originales.

  • Conmutación por error manual

    Puede iniciar manualmente una conmutación por error geográfica en cualquier momento, independientemente de la configuración de la conmutación automática por error. Durante una interrupción que afecta a la principal, si la directiva de conmutación automática por error no está configurada, se requiere una conmutación por error manual para promover la base de datos secundaria al rol principal. Puede iniciar una conmutación por error forzada (no planeada) o que sea sencilla (planeada). Una conmutación por error sencilla solo es posible cuando la base de datos principal anterior es accesible y se puede usar para reubicar la región principal en la secundaria sin perder los datos. Cuando se completa una conmutación por error, los registros de DNS se actualizan automáticamente para garantizar la conectividad a la nueva base de datos principal.

  • Período de gracia con pérdida de datos

    Como los datos se replican en la base de datos secundaria mediante replicación asincrónica, una conmutación por error geográfica automática puede provocar una pérdida de datos. Puede personalizar la directiva de conmutación por error automática para que refleje la tolerancia de la aplicación a la pérdida de datos. Si configura GracePeriodWithDataLossHours, puede controlar durante cuánto tiempo espera el sistema antes de iniciar la conmutación por error forzada, aunque es probable que genere una pérdida de datos.

Arquitectura del grupo de conmutación por error

El grupo de conmutación por error automática debe estar configurado en la instancia principal y se conectará a la instancia secundaria de una región de Azure diferente. Todas las bases de datos de usuario de la instancia se replicarán en la instancia secundaria. Las bases de datos del sistema como maestra y msdb no se replicarán.

En el diagrama siguiente se ilustra una configuración típica de una aplicación en la nube con redundancia geográfica con instancia administrada y un grupo de conmutación por error automática:

Auto-failover group diagram for SQL MI

Si la aplicación utiliza SQL Managed Instance como la capa de datos, siga las directrices generales y los procedimientos recomendados que se describen en este artículo al realizar el diseño para la continuidad empresarial.

Importante

Si implementa grupos de conmutación automática por error en una topología en estrella tipo hub-and-spoke entre regiones, el tráfico de replicación debe ir directamente entre las dos subredes de instancia administrada en lugar de dirigirse a través de las redes del centro.

Propagación inicial

Cuando se agregan instancias administradas a un grupo de conmutación por error, hay una fase de propagación inicial antes de que se inicie la replicación de datos. Esta fase de propagación inicial es la operación más larga y costosa. Una vez completada, se sincronizan los datos y, luego, solo se replican los cambios de datos posteriores. El tiempo que tarda la propagación inicial en completarse depende del tamaño de sus datos, la cantidad de bases de datos replicadas, la carga en las bases de datos primarias y la velocidad del enlace entre la primaria y la secundaria. En circunstancias normales, la velocidad posible de propagación es de hasta 360 GB por hora para SQL Managed Instance. La propagación se realiza en paralelo para todas las bases de datos.

En el caso de SQL Managed Instance, al estimar el tiempo de la fase de inicialización inicial, tenga en cuenta la velocidad del vínculo de ExpressRoute entre las dos instancias. Si la velocidad del vínculo entre las dos instancias es más lenta de lo necesario, es probable que el tiempo de inicialización resulte muy afectado. Puede usar la velocidad de propagación indicada, el número de bases de datos, el tamaño total de los datos y la velocidad del vínculo para calcular cuánto tardará la fase de propagación inicial antes de que se inicie la replicación de los datos. Por ejemplo, en el caso de una sola base de datos de 100 GB, la fase de inicialización inicial tardaría aproximadamente 1,2 horas si el vínculo es capaz de insertar 84 GB por hora y si no hay otras bases de datos que se vayan a inicializar. Si el vínculo solo puede transferir 10 GB por hora, la propagación de una base de datos de 100 GB tardará aproximadamente 10 horas. Si hay que replicar varias bases de datos, la propagación se ejecutará en paralelo y, cuando se combina con una velocidad de vínculo baja, la fase de propagación inicial puede tardar mucho más tiempo, en especial si la propagación paralela de los datos de todas las bases de datos supera el ancho de banda de vínculo disponible. Si el ancho de banda de red entre dos instancias es limitado y va a agregar varias instancias administradas a un grupo de conmutación por error, considere la posibilidad de hacerlo de manera secuencial, una por una. Dada una SKU de puerta de enlace con el tamaño adecuado entre las dos instancias administradas, y si el ancho de banda de la red corporativa lo permite, se pueden lograr velocidades de hasta 360 GB.

Creación de la instancia secundaria geográfica

Para garantizar la conectividad sin interrupciones a la Instancia administrada de SQL principal después de la conmutación por error, las instancias principales y secundarias deben estar en la misma zona DNS. Esto garantizará que se pueda usar el mismo certificado de varios dominios (SAN) para autenticar las conexiones de cliente a cualquiera de las dos instancias del grupo de conmutación por error. Cuando la aplicación esté lista para la implementación en producción, cree una Instancia administrada de SQL secundaria en una región distinta y asegúrese de que comparte la zona DNS con la Instancia administrada de SQL principal. Puede hacerlo al especificar un parámetro opcional durante la creación. Si usa PowerShell o la API de REST, el nombre del parámetro opcional es DNSZonePartner. El nombre del campo opcional correspondiente en Azure Portal es Primary Managed Instance (Instancia administrada principal).

Importante

La primera Instancia administrada creada en la subred determina la zona DNS de todas las instancias posteriores de la misma subred. Esto significa que dos instancias de la misma subred no pueden pertenecer a zonas DNS diferentes.

Para obtener más información sobre cómo crear la Instancia administrada de SQL secundaria en la misma zona DNS que la instancia principal, consulte Creación de una instancia administrada secundaria.

Uso de regiones emparejadas

De cara al rendimiento, implemente ambas instancias administradas en regiones emparejadas. Los grupos de conmutación por error de SQL Managed Instance en regiones emparejadas tienen un mejor rendimiento en comparación con las regiones no emparejadas.

Habilitación del tráfico de replicación geográfica entre dos instancias

Dado que cada instancia administrada está aislada en su propia red virtual, se debe permitir el tráfico bidireccional entre estas redes virtuales. Consulte Azure VPN Gateway.

Administración de la conmutación por error geográfica en una instancia secundaria geográfica

El grupo de conmutación por error administrará la conmutación por error geográfica de todas las bases de datos de la instancia administrada principal. Cuando se crea un grupo, cada base de datos de la instancia se replicará geográficamente de manera automática a la instancia secundaria geográfica. No se pueden usar grupos de conmutación por error para iniciar una conmutación por error parcial de un subconjunto de bases de datos.

Importante

Si se coloca una base de datos en la instancia administrada principal, también se colocará automáticamente en la instancia administrada secundaria de replicación geográfica.

Uso del cliente de escucha de lectura y escritura (MI principal)

Para cargas de trabajo de lectura y escritura, use <fog-name>.zone_id.database.windows.net como nombre del servidor. Las conexiones se dirigirán automáticamente a la principal. Este nombre no cambia después de la conmutación por error. La conmutación por error geográfica implica actualizar el registro DNS para que las conexiones de cliente se redirijan a la nueva base de datos principal cuando la caché DNS del cliente se haya actualizado. Dado que la instancia secundaria comparte la zona DNS con la principal, la aplicación cliente podrá volver a conectarse a ella con el mismo certificado de SAN del lado del servidor. No se puede acceder al cliente de escucha de lectura y escritura y al cliente de escucha de solo lectura mediante el punto de conexión público de la instancia administrada.

Uso del cliente de escucha de solo lectura (MI secundaria)

Si tiene cargas de trabajo de solo lectura aisladas lógicamente que son tolerantes a la latencia de datos, puede ejecutarlas en la base de datos secundaria geográfica. Para conectarse directamente a la base de datos secundaria geográfica, use <fog-name>.secondary.<zone_id>.database.windows.net como nombre del servidor.

En el nivel Crítico para la empresa, SQL Managed Instance admite el uso de réplicas de solo lectura para descargar cargas de trabajo de consulta de solo lectura, mediante el parámetro de la cadena de conexión. Cuando se configuró una base de datos secundaria con replicación geográfica, se puede usar esta funcionalidad para conectarse a una réplica de solo lectura de la ubicación principal o de la ubicación con replicación geográfica:

  • Para conectarse a una réplica de solo lectura en la ubicación principal, use ApplicationIntent=ReadOnly y <fog-name>.<zone_id>.database.windows.net.
  • Para conectarse a una réplica de solo lectura en la ubicación secundaria, use ApplicationIntent=ReadOnlyy <fog-name>.secondary.<zone_id>.database.windows.net.

No se puede acceder al cliente de escucha de lectura y escritura y al cliente de escucha de solo lectura mediante el punto de conexión público de la instancia administrada.

Posible degradación del rendimiento después de la conmutación por error

Una aplicación de Azure típica usa varios servicios de Azure y consta de varios componentes. La conmutación por error geográfica de manera automática del grupo de conmutación por error se desencadena en función del estado de los componentes de Azure SQL. Es posible que otros servicios de Azure de la región primaria no se vean afectados por la interrupción y que sus componentes sigan estando disponibles en esa región. Una vez que las bases de datos principales cambien a la región secundaria, la latencia entre los componentes dependientes puede aumentar. Para evitar que la mayor latencia afecte al rendimiento de la aplicación, compruebe la redundancia de todos los componentes de la aplicación en la región secundaria y realice la conmutación por error de los componentes junto con la de la base de datos.

Posible pérdida de datos después de la conmutación por error

Si se produce una interrupción en la región primaria, es posible que las transacciones recientes no se puedan replicar en la secundaria geográfica. La conmutación por error se aplazará durante el período que especifique mediante GracePeriodWithDataLossHours. Si configuró la directiva de conmutación automática por error, prepárese para la pérdida de datos. Por lo general, durante las interrupciones, Azure favorece la disponibilidad. Establecer GracePeriodWithDataLossHours en un número mayor, como 24 horas, o deshabilitar la conmutación por error geográfica de manera automática le permite reducir la probabilidad de perder datos a costa de la disponibilidad de la base de datos.

Actualización de DNS

La actualización de DNS del agente de escucha de lectura y escritura sucederá inmediatamente después de que se inicie la conmutación por error. Esta operación no ocasionará pérdida de datos. Sin embargo, el proceso de conmutación de roles de base de datos puede tardar hasta 5 minutos en condiciones normales. Hasta que se complete, algunas bases de datos de la nueva instancia principal seguirán siendo de solo lectura. Si se inicia una conmutación por error mediante PowerShell, la operación para cambiar el rol de la réplica principal es sincrónica. Si se inicia mediante Azure Portal, la interfaz de usuario indicará el estado de finalización. Si se inicia mediante la API REST, use el mecanismo de sondeo estándar de Azure Resource Manager para supervisar la finalización.

Importante

Use la conmutación por error planeada manual para volver a transferir la principal a la ubicación original una vez mitigada la interrupción que provocó la conmutación por error geográfica.

Habilitación de escenarios que dependen de objetos de las bases de datos del sistema

Las bases de datos del sistema no se replican en la instancia secundaria de un grupo de conmutación por error. Para habilitar escenarios que dependen de los objetos de las bases de datos del sistema, asegúrese de crear los mismos objetos en la instancia secundaria y mantenerlos sincronizados con la instancia principal.

Por ejemplo, si tiene previsto utilizar los mismos inicios de sesión en la instancia secundaria, asegúrese de crearlos con el SID idéntico.

-- Code to create login on the secondary instance
CREATE LOGIN foo WITH PASSWORD = '<enterStrongPasswordHere>', SID = <login_sid>;

Para más información, consulte el artículo sobre la replicación de inicios de sesión y trabajos de agente.

Sincronización de las propiedades de instancia y las instancias de directivas de retención

Las instancias de un grupo de conmutación por error siguen siendo recursos de Azure independientes y ningún cambio que se haga en la configuración de la instancia principal se replicará automáticamente en la instancia secundaria. Por ello, asegúrese de realizar todos los cambios relevantes tanto en la instancia principal como en la secundaria. Por ejemplo, si cambia la redundancia del almacenamiento de copia de seguridad o la directiva de retención de copias de seguridad a largo plazo en la instancia principal, asegúrese de cambiarla también en la instancia secundaria.

Uso de los grupos de conmutación por error y los puntos de conexión de servicio de red virtual

Si usa reglas y puntos de conexión de servicio de red virtual para restringir el acceso a su instancia de SQL Managed Instance, tenga en cuenta que cada punto de conexión de servicio de red virtual solo se aplica a una región de Azure. El punto de conexión no permite que otras regiones acepten la comunicación de la subred. Por lo tanto, solo las aplicaciones de cliente implementadas en la misma región pueden conectarse a la base de datos principal.

Evitación la pérdida de datos críticos

Debido a la elevada latencia de las redes de área extensa, la replicación geográfica usa un mecanismo de replicación asincrónica. La replicación asincrónica hace que la posibilidad de perder datos sea inevitable si se produce un error en la principal. Para proteger las transacciones críticas contra la pérdida de datos, un desarrollador de aplicaciones puede llamar al procedimiento almacenado sp_wait_for_database_copy_sync inmediatamente después de confirmar la transacción. La llamada a sp_wait_for_database_copy_sync bloquea el subproceso de llamada hasta que se transmite y protege la última transacción confirmada en el registro de transacciones de la base de datos secundaria. Sin embargo, no espera a que las transacciones transmitidas se reproduzcan (vuelvan a hacerse) en la base de datos secundaria. sp_wait_for_database_copy_sync está limitado a un vínculo de replicación geográfica específico. Cualquier usuario con derechos de conexión para la base de datos principal puede llamar a este procedimiento.

Nota:

sp_wait_for_database_copy_sync evita la pérdida de datos después de la conmutación por error geográfica para transacciones específicas, pero no garantiza la sincronización completa para el acceso de lectura. El retraso provocado por una llamada al procedimiento sp_wait_for_database_copy_sync puede ser considerable y depende del tamaño del registro de transacciones que todavía no se transmiten en la principal en el momento de la llamada.

Estado del grupo de conmutación por error

El grupo de conmutación por error automática informa de su estado describiendo el estado actual de la replicación de datos:

  • Inicialización: la inicialización inicial tiene lugar después de la creación del grupo de conmutación por error, hasta que todas las bases de datos de usuario se inicializan en la instancia secundaria. No se puede iniciar el proceso de conmutación por error mientras el grupo de conmutación por error automática se encuentra en estado de inicialización, ya que las bases de datos de usuario aún no se copian en la instancia secundaria.
  • Sincronización: el estado habitual del grupo de conmutación por error automática. Esto significa que los cambios de datos de la instancia principal se replican de forma asincrónica en la instancia secundaria. Este estado no garantiza que los datos estén totalmente sincronizados en cada momento. Puede haber cambios en los datos del servidor principal que todavía se va a replicar en la base de datos secundaria debido a la naturaleza asincrónica del proceso de replicación entre instancias del grupo de conmutación por error automática. Tanto las conmutaciones por error automáticas como las manuales se pueden iniciar mientras el grupo de conmutación por error automática se encuentra en estado de inicialización.
  • Conmutación por error en curso: este estado indica que el proceso de conmutación por error iniciado de forma automática o manual está en curso. No se pueden iniciar cambios en el grupo de conmutación por error ni conmutaciones por error adicionales mientras el grupo de conmutación por error automática se encuentra en este estado.

Permisos

Los permisos para un grupo de conmutación por error se administran a través del control de acceso basado en rol de Azure (Azure RBAC).

El acceso de escritura de RBAC de Azure es necesario para crear y administrar grupos de conmutación por error. El rol Colaborador de instancia administrada de SQL tiene todos los permisos necesarios para administrar grupos de conmutación por error.

Para ámbitos de permisos específicos, consulte cómo configurar grupos de conmutación por error automática en Azure SQL Managed Instance.

Limitaciones

Tenga en cuenta las siguientes limitaciones:

  • No se pueden crear grupos de conmutación por error entre dos instancias en la misma región de Azure.
  • No se puede cambiar el nombre de los grupos de conmutación por error. Tendrá que eliminar el grupo y volver a crearlo con un nombre diferente.
  • No se admiten los cambios de nombre de la base de datos para las bases de datos del grupo de conmutación por error. Tendrá que eliminar temporalmente el grupo de conmutación por error para poder cambiar el nombre a una base de datos.
  • Las bases de datos del sistema no se replican en la instancia secundaria de un grupo de conmutación por error. Por lo tanto, los escenarios que dependen de objetos de las bases de datos del sistema, como los inicios de sesión del servidor o los trabajos del agente, necesitan que los objetos se creen manualmente en las instancias secundarias y también que se mantengan sincronizados manualmente después de los cambios realizados en la instancia principal. La única excepción es la clave maestra de servicio (SMK) de SQL Managed Instance, que se replica automáticamente en la instancia secundaria durante la creación del grupo de conmutación por error. Sin embargo, los cambios posteriores de SMK en la instancia principal no se replicarán en la instancia secundaria. Para obtener más información, consulte Habilitación de escenarios que dependen de objetos de las bases de datos del sistema.
  • No se pueden crear grupos de conmutación por error entre instancias si alguna de ellas se encuentra en un grupo de instancias.

Administración mediante programación de grupos de conmutación por error

Los grupos de conmutación por error automática también se pueden administrar mediante programación con Azure PowerShell, la CLI de Azure y la API REST. En las tablas siguientes se describe el conjunto de comandos disponibles. La replicación geográfica activa incluye un conjunto de API de Azure Resource Manager para la administración, en el que se incluyen la API REST de Azure SQL Database y los cmdlets de Azure PowerShell. Estas API requieren que se usen grupos de recursos y admiten el control de acceso basado en rol de Azure (Azure RBAC). Para más información sobre cómo implementar los roles de acceso, consulte Control de acceso basado en roles de Azure (Azure RBAC).

Cmdlet Descripción
New-AzSqlDatabaseInstanceFailoverGroup Este comando crea un grupo de conmutación por error y lo registra en las instancias principal y secundaria.
Set-AzSqlDatabaseInstanceFailoverGroup Modifica la configuración de un grupo de conmutación por error.
Get-AzSqlDatabaseInstanceFailoverGroup Recupera la configuración de un grupo de conmutación por error.
Switch-AzSqlDatabaseInstanceFailoverGroup Desencadena la conmutación por error de un grupo de conmutación por error en la instancia secundaria.
Remove-AzSqlDatabaseInstanceFailoverGroup Quita un grupo de conmutación por error.

Pasos siguientes