Configuración de una réplica en espera sin licencia (versión preliminar) para Azure SQL Database

  • Artículo

Se aplica a:Azure SQL Database

En este artículo se describe cómo puede ahorrar en los costos de licencias mediante la designación de la base de datos de recuperación ante desastres secundaria (DR) para espera cuando se usa Azure SQL Database.

Nota:

Las réplicas de Azure SQL Database en espera se encuentran actualmente en versión preliminar.

Información general

Cuando una réplica de base de datos secundaria solo se usa para la recuperación ante desastres y no tiene cargas de trabajo que se ejecuten en ella o las aplicaciones que se conectan a ella, puede ahorrar en costos de licencias mediante la designación de la base de datos como réplica en espera. Cuando una base de datos secundaria se designa para la espera, Microsoft le proporciona la cantidad de núcleos virtuales con licencia para la base de datos principal sin cargo adicional en virtud de las ventajas de derechos de conmutación por error de los términos de licencia del producto. Se le seguirá facturando por el proceso y el almacenamiento que usa la base de datos secundaria.

Puede designar una réplica para espera al configurar una nueva replicación de replicación geográfica activa, o puede convertir una réplica existente para que se convierta una réplica en espera.

Aunque la replicación geográfica activa admite la adición de cuatro réplicas secundarias, solo puede designar una réplica de base de datos secundaria para espera. Los grupos de conmutación por error admiten una réplica de base de datos secundaria por base de datos principal y pueden ser legibles o en espera.

Durante una conmutación por error planificada o no planificada, la réplica en espera se convierte en el nuevo principal y empieza a incurrir en los costos habituales de las licencias de vCore, mientras que el principal original se convierte en el nuevo secundario en espera y deja de incurrir en los costos de las licencias de vCore.

Para obtener más información, vea este vídeo de Datos expuestos:

Ventaja del costo

Cuando designa una réplica de base de datos como en espera, Microsoft no le cobra los costos de licencia de SQL Server por los núcleos virtuales utilizados por la réplica en espera. Sin embargo, dado que la base de datos se factura por la hora completa, es posible que se le sigan cobrando costos de licencia por toda la hora si el cambio de estado se realiza a mitad de la hora.

La ventaja se traduce de forma diferente entre los clientes que usan el modelo de pago por uso y los clientes que usan el modelo Ventaja híbrida de Azure. Para un cliente de pago por uso, los núcleos virtuales se descuentan de su factura. Para un cliente que usa la Ventaja híbrida de Azure para la réplica en espera, el número de núcleos virtuales que la réplica secundaria usa se devuelve a su grupo de licencias.

Por ejemplo, como cliente de pago por uso, si tiene 16 núcleos virtuales asignados a la base de datos secundaria, aparece un descuento por 16 núcleos virtuales en la factura si designa la base de datos secundaria como solo en espera.

En otro ejemplo, si dispone de 16 licencias Azure Hybrid Benefit e implementa una base de datos que tiene 16 núcleos virtuales, después de designar la base de datos secundaria en espera, los 16 núcleos virtuales se devuelven a su grupo de licencias para que pueda utilizarlos con otras implementaciones Azure SQL.

Funcionalidades funcionales

La siguiente tabla describe las capacidades funcionales de una réplica de base de datos secundaria en espera:

Funcionalidad Descripción
Cargas de trabajo de lectura limitadas Después de designar la base de datos como en espera, solo puede ejecutar un número limitado de cargas de trabajo de lectura en la base de datos secundaria, como vistas de administración dinámica (DMV), copias de seguridad y consultas de comandos de consola de base de datos (DBCC).
Conmutación por error planeada Todos los escenarios de conmutación por error planeados, incluidos los simulacros de recuperación, la reasignación de bases de datos a diferentes regiones y la devolución de bases de datos a la réplica principal, son compatibles con la réplica en espera. Cuando la secundaria cambia a la principal, puede atender consultas de lectura y escritura. La nueva réplica secundaria (la principal original) se convierte en la réplica en espera y no debe usarse para cargas de trabajo de lectura.
Conmutación por error no planeada Durante una conmutación por error no planeada, una vez que la réplica secundaria cambia al rol principal, puede atender consultas de lectura y escritura. Una vez mitigada la interrupción y la réplica antigua principal se vuelva a conectar, se convierte en la nueva réplica en espera secundaria y no se debe usar para las cargas de trabajo de lectura.
Copia de seguridad y restauración El comportamiento de copia de seguridad y restauración entre una réplica en espera y una instancia administrada de réplica de base de datos legible es el mismo.
Supervisión Todas las operaciones de supervisión compatibles con una réplica secundaria legible son compatibles con la réplica en espera.

La réplica de base de datos en espera solo debe usarse para la recuperación ante desastres. No se pueden conectar aplicaciones de producción a la réplica. A continuación se muestran las únicas actividades que se permiten en la base de datos en espera:

  • Realización de operaciones de mantenimiento, como checkDB
  • Conexión de aplicaciones de supervisión
  • Ejecutar simulacros de recuperación ante desastres

Limitaciones

La siguiente tabla enumera los modelos de implementación admitidos y no admitidos:

Modelo de implementación Nivel de proceso Nivel de servicio Réplica en espera admitida Hardware
Base de datos única aprovisionado Uso general Sí Serie estándar (Gen5), serie FSv2, serie DC
Base de datos única aprovisionado Crítico para la empresa Sí Serie Estándar (Gen5), Serie DC
Base de datos única aprovisionado Hiperescala N/D N/D
Base de datos única Sin servidor All No N/D
Grupo elástico All Todo No N/D

El uso de una base de datos en espera tiene las siguientes limitaciones:

  • Solo se puede designar una réplica de base de datos secundaria para espera.
  • No se admite el nivel de computación sin servidor. La réplica en espera no se puede habilitar si la base de datos principal o secundaria está en el nivel de proceso sin servidor.
  • No se admite el modelo de compra de DTU. Puede habilitar una réplica en espera para las bases de datos mediante el modelo de compra de núcleo virtual únicamente.
  • No se admite el nivel de servicio Hiperescala. Solo las bases de datos de los niveles de servicio de uso general y Crítico para la empresa se pueden designar para espera.
  • Cuando se usa un grupo de conmutación por error, los derechos en espera se asignan en el nivel de base de datos, no en el nivel de grupo de conmutación por error y se deben asignar por separado para cada base de datos del grupo de conmutación por error.
  • No se admite la designación de una réplica secundaria para espera cuando la réplica es una réplica secundaria de una réplica secundaria (un proceso conocido es encadenamiento).

Requisitos previos

Configuración de una nueva réplica para espera

Puede designar una réplica para espera cuando configure una nueva relación de replicación geográfica activa mediante Azure Portal, PowerShell, la CLI de Azure o la API de REST.

Para crear una nueva relación de replicación geográfica activa y designar la base de datos secundaria para espera en Azure Portal, siga estos pasos:

  1. Vaya a su recurso de base de datos SQL en el Azure Portal.

  2. Elija Réplicas en Administración de datos en el menú de recursos y seleccione + Crear réplica para abrir la página Crear réplica geográfica de SQL Database.

    Captura de pantalla de la página de réplicas para la SQL Database en el Azure Portal.

  3. En la página Crear réplica geográfica de SQL Database, seleccione Réplica en espera para Tipo de réplica en Configuración de réplica. Active la casilla para confirmar que usará la réplica para el modo de espera.

    Captura de pantalla de la página Crear réplica geográfica con la réplica en espera resaltada en Azure Portal.

  4. Proporcione un servidor nuevo o existente para la nueva base de datos en espera y, a continuación, use Revisar + crear para realizar una validación final de los detalles de la base de datos y el servidor.

  5. Use Crear para confirmar la configuración y crear la nueva réplica de base de datos en espera.

Conversión de réplica existente

Puede utilizar el Azure portal o el comando de API de REST Vínculos de replicación - Actualizar para convertir una réplica existente de una replicación geográfica normal a una réplica en espera, o una réplica en espera a una replicación geográfica normal.

Para convertir una réplica existente en el Azure portal, siga estos pasos:

  1. Vaya a su recurso de base de datos SQL en el Azure Portal.
  2. Seleccione Réplicas en Administración de datos.
  3. Seleccione los puntos suspensivos (...) para la réplica y, a continuación:
    1. Para convertir una réplica normal en una réplica en espera, elija Convertir a réplica en espera. Marque la casilla junto a Confirmo... en la ventana emergente Convertir a réplica en espera y, a continuación, seleccione Sí para guardar el cambio y convertir la réplica.
    2. Para convertir una réplica en espera en una replicación geográfica normal, elija Convertir a geográfica. Marque la casilla junto a Confirmo... en la ventana emergente Convertir a replicación geográfica y, a continuación, seleccione Sí para guardar los cambios y convertir la réplica.

Para convertir una réplica existente mediante el comando de API de REST Vínculos de replicación - Actualizar, designe el linkType como STANDBY para una réplica en espera o GEO para convertir una réplica en espera existente de nuevo en una replicación geográfica normal.

Visualización de derechos de licencia

Puede ver los derechos de licencia de una base de datos existente utilizando el Azure Portal, PowerShell, la CLI de Azure o la API de REST.

Para comprobar los derechos de licencia de una base de datos existente mediante Azure Portal, siga estos pasos:

  1. Vaya a su base de datos SQL en el Azure Portal.

  2. En la página Información general, active Tipo de réplica en Essentials. Un valor de Standby indica que la base de datos es una réplica en espera y no se le cobra por los costos de licencia de SQL para esta base de datos:

    Captura de pantalla de la página de información general de la SQL Database en el Azure portal con el tipo de réplica resaltado.

Quitar réplica en espera

Después de designar una base de datos como en espera, no solo puede quitar la propiedad en espera. Para quitar una réplica en espera, debe detener la replicación para finalizar la relación de replicación geográfica activa. Después de que se detenga la replicación, la base de datos se convierte en independiente y comenzará a incurrir en costos de licencia.

Puede detener la replicación geográfica utilizando el portal de Azure, PowerShell, la CLI de Azure o la API de REST.

Para quitar una réplica en espera finalizando la replicación geográfica en Azure Portal, siga estos pasos:

  1. Vaya a su base de datos SQL en el Azure Portal.
  2. Seleccione Réplicas en Administración de datos.
  3. Seleccione los puntos suspensivos (...) de la réplica en espera y, a continuación, seleccione Detener replicación en el menú emergente. Esto detiene la replicación para que la base de datos secundaria ahora sea independiente en lugar de designada para el modo de espera e incurrir en costos de licencia.

Preguntas más frecuentes

  • ¿Cuáles son las implicaciones de precios y licencias?

    Las réplicas de base de datos secundarias se cobran por las licencias, el proceso y el almacenamiento de SQL para los datos y las copias de seguridad. Al designar una réplica de base de datos para espera, no se le cobrarán los costos de licencia de los núcleos virtuales usados por la réplica secundaria, pero todavía se le cobrará por el proceso y el almacenamiento.

  • ¿Cuáles son los ahorros aproximados con una réplica en espera?

    Sin costos de licencia, una réplica en espera es aproximadamente del 35 al 40 % menos costosa que una réplica secundaria totalmente legible normal, aunque el ahorro varía según la región. Para obtener un precio más preciso, use la Calculadora de precios de Azure y establezca la licencia de SQL Server en Ventaja híbrida de Azure.

  • ¿Cuántos núcleos virtuales estarán libres de licencia para la réplica en espera?

    El mismo número de núcleos virtuales que usa la base de datos principal. Se recomienda configurar la réplica secundaria con el mismo número de núcleos virtuales que la base de datos principal para lograr un rendimiento óptimo de replicación geográfica.

  • ¿Es necesario tener una licencia de SQL Server con Software Assurance activo para usar una réplica en espera?

    No. Dado que la réplica en espera no incurre en costos de licencias, no necesita una licencia activa de SQL Server con Software Assurance activo.

  • ¿Cómo puedo usar la réplica en espera?

    Las réplicas en espera están pensadas solo para fines de recuperación ante desastres (DR) y no pueden tener cargas de trabajo de lectura activas en ella. Las únicas cargas de trabajo aceptables son para la supervisión, el mantenimiento, como la ejecución de vistas de administración dinámica (DMV) y CheckDB.

  • ¿Puedo actualizar mi réplica secundaria legible existente a una réplica en espera para ahorrar costos?

    Sí, en Azure Portal, en el panel Réplicas. Seleccione los puntos suspensivos (...) y, a continuación, seleccione la opción Convertir la réplica.

  • ¿Puedo habilitar el Ventaja híbrida de Azure para la réplica en espera?

    Al designar una réplica para modo de espera, se reemplaza el descuento de la Ventaja híbrida de Azure, por lo que no se puede modificar el modelo de licencias de la réplica mediante Azure Portal. Sin embargo, si desea que la réplica en espera use la Ventaja híbrida de Azure después de la migración tras error, puede usar el comando Set-AzSqlDatabase de PowerShell o az sql db update de la CLI de Azure para actualizar el tipo de licencia a BasePrice (Ventaja híbrida de Azure) para que la réplica en espera se use cuando la réplica en espera se convierta en principal después de la migración tras error.

  • ¿Qué ocurre con el estado de la réplica en espera durante la conmutación por error?

    Durante los costos planeados o no conmutación por error planeada, la réplica en espera se convierte en la nueva principal que incurre en costos de licencia normales mientras que la principal original se convierte en la nueva base de datos secundaria en espera y deja de incurrir en costos de licencias de núcleo virtual. Sin embargo, dado que la instancia se factura por la hora completa, es posible que se le sigan cargando los costos de licencia del nuevo secundario durante toda la hora si el cambio de estado se produce en mitad de la hora. Si la principal original (que se convierte en el modo de espera después de la conmutación por error) usaba el Ventaja híbrida de Azure, el descuento de licencias en espera invalida el Ventaja híbrida de Azure usado por la base de datos.

  • ¿Qué ocurre si escalado verticalmente la base de datos principal o secundaria a un mayor tamaño de núcleo virtual?

    A la hora de ampliar, es una buena práctica ampliar primero la secundaria y después la principal. Aunque la réplica secundaria tendrá un número mayor de núcleos virtuales que la principal durante el período de transición, las ventajas de la réplica en espera se siguen aplicando. Intente minimizar el período de transición tanto como sea posible.

  • ¿Qué ocurre si se reduce verticalmente el tamaño principal o secundario a un menor tamaño de núcleo virtual?

    Al reducir verticalmente, es un procedimiento recomendado reducir verticalmente primero la base de datos principal y, a continuación, la secundaria. Aunque la réplica secundaria tendrá un número mayor de núcleos virtuales que la principal durante el período de transición, las ventajas de la réplica en espera se siguen aplicando. Intente minimizar el período de transición tanto como sea posible.

  • ¿Qué ocurre si se quita la relación de replicación geográfica entre la réplica principal y la réplica en espera?

    Después de quitar la replicación geográfica, la base de datos en espera se convierte en una base de datos independiente normal y comienza a incurrir en costos de licencia.

  • ¿Puedo obtener ventajas de capacidad reservada para la réplica en espera?

    Sí. Los precios de capacidad reservada son totalmente compatibles con la réplica en espera.

Contenido relacionado