Introducción a los grupos de conmutación por error y procedimientos recomendados (Azure SQL Database)

Applies to:Azure SQL Database

La característica de los grupos de conmutación por error permite administrar la replicación y la conmutación por error de algunas bases de datos de un servidor lógico o de todas ellas a otro servidor lógico en otra región. En este artículo se proporciona información general sobre la característica de grupo de conmutación por error con procedimientos recomendados y recomendaciones para usarlo con Azure SQL Database.

Para empezar a usar la función, consulte Configurar un grupo de conmutación por error para Azure SQL Database.

Para más información sobre Azure SQL Database recuperación ante desastres, vea este vídeo:

Información general

La característica de los grupos de conmutación por error permite administrar la replicación y la conmutación por error de las bases de datos a otra región de Azure. Puedes elegir todas o un subconjunto de bases de datos de usuario en un servidor lógico para replicarse en otro servidor lógico. 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.

Para obtener información sobre RPO y RTO de geo-failover, consulta Resumen de la continuidad empresarial.

Redireccionamiento de punto de conexión

Los grupos de conmutación por error 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. No es necesario cambiar la cadena de conexión de la aplicación después de una conmutación por error geográfica, ya que las conexiones se enrutan automáticamente a la base de datos primaria actual. Una conmutación por error geográfica transfiere 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.

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.

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 tomar las medidas adecuadas para asegurarse de que su servicio siga operando durante la conmutación por error de los servicios de los que depende.

Directiva de conmutación por error

Los grupos de conmutación por error admiten dos directivas de conmutación por error:

• Administrada por el cliente (recomendado): los clientes pueden realizar una conmutación de emergencia de un grupo cuando detecten una interrupción inesperada que afecta a una o varias bases de datos del grupo afectado. Al usar herramientas de línea de comandos como PowerShell, la Azure CLI o la API REST, el valor de la directiva de conmutación por error para gestionado por el cliente es manual.
• Administrado por Microsoft: en el caso de una interrupción generalizada que impacta una región primaria, Microsoft inicia la conmutación por error de todos los grupos de conmutación por error afectados que tienen configurada su directiva de conmutación por error para ser administrada por Microsoft. La conmutación por error administrada por Microsoft no se iniciará para grupos de conmutación por error individuales ni para un subconjunto de grupos de conmutación por error de una región. Al utilizar herramientas de línea de comandos como PowerShell, la Azure CLI o la API REST, el valor de la política de conmutación por error para el entorno administrado por Microsoft es automatic.

Cada directiva de conmutación por error tiene un conjunto único de casos de uso y las expectativas correspondientes sobre el ámbito de conmutación por error y la pérdida de datos, como se resume en la tabla siguiente:

Administrado por el cliente

En raras ocasiones, la disponibilidad integrada o la alta disponibilidad no es suficiente para mitigar una interrupción y las bases de datos de un grupo de conmutación por error podrían no estar disponibles durante una duración que no es aceptable para el acuerdo de nivel de servicio (SLA) de las aplicaciones que usan las bases de datos. Las bases de datos pueden no estar disponibles debido a un problema localizado que afecta a solo unas pocas bases de datos o podrían estar en el centro de datos, la zona de disponibilidad o el nivel de región. En cualquiera de estos casos, para restaurar la continuidad empresarial, puedes iniciar una conmutación por error forzada.

Se recomienda encarecidamente establecer la política de conmutación por error como gestionada por el cliente, ya que le permite tener el control sobre cuándo iniciar una conmutación por error y restaurar la continuidad de negocio. Puedes iniciar una conmutación por error cuando observes una interrupción inesperada que afecte a una o varias bases de datos del grupo de conmutación por error.

Administrado por Microsoft

Con una directiva de conmutación por error administrada por Microsoft, la responsabilidad de recuperación ante desastres se delega al servicio Azure SQL. Para que el servicio Azure SQL inicie una conmutación por error forzada, se deben cumplir las condiciones siguientes:

• Interrupción del nivel de región causada por un evento de desastre natural, cambios de configuración, errores de software o errores de componentes de hardware y muchas bases de datos de la región se ven afectadas.
• El período de gracia ha expirado. 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.

Cuando se cumplen estas condiciones, el servicio Azure SQL inicia conmutaciones por error forzadas para todos los grupos de conmutación por error de la región que tienen la política de conmutación por error configurada como Administrada por Microsoft.

Establece la directiva de conmutación por error en Administrada por Microsoft solo cuando:

• Quiere delegar la responsabilidad de recuperación ante desastres en el servicio Azure SQL.
• La aplicación es tolerante a que la base de datos no esté disponible durante al menos una hora o más.
• Es aceptable desencadenar conmutaciones por error forzadas algún tiempo después de que expire el período de gracia, ya que el tiempo real de la conmutación por error forzada puede variar significativamente.
• Es aceptable que todas las bases de datos del grupo de conmutación por error realicen la conmutación por error, independientemente de su configuración de redundancia de zona o estado de disponibilidad. Aunque las bases de datos configuradas para la redundancia de zona son resistentes a fallos zonales y podrían no verse afectadas por una interrupción, se producirá una conmutación por error si forman parte de un grupo de conmutación por error con una directiva de conmutación por error administrada por Microsoft.
• Es aceptable tener conmutaciones por error forzadas de bases de datos en el grupo de conmutación por error sin tener en cuenta la dependencia de la aplicación en otros servicios o componentes de Azure utilizados por la aplicación, lo que puede provocar una degradación del rendimiento o una falta de disponibilidad de la aplicación.
• Es aceptable incurrir en una cantidad desconocida de pérdida de datos, ya que el tiempo exacto de la conmutación por error forzada no se puede controlar y omite el estado de sincronización de las bases de datos secundarias.
• Las réplicas principales y secundarias del grupo de conmutación por error tienen el mismo nivel de servicio, nivel de cómputo y tamaño de cómputo.

Cuando Microsoft desencadena una conmutación por error, se agrega una entrada para el nombre de la operación Failover Azure SQL grupo de conmutación por error al registro de actividad de Azure Monitor. La entrada incluye el nombre del grupo de conmutación por error en Recurso y Evento iniciado por muestra un solo guión (-) para indicar que Microsoft inició la conmutación por error. Esta información también se puede encontrar en la página Activity log del nuevo servidor principal o instancia en el portal de Azure.

Terminología y funcionalidades

• Grupo de conmutación por error (FOG)

  Un grupo de conmutación por error es un grupo con nombre de bases de datos administradas por un servidor lógico único en Azure que puede hacer la conmutación por error como una unidad a otra región de Azure en caso de que todas o algunas bases de datos principales no estén disponibles debido a un fallo en la región primaria.

  Importante

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

• Servidores

  Algunas o todas las bases de datos de usuario de un servidor lógico pueden colocarse en un grupo de conmutación por error. Además, un servidor admite varios grupos de conmutación por error en un solo servidor.

• Principal

  Servidor lógico que alberga las bases de datos principales en el grupo de conmutación por error.

• Secundario

  Servidor lógico que hospeda las bases de datos secundarias en el grupo de conmutación automática. La secundaria no puede estar en la misma región de Azure que la principal.

• Failover (sin pérdida de datos)

  La conmutación por error 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 solo es posible cuando se puede acceder al servidor principal. La conmutación por error 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 la carga de trabajo a una región diferente
  • Devolver la carga de trabajo a la región primaria después de que se ha solucionado la interrupción (retroceso)

• Conmutación por error forzada (posible pérdida de datos)

  La conmutación por error 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 dar lugar a una potencial pérdida de datos. La conmutación por error forzada se usa como método de recuperación durante las interrupciones cuando no es posible acceder al primario. 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. Se puede ejecutar una conmutación por error para retroceder, devolviendo las réplicas a sus roles principal y secundario originales.

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

  Dado que los datos se replican en la base de datos secundaria mediante la replicación asincrónica, la conmutación por error forzada de grupos con directivas de conmutación por error administradas por Microsoft puede provocar la pérdida de datos. Puedes personalizar la directiva de conmutación por error para que refleje la tolerancia de la aplicación a la pérdida de datos. Al configurar GracePeriodWithDataLossHours, puede controlar cuánto tiempo espera el servicio Azure SQL antes de iniciar una conmutación por error forzada, lo que puede provocar la pérdida de datos.

• Incorporación de bases de datos individuales a un grupo de conmutación por error

  Puede colocar varias bases de datos individuales en el mismo servidor lógico e incluirlas en el mismo grupo de conmutación por error. Si agregas una base de datos única al grupo de conmutación por error, automáticamente se creará una base de datos secundaria con la misma edición y el mismo tamaño de proceso en el servidor secundario que especificaste cuando se creó el grupo de conmutación por error. Si agrega una base de datos que ya tenga una base de datos secundaria en el servidor secundario, el grupo heredará el vínculo de replicación geográfica. Cuando se agrega una base de datos que ya tiene una base de datos secundaria en un servidor que no forma parte del grupo de conmutación por error, se crea otra base de datos secundaria en el servidor secundario.

  Importante

  • Asegúrate de que el servidor lógico secundario no tenga una base de datos con el mismo nombre, a menos que sea una base de datos secundaria existente.
  • Si una base de datos contiene objetos OLTP en memoria, la base de datos principal y la base de datos de réplica geográfica secundaria deben tener niveles de servicio coincidentes, ya que los objetos OLTP en memoria están alojados en memoria. Un nivel de servicio inferior en la base de datos de réplica geográfica puede dar lugar a problemas de memoria insuficiente. Si esto ocurre, es posible que la réplica geográfica no pueda recuperar correctamente la base de datos, lo que causa la inactividad de la base de datos secundaria junto con objetos OLTP en memoria en la replica geo-secundaria. Esto, a su vez, puede provocar que las conmutaciones por error también sean fallidas. Para evitarlo, asegúrese de que el nivel de servicio de la base de datos secundaria geográfica coincide con el de la base de datos principal. Las actualizaciones de nivel de servicio pueden ser operaciones de tamaño de datos y es posible que tarden en finalizar.

• Incorporación de bases de datos de un grupo elástico a un grupo de conmutación por error

  Puede poner varias bases de datos en el mismo grupo elástico e incluirlas en el mismo grupo de conmutación por error. Si la base de datos principal está en un grupo elástico, la base de datos secundaria se creará automáticamente en un grupo elástico con el mismo nombre (grupo secundario). Debe asegurarse de que el servidor secundario contenga un grupo elástico con el nombre exacto y suficiente capacidad libre para hospedar las bases de datos secundarias que el grupo de conmutación por error va a crear. Si agrega una base de datos en un grupo que ya tiene una base de datos secundaria en el grupo secundario, el grupo heredará el vínculo de replicación geográfica. Cuando se agrega una base de datos que ya tiene una base de datos secundaria en un servidor que no forma parte del grupo de conmutación por error, se crea otra base de datos secundaria en el grupo secundario.

• Escucha de lectura-escritura del grupo de conmutación por error

  Un registro CNAME de DNS que apunta al servidor primario 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 conecte de nuevo de forma transparente a la entidad primaria cuando esta cambia después de la conmutación por error. Cuando se crea el grupo de conmutación por error en un servidor, el registro CNAME de DNS para la dirección URL del cliente de escucha tiene el formato <fog-name>.database.windows.net. Tras la conmutación, el registro DNS se actualiza automáticamente para redirigir al receptor hacia el nuevo primario.

• 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 configura el grupo de conmutación por error y permite que la carga de trabajo SQL de solo lectura se conecte de manera transparente al servidor secundario cuando este cambia después de la conmutación por error. Cuando se crea el grupo de conmutación por error en un servidor, el registro CNAME de DNS para la dirección URL del cliente de escucha tiene el formato <fog-name>.secondary.database.windows.net. De forma predeterminada, la conmutación por error del agente de escucha de solo lectura está deshabilitada, ya que garantiza que el rendimiento de la base de datos principal no se vea 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.

• Varios grupos de conmutación por error

  Puede configurar varios grupos de conmutación por error para el mismo par de servidores con el fin de controlar el ámbito de las conmutaciones por error geográficas. Cada grupo realiza la conmutación por error por separado. Si la aplicación de inquilino por base de datos se implementa en varias regiones y usa grupos elásticos, puede usar esta funcionalidad para combinar las bases de datos principales y secundarias en cada grupo. De este modo, puedes reducir el impacto de una interrupción a solo algunas bases de datos de inquilino.

Arquitectura del grupo de failover

Un grupo de conmutación por error en Azure SQL Database puede incluir una o varias bases de datos, normalmente usadas por la misma aplicación. Un grupo de conmutación por error debe configurarse en el servidor principal, que lo conecta al servidor secundario en una región de Azure diferente. Los grupos de conmutación por error pueden incluir todas las bases de datos o algunas de ellas en el servidor principal. En el siguiente diagrama se ilustra una configuración típica de una aplicación de nube con redundancia geográfica que usa varias bases de datos y un grupo de conmutación por error:

Al diseñar un servicio con la continuidad empresarial en mente, siga las instrucciones generales y los procedimientos recomendados que se describen en este artículo. Al configurar un grupo de conmutación por error, asegúrese de que la autenticación y el acceso a la red en la secundaria estén configurados correctamente para funcionar después de la conmutación por error geográfica, cuando la geo-secundaria se convierta en la nueva principal. Para obtener más información, consulte Configurar y administrar la seguridad de Azure SQL Database para la restauración geográfica o conmutación por error. Para obtener más información, consulte Diseño de servicios globalmente disponibles utilizando Azure SQL Database y Geo-restauración para Azure SQL Database.

Uso de regiones emparejadas

Al crear el grupo de conmutación por error entre el servidor principal y secundario, usa regiones emparejadas, ya que los grupos de conmutación por error de las regiones emparejadas tienen un mejor rendimiento en comparación con las regiones no emparejadas.

Siguiendo los procedimientos de implementación seguros, Azure SQL Database normalmente no actualiza las regiones emparejadas al mismo tiempo. Sin embargo, no es posible predecir qué región se actualizará primero, por lo que no se garantiza el orden de implementación. A veces, el servidor principal se actualiza primero y, a veces, se actualiza en segundo lugar.

Si tiene geo-replication o grupos de conmutación por error configurados para las bases de datos que no se alinean con el Azure region pairing, use diferentes programaciones de ventanas de mantenimiento para las bases de datos principales y secundarias. Por ejemplo, puedes seleccionar la ventana de mantenimiento Día de la semana para la base de datos secundaria y la ventana de mantenimiento Fin de semana para la base de datos principal.

Siembra inicial

Al agregar bases de datos o grupos elásticos 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 la siembra inicial, se sincronizan los datos y, luego, solo se replican los cambios de datos subsecuentes. 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 de red entre la base de datos primaria y la secundaria. En circunstancias normales, la velocidad posible de propagación es de hasta 500 GB por hora para Azure SQL Database. El sembrado se realiza en paralelo para todas las bases de datos.

Número de bases de datos en el grupo de conmutación por error

El número de bases de datos dentro de un grupo de conmutación por error afecta directamente a la duración de las operaciones de conmutación por error estándar y las de conmutación por error forzada.

• Durante una conmutación por error (también conocida como conmutación por error planeada), se garantiza que todas las bases de datos principales estén totalmente sincronizadas con su secundario y lleguen a un estado listo. Para evitar sobrecargar el plano de control, las bases de datos se preparan en lotes. Por lo tanto, es muy recomendable limitar el número de bases de datos en un grupo de conmutación por error.
• En el caso de una conmutación por error forzada, la fase de preparación se acelera ya que no se inicia la sincronización de datos. Para lograr duraciones de conmutación por error más rápidas y predecibles, puede ser beneficioso mantener el número de bases de datos del grupo de conmutación por error en un número menor.

Uso de varios grupos de conmutación por error para conmutar por error varias bases de datos

Se pueden crear uno o más grupos de conmutación por error entre dos servidores en regiones distintas (servidor principal y servidor secundario). Cada grupo puede incluir una o varias bases de datos que se recuperan como unidad en caso de que una o todas las bases de datos principales dejen de estar disponibles debido a una interrupción en la región primaria. La creación de un grupo de conmutación por error crea bases de datos geográficas secundarias con el mismo objetivo de servicio que la principal. Si agrega una relación de replicación geográfica existente a un grupo de conmutación por error, asegúrese de que el secundario geográfico esté configurado con el mismo nivel de servicio y tamaño de cálculo que el primario.

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

En el caso de las cargas de trabajo de lectura y escritura, use <fog-name>.database.windows.net como nombre de servidor en el connection string. Las conexiones se dirigen automáticamente a la principal. Este nombre no cambia después del fallo. Tenga en cuenta que la conmutación por error implica actualizar el registro DNS para que las conexiones del cliente se redirijan al nuevo servidor primario solo después de que la caché DNS del cliente se haya actualizado. El período de vida (TTL) del registro DNS del agente de escucha principal y secundario es de 30 segundos.

Usar el oyente de solo lectura (secundario)

Si tiene cargas de trabajo de solo lectura que están aisladas lógicamente y son tolerantes a la latencia de datos, puede ejecutarlas en la secundaria geográfica. Para las sesiones de solo lectura, use <fog-name>.secondary.database.windows.net como nombre del servidor en el connection string. Las conexiones se dirigen automáticamente a la secundaria geográfica. También se recomienda indicar la intención de lectura en el connection string mediante ApplicationIntent=ReadOnly.

En los niveles de servicio Premium, Crítico para la empresa e Hiperescala, SQL Database admite el uso de réplicas de solo lectura para desviar cargas de trabajo de consulta de solo lectura mediante el parámetro ApplicationIntent=ReadOnly en la cadena de conexión. Cuando se ha configurado una base de datos secundaria geográfica, puedes usar esta funcionalidad para conectarte a una réplica de solo lectura de la ubicación principal o de la ubicación secundaria geográfica:

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

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

Una aplicación Azure típica usa varios servicios Azure y consta de varios componentes. La conmutación por error de un grupo se desencadena únicamente en función del estado de Azure SQL Database. Es posible que otros servicios de Azure de la región primaria no se vean afectados por la interrupción y sus componentes todavía estén disponibles en esa región. Una vez que las bases de datos principales cambien a la región secundaria de DR, la latencia entre los componentes dependientes puede aumentar. Para evitar el impacto de una mayor latencia en el rendimiento de la aplicación, asegúrese de la redundancia de todos los componentes de la aplicación en la región de DR, siga estas directrices de seguridad de red y organice la conmutación por error geográfica de los componentes de aplicación pertinentes junto con la base de datos.

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

Si se produce una interrupción en la región primaria, es posible que las transacciones recientes no se hayan replicado en la base de datos secundaria geográfica y que se produzca una pérdida de datos si se realiza una conmutación por error forzada.

Conmutación inversa

Cuando los grupos de conmutación por error se configuran con una directiva de conmutación por error administrada por Microsoft, la conmutación por error al servidor geográfico secundario se inicia durante un escenario de desastre según el período de gracia que se definió. La reversión al servidor principal anterior debe iniciarse manualmente.

Varias secundarias

Cada grupo de conmutación por error puede admitir varios servidores secundarios en la misma o diferente región. Esta configuración proporciona opciones adicionales para la recuperación ante desastres y permite que las cargas de trabajo de solo lectura se distribuyan entre varias regiones. Al configurar varias secundarias, tenga en cuenta lo siguiente:

• Se pueden especificar hasta cuatro servidores secundarios para cada grupo de conmutación por error.
• Cada servidor secundario puede estar en la misma región o en una región diferente del servidor principal y entre sí.
• Cada servidor secundario mantiene su propio vínculo de replicación geográfica con el servidor principal.
• La conmutación por error podrá iniciarse en cualquiera de los servidores secundarios.
• El agente de escucha de solo lectura se puede configurar solo en uno de los servidores secundarios y debe estar en un secundario de otra región para atender correctamente las cargas de trabajo de solo lectura.
• No se admite el encadenamiento (crear una réplica geográfica de una réplica geográfica) con esta configuración.

Permisos y limitaciones

Revisa la guía de configuración del grupo de conmutación por error para obtener una lista de permisos y limitaciones.

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

Los grupos de conmutación por error también se pueden administrar programáticamente mediante Azure PowerShell, Azure CLI y la API REST. Para obtener más información, consulte Configurar un grupo de conmutación por error para Azure SQL Database.

Habilitación de la alta disponibilidad (redundancia de zona)

Disponibilidad a través de la redundancia mejora aún más la resiliencia al proteger contra interrupciones de una zona de disponibilidad dentro de una región.

Al crear un grupo de conmutación por error que incluya una o varias bases de datos, no hay ninguna opción para habilitar la alta disponibilidad para las bases de datos secundarias, independientemente de la configuración de alta disponibilidad de las bases de datos principales.

Redundancia de zona con bases de datos que no son de Hiperescala

Las bases de datos secundarias creadas a través del grupo de conmutación por error no tienen habilitada la alta disponibilidad de forma predeterminada. Una vez creado el grupo de conmutación por error, habilite la alta disponibilidad en las bases de datos contenidas en el grupo. Este comportamiento también se aplica si crea primero la replicación geográfica activa y, a continuación, agrega opcionalmente las bases de datos a un grupo de conmutación por error.

Redundancia de zona con Hiperescala

Las bases de datos secundarias creadas a través del grupo de conmutación por error heredarán la configuración de alta disponibilidad de sus respectivas bases de datos principales. Por lo tanto, si la base de datos principal tiene habilitada la alta disponibilidad, la base de datos secundaria también la tendrá habilitada. Por el contrario, si la base de datos principal no tiene habilitada la alta disponibilidad, la base de datos secundaria tampoco la tendrá habilitada.

Soporte regional para zonas de disponibilidad

En un escenario en el que la alta disponibilidad está habilitada en la base de datos principal y la base de datos secundaria que se agrega se encuentra en una región que aún no admite zonas de disponibilidad, el flujo de trabajo producirá un mensaje de error con el código 45122: "La operación crear o actualizar el grupo de conmutación por error se completó correctamente; Sin embargo, algunas de las bases de datos no se pudieron agregar ni quitar del grupo de conmutación por error. No se admite el aprovisionamiento de la base de datos o el grupo con redundancia de zona para la solicitud actual". Para solucionar este problema, use una Replicación geográfica activa donde se habilite o deshabilite la alta disponibilidad al crear la base de datos secundaria. A continuación, puede agregar estas bases de datos a un grupo de conmutación por error.

Contenido relacionado

• Para los scripts de ejemplo, vea:
  • Use PowerShell para configurar la replicación geográfica activa para Azure SQL Database
  • Use PowerShell para configurar la replicación geográfica activa para una base de datos agrupada en Azure SQL Database
  • Usar PowerShell para agregar una base de datos SQL de Azure a un grupo de conmutación por error
• Para obtener una descripción general y los escenarios de la continuidad empresarial, consulte Descripción general de la continuidad empresarial
• Para obtener información sobre Azure SQL Database copias de seguridad automatizadas, consulte SQL Database automated backups.
• Si quiere saber cómo usar las copias de seguridad automatizadas para procesos de recuperación, consulte Recuperación de una base de datos a partir de copias de seguridad iniciadas por un servicio.
• Para obtener información acerca de los requisitos de autenticación para un nuevo servidor principal y la base de datos, consulte Administración de la seguridad de Azure SQL Database después de la recuperación ante desastres.
• Para solucionar problemas de replicación geográfica, consulte Solución de problemas de retardo de replicación geográfica.