Migración de Azure SQL Database a compatibilidad con zonas de disponibilidad

Artículo
04/14/2024

En esta guía se describe cómo migrar Azure SQL Database sin compatibilidad con las zonas de disponibilidad para lograrla.

La habilitación de la redundancia de zona para Azure SQL Database garantiza la alta disponibilidad, ya que la base de datos utiliza Azure Availability Zones para replicar datos en varias ubicaciones físicas dentro de una región de Azure. Al seleccionar redundancia de zona, puede hacer que las bases de datos y los grupos elásticos sean resistentes a un conjunto mayor de errores, como interrupciones catastróficas del centro de datos, sin cambios en la lógica de la aplicación.

Requisitos previos

Antes de migrar a la compatibilidad con zonas de disponibilidad, consulte la tabla siguiente para asegurarse de que Azure SQL Database se encuentra en un modelo de implementación y nivel de servicio admitidos. Asegúrese de que el nivel y el modelo se ofrecen en una región que admite zonas de disponibilidad.

Nivel de servicio	Modelo de implementación	Disponibilidad de redundancia de zona
Premium	Base de datos única o grupo elástico	Todas las regiones que admiten zonas de disponibilidad
Crítico para la empresa	Base de datos única o grupo elástico	Todas las regiones que admiten zonas de disponibilidad
Uso general	Base de datos única o grupo elástico	Regiones seleccionadas que admiten zonas de disponibilidad
Hiperescala	Base de datos única	Todas las regiones que admiten zonas de disponibilidad

Requisitos de tiempo de inactividad

La migración para el nivel de servicio Premium, Crítico para la empresa y Uso general es una operación en línea con una breve desconexión hacia el final para finalizar el proceso de migración. Si ha implementado lógica de reintento para errores transitorios estándar, no observará la conmutación por error.

En el caso del nivel de servicio Hiperescala, la compatibilidad con redundancia de zona solo se puede especificar durante la creación de la base de datos y no se puede modificar una vez que se aprovisiona el recurso. Si desea pasar a la compatibilidad con la zona de disponibilidad, deberá transferir los datos con copia de base de datos, restauración a un momento dado o réplica geográfica. Si la base de datos de destino está en una región diferente a la del origen o si la redundancia del almacenamiento de copia de seguridad de la base de datos de base de datos para el destino difiere de la base de datos de origen, el tiempo de inactividad es proporcional al tamaño de la operación de datos.

Migración (Premium, Crítico para la empresa y Uso general)

Para los niveles de servicio Premium, Crítico para la empresa y Uso general, es posible la migración a la redundancia de zona.

Siga los pasos siguientes para realizar la migración para una base de datos única o un grupo elástico.

Migración a una base de datos única

Vaya a Azure Portal para encontrar su base de datos. Busque y seleccione base de datos SQL.
Seleccione la base de datos que desea migrar.
En Configuración, seleccione Proceso y almacenamiento.
Seleccione Sí para ¿Desea que esta zona de base de datos tenga redundancia?
Seleccione Aplicar.
Espere a recibir un aviso de finalización de la operación en Notificaciones en el menú superior de Azure Portal.
Para comprobar que la redundancia de zona está habilitada, seleccione Información general y, a continuación, seleccione Propiedades.
En la sección Disponibilidad, confirme que la redundancia de zona está establecida en Habilitado.

Abra PowerShell como administrador y ejecute el comando siguiente (reemplace los marcadores de posición en "<>" por los nombres de recursos). Tenga en cuenta que <server_name> no debe incluir .database.windows.net.

Connect-AzAccount
$subscriptionid = <'your subscription id here'>
Set-AzContext -SubscriptionId $subscriptionid

$parameters = @{
    ResourceGroupName = '<Resource_Group_Name>'
    ServerName = '<Server_Name>'
    DatabaseName = '<Database_Name>'
}
Set-AzSqlDatabase @parameters -ZoneRedundant

Use la CLI de Azure para ejecutar el comando siguiente (reemplace los marcadores de posición en "<>" por los nombres de recursos):

    az sql db update --resource-group “<Resource_Group_Name>” --server “<Server_Name>” --name “<Database_Name>” --zone-redundant

Migración de un grupo elástico

Importante

La habilitación de la compatibilidad con redundancia de zona para grupos elásticos hace que todas las bases de datos dentro de la zona del grupo tengan redundancia.

Vaya al Azure Portal para buscar y seleccionar el grupo elástico que desea migrar.
Seleccione Configuracióny, a continuación, seleccione Configurar.
Seleccione Sí para ¿Desea que esta zona del grupo elástico tenga redundancia?.
Seleccione Guardar.
Espere a recibir un aviso de finalización de la operación en Notificaciones en el menú superior de Azure Portal.
Para comprobar que la redundancia de zona está habilitada, seleccione Configurar y, a continuación, seleccione Configuración del grupo.
La opción con redundancia de zona debe establecerse en Sí.

Connect-AzAccount
$subscriptionid = <'your subscription id here'>
Set-AzContext -SubscriptionId $subscriptionid

$parameters = @{
    ResourceGroupName = '<Resource_Group_Name>'
    ServerName = '<Server_Name>'
    ElasticPoolName = '<Elastic_Pool_Name>'
}

Set-AzSqlElasticPool  @parameters -ZoneRedundant

Use la CLI de Azure para ejecutar el comando siguiente (reemplace los marcadores de posición en "<>" por los nombres de recursos):

    az sql elastic-pool update --resource-group “<Resource_Group_Name>” --server “<Server_Name>” --name “<Elastic_Pool_Name>” --zone-redundant

Reimplementación (Hiperescala)

Para el nivel de servicio Hiperescala, la compatibilidad con redundancia de zona solo se puede especificar durante la creación de la base de datos y no se puede modificar una vez aprovisionada la base de datos. Si desea obtener compatibilidad con redundancia de zona, debe realizar una transferencia de datos desde la base de datos única de nivel de servicio de Hiperescala existente. Para realizar la transferencia y habilitar la opción de redundancia de zona, se debe crear un clon mediante la copia de base de datos, la restauración a un momento dado o la réplica geográfica.

Consideraciones de la reimplementación

Hay dos modos de reimplementación (en línea y sin conexión):
- Los métodos de copia de base de datos y restauración a un momento dado (modo sin conexión) crear una base de datos transaccionalmente coherente en un momento dado. Como resultado, los cambios de datos realizados después de iniciar la operación de copia o restauración no estarán disponibles en la base de datos copiada o restaurada.
- Método de réplica geográfica (modo en línea) es una reimplementación en la que los cambios de datos del origen se sincronizan con el destino.
La cadena de conexión de la aplicación debe actualizarse para que apunte a la base de datos con redundancia de zona.

Reimplementación de una base de datos única

Copia de base de datos

Para crear una copia de base de datos y habilitar la redundancia de zona con Azure Portal, PowerShell o la CLI de Azure, siga las instrucciones de copiar una copia transaccionalmente coherente de una base de datos en Azure SQL Database.

Restauración a un momento dado

Para crear una restauración de base de datos a un momento dado y habilitar la redundancia de zona con Azure Portal, PowerShell o la CLI de Azure, siga las instrucciones de restauración a un momento dado.

Replicación geográfica

Para crear una réplica geográfica de la base de datos:

Siga las instrucciones de Azure Portal, PowerShell o la CLI de Azure en Configuración de la replicación geográfica activa y la conmutación por error (Azure SQL Database) y habilite la redundancia de zona en Proceso y almacenamiento
La réplica se inicializará y el tiempo necesario para inicializar los datos depende del tamaño de la base de datos de origen. Puede supervisar el estado de propagación en Azure Portal o ejecutando las siguientes consultas TSQL en la base de datos de réplica:
```
    SELECT * FROM sys.dm_geo_replication_link_status;
    SELECT * FROM sys.dm_operation_status;
```
Una vez finalizada la propagación de la base de datos, realice una conmutación por error planeada (sin pérdida de datos) para que la base de datos de destino con redundancia de zona sea principal. Use el sys.dm_geo_replication_link_status para ver el estado de la situación de replicación geográfica. El replication_state_desc es CATCH_UP cuando la base de datos secundaria está en un estado transaccionalmente coherente. En la vista de administración dinámica de sys.dm_operation_status, busque state_desc que sea COMPLETED cuando se haya completado la operación de propagación.
Actualice el nombre del servidor en las cadenas de conexión de la aplicación para reflejar la nueva base de datos con redundancia de zona.
Para limpiarlo, considere la posibilidad de quitar la base de datos no con redundancia de zona original de la relación de réplica geográfica. Puede optar por eliminarlo.

Deshabilitación de la redundancia de zona

Para deshabilitar la redundancia de zona para una base de datos única o un grupo elástico, puede usar el portal o la API de ARM.

Para deshabilitar la redundancia de zona para el nivel de servicio Hiperescala, puede revertir los pasos documentados en Reimplementación (Hiperescala).

Grupo elástico
Base de datos única

Para deshabilitar la redundancia de zona con Azure Portal:

Vaya al Azure Portal para buscar y seleccionar el grupo elástico que ya no desea tener redundancia de zona.
Seleccione Configuracióny, a continuación, seleccione Configurar.
Seleccione No para ¿Desea que esta zona del grupo elástico tenga redundancia?.
Seleccione Guardar.

Para deshabilitar la redundancia de zona con ARM, consulte Base de datos: creación o actualización en ARM and use la propiedad properties.zoneRedundant.