Compartir por

Configuración de un grupo de conmutación por error para una SQL Managed Instance

  • Artigo

Se aplica a: Azure SQL Managed Instance

En este tema se muestra cómo configurar un grupo de conmutación por error para Azure SQL Managed Instance mediante el portal de Azure y Azure PowerShell.

Para que un script de PowerShell de un extremo a otro cree ambas instancias dentro de un grupo de conmutación por error, revise Agregar instancia a un grupo de conmutación por error con PowerShell.

Requisitos previos

Para configurar un grupo de migración tras error, ya debe tener permisos adecuados y una instancia administrada de SQL que quiera usar como principal. Para empezar, consulte Crear instancia.

Asegúrese de revisar las limitaciones antes de crear la instancia secundaria y el grupo de migración tras error.

Requisitos de configuración

Para configurar un grupo de conmutación por error entre una instancia administrada de SQL principal y secundaria, tenga en cuenta los siguientes requisitos:

  • La instancia administrada secundaria debe estar vacía, sin bases de datos de usuarios.
  • Las dos instancias deben ser del mismo nivel de servicio y tener el mismo tamaño de almacenamiento. Aunque no es necesario, se recomienda encarecidamente que ambas instancias tengan un tamaño de proceso igual, para asegurarse de que la instancia secundaria pueda procesar de forma sostenible los cambios que se replican desde la instancia principal, incluso durante periodos de actividad máxima.
  • El intervalo de direcciones IP de la red virtual de la instancia principal no debe superponerse con el intervalo de direcciones de la red virtual de la instancia administrada secundaria, ni con cualquier otra red virtual emparejada con la red virtual principal o secundaria.
  • Ambas instancias deben estar en la misma zona DNS. Al crear la instancia administrada secundaria, debe especificar el id. de zona DNS de la instancia primaria. Si no se hace, el Id. de zona se genera como una cadena aleatoria cuando se crea la primera instancia en cada red virtual, y este mismo Id. se asigna a todas las demás instancias de la misma subred. Una vez que se ha asignado, no se puede modificar la zona DNS.
  • Las reglas de grupos de seguridad de red (NSG) para las subredes de ambas instancias deben tener conexiones TCP entrantes y salientes abiertas para el puerto 5022 y el intervalo de puertos 11000-11999 para facilitar la comunicación entre las dos instancias.
  • Las instancias administradas se deben implementar en regiones emparejadas por motivos de rendimiento. Las instancias administradas que residen en regiones emparejadas geográficamente se benefician de una velocidad de replicación geográfica significativamente mayor en comparación con las regiones no emparejadas.
  • Ambas instancias deben usar la misma directiva de actualización.

Creación de la instancia secundaria

Al crear la instancia secundaria, debe usar una red virtual que tenga un espacio de direcciones IP que no se superponga con el intervalo de espacio de direcciones IP de la instancia principal. Además, al configurar la nueva instancia secundaria, debe especificar el id. de zona de la instancia principal.

Puede configurar la red virtual secundaria y crear la instancia secundaria mediante Azure Portal y PowerShell.

Creación de una red virtual

Para crear una red virtual para su instancia secundaria en Azure Portal, siga estos pasos:

  1. Compruebe el espacio de direcciones de la instancia principal. Vaya al recurso de red virtual para la instancia principal en el portal Azure y, en Configuración, seleccione Espacio de direcciones. Comprueba el intervalo en Intervalo de direcciones:

    Captura de pantalla del espacio de direcciones de la red virtual principal en Azure Portal.

  2. Cree una nueva red virtual que planee usar para la instancia secundaria; para ello, vaya a la página Crear red virtual.

  3. En la pestaña Aspectos básicos de la página Crear una red virtual:

    1. Seleccione el grupo de recursos que quiere usar para la instancia secundaria. Cree uno nuevo si aún no existe.
    2. Escriba un nombre para la red virtual, como por ejemplo vnet-sql-mi-secondary.
    3. Seleccione una región emparejada con la región donde está la instancia principal.

  4. En la pestaña Direcciones IP de la página Crear red virtual:

    1. Utilice Borrar espacio de direcciones para borrar el espacio de direcciones IPv4 existente.
    2. Una vez eliminado el espacio de direcciones, seleccione Agregar espacio de direcciones IPv4 para agregar un nuevo espacio y, a continuación, proporcione un espacio de direcciones IP diferente al espacio de direcciones utilizado por la red virtual de la instancia principal. Por ejemplo, si la instancia principal actual usa un espacio de direcciones de 10.0.0.16, escriba 10.1.0.0/16 para el espacio de direcciones de la red virtual que quiere usar para la instancia secundaria.
    3. Use + Agregar una subred para agregar una subred predeterminada con valores predeterminados.
    4. Use + Agregar una subred para agregar una subred vacía denominada ManagedInstance que se dedicará a la instancia secundaria mediante un intervalo de direcciones diferente a la subred predeterminada. Por ejemplo, si la instancia principal usa un intervalo de direcciones de 10.0.0.0 - 10.0.255.255, proporcione un intervalo de subred de 10.1.1.0 - 10.1.1.255 para la subred de la instancia secundaria.

    Captura de pantalla del espacio de direcciones de una nueva red virtual en Azure Portal.

  5. Seleccione Revisar y crear para revisar la configuración y después use Crear para crear la nueva red virtual.

Creación de una instancia secundaria

Una vez que la red virtual esté lista, siga estos pasos para crear la instancia secundaria en Azure Portal:

  1. Vaya a Crear Azure SQL Managed Instance en el Azure Portal.

  2. En la pestaña Aspectos básicos de la página Crear Azure SQL Managed Instance:

    1. Elija una región para la instancia secundaria que esté emparejada con la instancia principal.
    2. Elija un nivel de servicio que coincida con el nivel de servicio de la instancia principal.

  3. En la pestaña Redes de la página Crear Instancia administrada de Azure SQL, use la lista desplegable en Red virtual o subred para seleccionar la red virtual y la subred que creó anteriormente:

    Captura de pantalla en la que se resalta la red que creó para usarla con la instancia secundaria en Azure Portal.

  4. En la pestaña Configuración adicional de la página Crear instancia administrada de Azure SQL, seleccione Sí para usar como secundaria de conmutación por error y, a continuación, elija la instancia principal adecuada en la lista desplegable.

    Captura de pantalla de Azure Portal que especifica la instancia administrada principal como secundaria de conmutación por error en la página de configuración adicional.

  5. Configure el resto de la instancia según sus necesidades empresariales y, a continuación, créela mediante Revisar y crear.

Establecimiento de la conectividad entre las instancias

Para que el flujo de tráfico de la replicación geográfica sea ininterrumpido, se debe establecer la conectividad entre las subredes de red virtual que hospedan las instancias principal y secundaria. Hay varias maneras de conectar instancias administradas en diferentes regiones de Azure, entre las que se incluyen:

El emparejamiento de red virtual global se recomienda como la manera más eficaz y sólida de establecer la conectividad entre las instancias y un grupo de conmutación por error. El emparejamiento de red virtual global proporciona una conexión privada de ancho de banda alto y baja latencia entre redes virtuales emparejadas mediante la infraestructura troncal de Microsoft. No se requiere ninguna red pública de Internet, puertas de enlace ni cifrado adicional en la comunicación entre las redes virtuales emparejadas.

Importante

Las formas alternativas de conectar instancias que implican dispositivos de red adicionales pueden complicar la solución de problemas de conectividad o velocidad de replicación, lo que podría requerir la participación activa de los administradores de red y, posiblemente, prolongar significativamente el tiempo de resolución.

Si usa un mecanismo para establecer la conectividad entre las instancias distinto del emparejamiento global de redes virtuales recomendado, debe asegurarse de lo siguiente:

  • El dispositivo de red, como firewalls o aplicaciones virtuales de red (NVA), no bloquea el tráfico en conexiones entrantes y salientes para el puerto 5022 (TCP) y el intervalo de puertos 11000-11999.
  • El enrutamiento está configurado correctamente y se evita el enrutamiento asimétrico.
  • Si implementa grupos de conmutación por error en una topología en estrella tipo hub-and-spoke entre regiones, para evitar problemas de conectividad y velocidad de replicación, 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.

Este artículo le guía para configurar el emparejamiento de red virtual global entre las redes de las dos instancias mediante Azure Portal y PowerShell.

  1. En el portal de Azure, vaya al recurso Red virtual para la instancia administrada principal.

  2. Seleccione Emparejamientos en Configuración para abrir la página Emparejamientos y, a continuación, use + Agregar desde la barra de comandos para abrir la página Agregar emparejamiento.

    Captura de pantalla de la página de emparejamiento de una red virtual A en Azure Portal.

  3. En la página Agregar emparejamiento, escriba o seleccione valores para las siguientes opciones:

    Configuración Descripción
    Resumen de red virtual remota
    Nombre del vínculo de emparejamiento el nombre del emparejamiento debe ser único dentro de la red virtual. En este artículo se usa Fog-peering.
    Modelo de implementación de red virtual Seleccione Administrador de recursos.
    Conozco mi Id. de recurso Puede dejar esta casilla desactivada, a menos que conozca el identificador de recurso.
    Subscription En la lista desplegable, seleccione la suscripción.
    Red virtual Seleccione la red virtual para la instancia secundaria en la lista desplegable.
    Configuración de emparejamiento de red virtual remota
    Permitir que "red virtual secundaria" acceda a "red virtual principal" Active la casilla para permitir la comunicación entre las dos redes. Al permitir la comunicación entre redes virtuales, los recursos conectados a cualquier red virtual se pueden comunicar entre sí, con el mismo ancho de banda y latencia que si estuvieran conectados a la misma red virtual. Todas las comunicaciones entre los recursos de las dos redes virtuales se realizan a través de la red privada de Azure.
    Permitir que la "red virtual secundaria" reciba tráfico reenviado desde la "red virtual principal" Puede activar o desactivar esta casilla, cualquier opción sirve para esta guía. Para obtener más información, consulte Creación de un emparejamiento.
    Permitir que la puerta de enlace o el servidor de enrutamiento en "red virtual secundaria" reenvíen el tráfico a la "red virtual principal" Puede activar o desactivar esta casilla, cualquier opción sirve para esta guía. Para obtener más información, consulte Creación de un emparejamiento.
    Habilite la "red virtual secundaria" para usar la puerta de enlace remota o el servidor de rutas de la red virtual principal Deje esta casilla desactivada. Para obtener más información sobre las otras opciones disponibles, consulte Creación de un emparejamiento.
    Resumen de red virtual local
    Nombre del vínculo de emparejamiento El nombre del mismo emparejamiento usado en la red virtual remota. En este artículo se usa Fog-peering.
    Permitir que "red virtual principal" acceda a "red virtual secundaria" Active la casilla para permitir la comunicación entre las dos redes. Al permitir la comunicación entre redes virtuales, los recursos conectados a cualquier red virtual se pueden comunicar entre sí, con el mismo ancho de banda y latencia que si estuvieran conectados a la misma red virtual. Todas las comunicaciones entre los recursos de las dos redes virtuales se realizan a través de la red privada de Azure.
    Permitir que la "red virtual principal" reciba tráfico reenviado desde la "red virtual secundaria" Puede activar o desactivar esta casilla, cualquier opción sirve para esta guía. Para obtener más información, consulte Creación de un emparejamiento.
    Permitir que la puerta de enlace o el servidor de enrutamiento en "red virtual principal" reenvíen el tráfico a la "red virtual secundaria" Puede activar o desactivar esta casilla, cualquier opción sirve para esta guía. Para obtener más información, consulte Creación de un emparejamiento.
    Habilite "red virtual principal" para usar la puerta de enlace remota o el servidor de rutas de la red virtual secundaria Deje esta casilla desactivada. Para obtener más información sobre las otras opciones disponibles, consulte Creación de un emparejamiento.

  4. Use Agregar para configurar el emparejamiento con la red virtual seleccionada y vuelva automáticamente a la página Emparejamientos, que muestra que las dos redes están conectadas:

    Captura de pantalla del estado del emparejamiento de red virtual en la página de emparejamientos de Azure Portal.

Configuración de puertos y reglas de NSG

Independientemente del mecanismo de conectividad elegido entre las dos instancias, las redes deben cumplir los siguientes requisitos para el flujo de tráfico de replicación geográfica:

  • La tabla de rutas y los grupos de seguridad de red asignados a las subredes de instancia administrada no se comparten entre las dos redes virtuales emparejadas.
  • Las reglas del grupo de seguridad de red (NSG) en ambas subredes que hospedan cada instancia permiten el tráfico entrante y saliente a la otra instancia del puerto 5022 y el intervalo de puertos 11000-11999.

Puede configurar la comunicación de puertos y las reglas de NSG mediante Azure Portal y PowerShell.

Para abrir los puertos del grupo de seguridad de red (NSG) en Azure Portal, siga estos pasos:

  1. Vaya al recurso Grupo de seguridad de red para la instancia principal.

  2. En Configuración, seleccione Reglas de seguridad de entrada. Compruebe si ya tiene reglas que permiten el tráfico para el puerto 5022 y el intervalo 11000-11999. Si lo hace y el origen satisface sus necesidades empresariales, omita este paso. Si las reglas no existen o si desea usar otro origen (por ejemplo, la dirección IP más segura) elimine la regla existente y, después, seleccione + Agregar en la barra de comandos para abrir el panel Agregar regla de seguridad de entrada:

    Captura de pantalla de la adición de reglas de seguridad de entrada para NSG en Azure Portal.

  3. En el panel Agregar regla de seguridad de entrada, introduzca o seleccione valores para los siguientes ajustes:

    Configuración Valor recomendado Descripción
    Origen Direcciones IP o etiqueta de servicio Filtro para el origen de la comunicación. La dirección IP es la más segura y se recomienda para entornos de producción. La etiqueta de servicio es adecuada para entornos que no son de producción.
    Etiqueta de servicio de origen Si seleccionó Etiqueta de servicio como origen, proporcione VirtualNetwork como etiqueta de origen. Las etiquetas predeterminadas son identificadores predefinidos que representan una categoría de direcciones IP. La etiqueta VirtualNetwork denota todos los espacios de direcciones de red virtual y local.
    Direcciones IP de origen Si seleccionó direcciones IP como origen, proporcione la dirección IP de la instancia secundaria. Proporcione un intervalo de direcciones mediante notación CIDR (por ejemplo, 192.168.99.0/24 o 2001:1234::/64) o una dirección IP (por ejemplo, 192.168.99.0 o 2001:1234::). También puede proporcionar una lista separada por comas de direcciones IP o rangos de direcciones utilizando IPv4 o IPv6.
    Intervalos de puertos de origen 5022 Esto especifica en qué puertos se permitirá el tráfico de esta regla.
    Service Personalizado El servicio especifica el intervalo de puerto y protocolo de destino para esta regla.
    Intervalos de puertos de destino 5022 Esto especifica en qué puertos se permitirá el tráfico de esta regla. Este puerto debe coincidir con el intervalo de puertos de origen.
    Action Permitir Permitir la comunicación en el puerto especificado.
    Protocolo TCP Determina el protocolo para la comunicación de puertos.
    Prioridad 1200 Las reglas se procesan en orden de prioridad; cuanto menor sea el número, mayor será la prioridad.
    Nombre allow_geodr_inbound Nombre de la regla.
    Descripción Opcionales Puede elegir proporcionar una descripción o dejar este campo en blanco.

    Seleccione Agregar para guardar la configuración y agregar la nueva regla.

  4. Repita estos pasos para agregar otra regla de seguridad de entrada para el intervalo de puertos 11000-11999 con un nombre como allow_redirect_inbound y una prioridad ligeramente superior a la regla 5022, como 1100.

  5. En Configuración, seleccione Reglas de seguridad de salida. Compruebe si ya tiene reglas que permiten el tráfico para el puerto 5022 y el intervalo 11000-11999. Si lo hace y el origen satisface sus necesidades empresariales, omita este paso. Si las reglas no existen o si desea usar otro origen (por ejemplo, la dirección IP más segura), elimine la regla existente y, después, seleccione + Agregar en la barra de comandos para abrir el panel Agregar regla de seguridad de salida.

  6. En el panel Agregar regla de seguridad de salida, use la misma configuración para el puerto 5022 y el intervalo 11000-11999 que hizo para los puertos de entrada.

  7. Vaya al grupo de seguridad de red de la instancia secundaria y repita estos pasos para que ambos grupos de seguridad de red tengan las siguientes reglas:

    • Permitir el tráfico entrante en el puerto 5022
    • Permitir el tráfico entrante en el intervalo de puertos 11000-11999
    • Permitir el tráfico saliente en el puerto 5022
    • Permitir el tráfico saliente en el intervalo de puertos 11000-11999

Creación del grupo de conmutación por error

Cree el grupo de conmutación por error para sus instancias administradas mediante Azure Portal o PowerShell.

Cree el grupo de conmutación por error para sus Instancias administradas de SQL mediante Azure Portal.

  1. Seleccione Azure SQL en el menú izquierdo de Azure Portal. Si Azure SQL no está en la lista, seleccione Todos los servicios y escriba Azure SQL en el cuadro de búsqueda. (Opcional) Seleccione la estrella junto a Azure SQL para agregarlo como elemento favorito al panel de navegación izquierdo.

  2. Seleccione la instancia administrada principal que desea agregar al grupo de conmutación por error.

  3. En Administración de datos, seleccione Grupos de conmutación por error y luego Agregar grupo para abrir la página Grupo de conmutación por error de instancias:

    Captura de pantalla de la adición de una página de un grupo de conmutación por error en Azure Portal.

  4. En la página Grupo de migración tras error de instancia:

    1. La instancia administrada principal está preseleccionada.
    2. En Nombre del grupo de conmutación por error, escriba un nombre para el grupo de conmutación por error.
    3. En Instancia administrada secundaria, seleccione la instancia administrada que desea usar como secundaria en el grupo de conmutación por error.
    4. Elija una directiva de conmutación por error de lectura y escritura en la lista desplegable. Se recomienda manual para proporcionarle control sobre la conmutación por error.
    5. Deje Habilitar derechos de conmutación por error en Desactivado, a menos que quiera usar esta réplica solo para la recuperación ante desastres.
    6. Use Crear para guardar la configuración y crear el grupo de conmutación por error.

    Captura de pantalla para crear un grupo de conmutación por error en Azure Portal.

  5. Una vez empezada la implementación del grupo de conmutación por error, vuelve a mostrarse la página grupos de conmutación por error. La página se actualiza para mostrar el nuevo grupo de conmutación por error una vez completada la implementación.

Conmutación por error de prueba

Pruebe la conmutación por error de su grupo de conmutación por error mediante Azure Portal o PowerShell.

Nota:

Si las instancias están en distintas suscripciones o grupos de recursos, inicie la conmutación por error desde la instancia secundaria.

Pruebe la conmutación por error de su grupo de conmutación por error mediante Azure Portal.

  1. Vaya a la instancia administrada principal o secundaria en Azure Portal.

  2. En seleccione Administración de datos, seleccione Grupos de conmutación por error.

  3. En el panel Grupos de migración tras error, observe qué instancia es la principal y qué instancia es la secundaria.

  4. En el panel Grupos de migración tras error, seleccione migración tras error en la barra de comandos. Seleccione Sí en la advertencia sobre las sesiones de TDS que se desconectan y anote la implicación de las licencias.

    Captura de pantalla para conmutar por error el grupo de conmutación por error en Azure Portal.

  5. En el panel Grupos de migración tras error, después de que la migración tras error se realice correctamente, las instancias cambian de roles para que la secundaria anterior se convierta en la nueva principal y la principal anterior se convierta en la nueva secundaria.

    Importante

    Si los roles no han cambiado, compruebe la conectividad entre las instancias y las reglas de firewall y NSG relacionadas. Continúe con el paso siguiente solo después de cambiar los roles.

  6. (Opcional) En el panel Grupos de migración tras error, use migración tras error para volver a cambiar los roles para que la principal original vuelva a ser principal.

Modificar un grupo de migración tras error existente

Puede modificar un grupo de migración tras error existente, como para cambiar la directiva de migración tras error, mediante Azure Portal, PowerShell, la CLI de Azure y las API REST.

Para modificar un grupo de migración tras error existente mediante Azure Portal, siga estos pasos:

  1. Vaya a SQL Managed Instance en Azure Portal.

  2. En Administración de datos, seleccione Grupos de migración tras error para abrir el panel Grupos de migración tras error.

  3. En el panel Grupos de migración tras error, seleccione Editar configuraciones en la barra de comandos para abrir el panel Editar grupo de migración tras error:

    Captura de pantalla del panel del grupo de migración tras error en Azure Portal, con la opción Editar configuraciones resaltada.

Búsqueda del punto de conexión del cliente de escucha

Una vez configurado el grupo de conmutación por error, actualice la cadena de conexión de la aplicación para que apunte al punto de conexión del agente de escucha de lectura y escritura para que la aplicación continúe conectándose a la instancia principal después de la conmutación por error. Con el punto de conexión del agente de escucha, no es necesario actualizar manualmente la cadena de conexión cada vez que el grupo de conmutación por error conmuta por error, ya que el tráfico siempre se enruta al principal actual. También puede apuntar la carga de trabajo de solo lectura al punto de conexión del agente de escucha de solo lectura.

Importante

Aunque se admite la conexión a una instancia de un grupo de migración tras error mediante la cadena de conexión específica de la instancia, no es nada recomendable. En su lugar, use los puntos de conexión de la escucha.

Para buscar el punto de conexión del agente de escucha en Azure Portal, vaya a la instancia administrada de SQL y, en Administración de datos, seleccione Grupos de conmutación por error.

Desplácese hacia abajo para buscar los puntos de conexión del agente de escucha:

  • El punto de conexión del agente de escucha de lectura y escritura, en forma de fog-name.dns-zone.database.windows.net, enruta el tráfico a la instancia principal.
  • El punto de conexión del agente de escucha de solo lectura, en forma de fog-name.secondary.dns-zone.database.windows.net, enruta el tráfico a la instancia secundaria.

Captura de pantalla en la que se indica dónde se encuentra la cadena de conexión del grupo de conmutación por error en Azure Portal.

Creación de un grupo de migración tras error entre instancias en distintas suscripciones

Puede crear un grupo de conmutación por error entre instancias de SQL Managed Instance en dos suscripciones diferentes, siempre que estén asociadas al mismo inquilino de Microsoft Entra.

  • Al usar la API de PowerShell, puede hacerlo especificando el parámetro PartnerSubscriptionId de la instancia secundaria de SQL Managed Instance.
  • Al usar la API REST, cada identificador de instancia incluido en el parámetro properties.managedInstancePairs puede tener su propio id. de suscripción.
  • Azure Portal no admite la creación de grupos de conmutación por error en distintas suscripciones.

Importante

Azure Portal no admite la creación de grupos de conmutación por error en distintas suscripciones. Para los grupos de conmutación por error en distintas suscripciones y/o grupos de recursos, no se puede iniciar manualmente la conmutación por error mediante el portal de Azure desde la instancia administrada principal de SQL. En su lugar, se inicia desde la instancia de la base de datos geográfica secundaria.

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. Pero no espera a que las transacciones transmitidas se reproduzcan (vuelvan a hacerse) en la 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.

Cambio de la región secundaria

Supongamos que la instancia A es la principal, la B es la instancia secundaria existente y la C es la nueva instancia secundaria de la tercera región. Para realizar la transición, siga estos pasos:

  1. Cree la instancia C con el mismo tamaño que la instancia A y en la misma zona DNS.
  2. Elimina el grupo de conmutación por error entre las instancias A y B. En este momento, se produce un error en los intentos de inicios de sesión porque se han eliminado los alias de SQL de los clientes de escucha del grupo de conmutación por error y la puerta de enlace no reconocerá el nombre del grupo de conmutación por error. Las bases de datos secundarias se desconectan de las principales y se convierten en bases de datos de lectura y escritura.
  3. Crea un grupo de conmutación por error con el mismo nombre entre las instancias A y C. Sigue las instrucciones de la guía para congigurar grupos de conmutación por error. Se trata de una operación de tamaño de datos, que se completa cuando todas las bases de datos de la instancia A se inicialicen y se sincronicen.
  4. Si no es necesario, elimine la instancia B para evitar cargos innecesarios.

Nota:

Después del paso 2 y hasta que se complete el paso 3, las bases de datos de la instancia A permanecerán desprotegidas frente a un error catastrófico en la instancia A.

Cambio de la región primaria

Supongamos que la instancia A es la principal, la B es la instancia secundaria existente y la C es la nueva instancia principal de la tercera región. Para realizar la transición, siga estos pasos:

  1. Cree la instancia C con el mismo tamaño que la instancia B y en la misma zona DNS.
  2. Inicie una conmutación por error manual desde la instancia B para que sea la nueva principal. La instancia A se convierte automáticamente en la nueva instancia secundaria.
  3. Elimina el grupo de conmutación por error entre las instancias A y B. En este momento, se produce un error en los intentos de inicio de sesión mediante el uso de los puntos de conexión del grupo de conmutación por error. Las bases de datos secundarias en A se desconectan de las principales y se convierten en bases de datos de lectura y escritura.
  4. Cree un grupo de conmutación por error con el mismo nombre entre la instancia B y C. Se trata de una operación de tamaño de datos y se completa cuando todas las bases de datos de la instancia B se inicialicen y sincronicen con la instancia C. En este momento, los intentos de inicio de sesión dejan de generar errores.
  5. Realice una conmutación por error manual para cambiar la instancia C al rol principal. La instancia B se convierte automáticamente en la nueva instancia secundaria.
  6. Si no es necesario, elimine la instancia A para evitar cargos innecesarios.

Precaución

Después del paso 3 y hasta que se complete el paso 4, las bases de datos de la instancia A permanecerán desprotegidas frente a un error catastrófico en la instancia A.

Importante

Cuando se elimina el grupo de conmutación por error, también se eliminan los registros de DNS de los puntos de conexión del agente de escucha. En ese momento, existe una probabilidad distinta de cero de que otra persona cree un grupo de conmutación por error con el mismo nombre. Dado que los nombres de grupo de conmutación por error deben ser únicos globalmente, esto impedirá que vuelva a usar el mismo nombre. Para minimizar este riesgo, no utilice nombres de grupo de conmutación por error genéricos.

Cambiar la directiva de actualización

Las instancias de un grupo de migración tras error deben tener directivas de actualización coincidentes. Para habilitar la directiva de actualización siempre actualizada en instancias que forman parte de un grupo de migración tras error, habilite primero la directiva de actualización siempre actualizada en la instancia secundaria, espere a que el cambio entre en vigor y, a continuación, actualice la directiva para la instancia principal.

Al cambiar la directiva de actualización en la instancia principal del grupo de migración tras error, la instancia se conmuta por error a otro nodo local (similar a las operaciones de administración en instancias que no forman parte de un grupo de conmutación por error), no hace que el grupo de conmutación por error conmute por error, manteniendo la instancia principal en el rol principal.

Precaución

Una vez que la directiva actualizada se cambia a Siempre actualizada, ya no es posible cambiarla a la directiva de actualización de SQL Server 2022.

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.

Escalado de instancias

Puede escalar verticalmente o reducir verticalmente la instancia principal o secundaria a un tamaño de proceso diferente en el mismo nivel de servicio. Cuando se escala verticalmente dentro del mismo nivel de servicio, escale verticalmente primero la secundaria geográfica y, después, escale verticalmente la principal. Al reducir verticalmente dentro del mismo nivel de servicio, invierta el orden: primero escale verticalmente la principal y, a continuación, escale verticalmente la secundaria. Siga la misma secuencia al escalar una instancia a otro nivel de servicio.

Esta secuencia se recomienda para evitar que la base de datos geográfica secundaria de una SKU inferior se sobrecargue y deba propagarse durante un proceso de actualización o cambio a una versión anterior.

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 rol Colaborador de SQL Managed Instance, que cuenta con un ámbito para los grupos de recursos de las instancias administradas principal y secundaria, es suficiente para realizar todas las operaciones de administración en grupos de conmutación por error.

En la tabla siguiente se proporciona una vista granular de los permisos necesarios mínimos y sus respectivos niveles de ámbito mínimos necesarios para las operaciones de administración en grupos de conmutación por error:

Operación de administración Permiso Ámbito
Actualización/Creación de un grupo de conmutación por error Microsoft.Sql/locations/instanceFailoverGroups/write Grupos de recursos de las instancias administradas principal y secundaria
Actualización/Creación de un grupo de conmutación por error Microsoft.Sql/managedInstances/write Instancias administradas principal y secundaria
Conmutación por error de un grupo de conmutación por error Microsoft.Sql/locations/instanceFailoverGroups/failover/action Grupos de recursos de las instancias administradas principal y secundaria
Forzar la conmutación por error en el grupo de conmutación por error Microsoft.Sql/locations/instanceFailoverGroups/forceFailoverAllowDataLoss/action Grupos de recursos de las instancias administradas principal y secundaria
Eliminación del grupo de conmutación por error Microsoft.Sql/locations/instanceFailoverGroups/delete Grupos de recursos de las instancias administradas principal y secundaria

Limitaciones

Al crear un grupo de migración tras error, tenga en cuenta las siguientes limitaciones:

  • No se pueden crear grupos de migración tras error entre dos instancias en la misma región de Azure.
  • Una instancia puede participar en solo un grupo de conmutación por error en cualquier momento.
  • No se puede crear un grupo de migración tras error entre dos instancias que pertenezcan a distintos inquilinos de Azure.
  • La creación de un grupo de conmutación por error entre dos instancias de diferentes grupos de recursos o suscripciones solo se admite con Azure PowerShell, o con la API de REST, y no con Azure Portal ni con la CLI de Azure. Una vez creado el grupo de conmutación por error, está visible en Azure Portal y todas las operaciones se admiten en Azure Portal o con la CLI de Azure. La conmutación por error debe iniciarse desde la instancia secundaria.
  • Si la propagación inicial de todas las bases de datos no se completa en un plazo de 7 días, se produce un error al crear el grupo de migración tras error y todas las bases de datos replicadas correctamente se eliminan de la instancia secundaria.
  • Actualmente no se admite la creación de un grupo de conmutación por error con una instancia configurada con un vínculo de instancia administrada.
  • No se pueden crear grupos de conmutación por error entre instancias si alguna de ellas se encuentra en un grupo de instancias.
  • Las bases de datos migradas a Azure SQL Managed Instance mediante el Servicio de reproducción de registros (LRS) no se pueden agregar a un grupo de migración tras error hasta que se ejecute el paso de transición.

Tenga en cuenta las siguientes limitaciones al usar los grupos de migración tras error:

  • No se puede cambiar el nombre de los grupos de conmutación por error. Tendrá que eliminar el grupo y volver a crearlo con otro nombre.
  • Un grupo de conmutación por error contiene exactamente dos instancias administradas. No se admite la incorporación de instancias adicionales al grupo de conmutación por error.
  • Las copias de seguridad completas se realizan automáticamente:
    • antes de la propagación inicial, y puede retrasar considerablemente el inicio del proceso de propagación inicial.
    • después de la migración tras error, y puede retrasar o evitar una migración tras error posterior.
  • 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.
  • Para las instancias dentro de un grupo de conmutación por error, no se admite el cambio del nivel de servicio a, o desde, el nivel de uso general de próxima generación. Primero debe eliminar el grupo de conmutación por error antes de modificar cualquiera de las réplicas y, a continuación, volver a crear el grupo de conmutación por error después de que el cambio surta efecto.
  • Las instancias administradas de SQL en un grupo de migración tras error deben tener la misma directiva de actualización, aunque es posible cambiar la directiva de actualización para las instancias de un grupo de migración tras error.

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

Los grupos de conmutación por error también se pueden administrar mediante programación con Azure PowerShell, la CLI de Azure y la API de REST. En las tablas siguientes se describe el conjunto de comandos disponibles. Los grupos de conmutación por error incluyen un conjunto de API de Azure Resource Manager para la administración, en el que se incluyen la API de 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.

Contenido relacionado