Compartir a través de

Réplicas secundarias de Hiperescala

  • Artículo

Se aplica a: Azure SQL Database

Como se describe en Arquitectura de funciones distribuidas, Hiperescala de Azure SQL Database tiene dos tipos diferentes de nodos de proceso, también llamados réplicas:

Las réplicas secundarias siempre son de solo lectura y pueden ser de tres tipos diferentes:

  • Réplica de alta disponibilidad
  • Replicación geográfica
  • Réplica con nombre

Cada tipo tiene una arquitectura, un conjunto de características, un propósito y un costo diferentes. En función de las características que necesite, puede usar solo una o incluso las tres juntas. Puede usar réplicas secundarias con niveles de proceso sin servidor o aprovisionados.

Para ver tutoriales sobre cómo configurar y administrar réplicas con nombre de Hiperescala, consulte:

Réplica de alta disponibilidad

Una réplica de alta disponibilidad (HA) usa los mismos servidores de páginas que la réplica principal, por lo que no se requiere ninguna copia de datos para agregar una réplica de alta disponibilidad. Las réplicas de alta disponibilidad se usan para aumentar la disponibilidad de la base de datos; actúan como réplicas en espera activa con fines de conmutación por error. Si la réplica principal deja de estar disponible, la conmutación por error a una de las réplicas de alta disponibilidad existentes es automática y rápida. No es necesario cambiar la cadena de conexión; durante la conmutación por error, las aplicaciones pueden experimentar un tiempo de inactividad mínimo debido a que se eliminan las conexiones activas. Como de costumbre en este escenario, se recomienda una lógica de reintento adecuada. Varios controladores ya proporcionan cierto grado de lógica de reintento automático. Si usa .NET, la biblioteca Microsoft.Data.SqlClient más reciente proporciona compatibilidad completa nativa con la lógica de reintento automática configurable.

Las réplicas de alta disponibilidad usan el mismo nombre de servidor y base de datos que la réplica principal. Su objetivo de nivel de servicio (SLO) también es siempre el mismo que para la réplica principal. Las réplicas de alta disponibilidad no son visibles ni administrables como recursos independientes, desde el portal o desde ninguna API. Se facturan a la misma velocidad de proceso que la réplica principal, pero los costos de almacenamiento no se aplican a las réplicas secundarias.

Puede haber de cero a cuatro réplicas de alta disponibilidad. Puede especificar las réplicas numéricas durante la creación de una nueva base de datos o actualizar el número de réplicas de una base de datos existente. Puede usar los puntos de conexión y las herramientas de administración comunes (por ejemplo: Azure PowerShell, CLI de Azure, Azure Portal, API de REST) para especificar el número de réplicas de alta disponibilidad. La creación o eliminación de réplicas de alta disponibilidad no afecta a las conexiones activas en la réplica principal.

Conexión a una réplica de alta disponibilidad

En las bases de datos de Hiperescala, el argumento ApplicationIntent de la cadena de conexión usada por el cliente dictamina si la conexión se enruta a la réplica de lectura y escritura principal o a una réplica de solo lectura de alta disponibilidad. Si ApplicationIntent se establece en ReadOnly y la base de datos no tiene una réplica secundaria, la conexión se enruta a la réplica principal y el comportamiento predeterminado del ReadWrite.

-- Connection string with application intent
Server=tcp:<myserver>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;User ID=<myLogin>;Password=<myPassword>;Trusted_Connection=False; Encrypt=True;

Todas las réplicas de alta disponibilidad son idénticas en su capacidad de recursos. Si hay más de una réplica de alta disponibilidad, la carga de trabajo de intención de lectura se distribuye arbitrariamente entre todas las réplicas de alta disponibilidad disponibles. Cuando haya varias réplicas de alta disponibilidad, tenga en cuenta que cada una de ellas podría tener una latencia de datos diferente con respecto a los cambios de datos realizados en la réplica principal. Cada réplica de alta disponibilidad utiliza los mismos datos que la principal en el mismo conjunto de servidores de páginas. No obstante, las cachés de datos locales de cada réplica de alta disponibilidad reflejan los cambios realizados en la réplica principal mediante el servicio de registro de transacciones, que reenvía las entradas del registro de la réplica principal a las réplicas de alta disponibilidad. Como resultado, dependiendo de la carga de trabajo que se ejecuta en la réplica de alta disponibilidad, la aplicación de registros de registros puede ocurrir a diferentes velocidades y, por tanto, las distintas réplicas podrían tener una latencia de datos diferente en relación con la réplica principal.

Réplica con nombre

Una réplica con nombre, al igual que una réplica de alta disponibilidad, usa los mismos servidores de páginas que la réplica principal. De forma similar a las réplicas de alta disponibilidad, no se necesita ninguna copia de datos para agregar una réplica con nombre.

Hay diferencias entre las réplicas de alta disponibilidad y las réplicas con nombre:

  • Las réplicas con nombre aparecen como bases de datos de Azure SQL normales (de solo lectura) en el portal y en las llamadas de API (CLI de Azure, Azure PowerShell, T-SQL).
  • La réplicas con nombre pueden tener un nombre de base de datos diferente de la réplica principal y, opcionalmente, estar ubicadas en un servidor lógico diferente (siempre que esté en la misma región que la réplica principal).
  • La réplicas con nombre tienen su propio objetivo de nivel de servicio, que se puede establecer y cambiar independientemente de la réplica principal.
  • La réplicas con nombre admiten hasta 30 réplicas con nombre (para cada réplica principal).
  • La réplicas con nombre admiten autenticación diferente para cada réplica con nombre mediante la creación de diferentes inicios de sesión en los servidores lógicos que hospedan las réplicas con nombre.

Como resultado, las réplicas con nombre ofrecen varias ventajas con respecto a las réplicas de alta disponibilidad, en lo que se refiere a las cargas de trabajo de solo lectura:

  • Los usuarios conectados a una réplica con nombre no se desconectan si la réplica principal se escala o reduce verticalmente.
  • Los usuarios conectados a la réplica principal no se ven afectados cuando se escalan o reducen verticalmente las réplicas con nombre.
  • Las cargas de trabajo que se ejecutan en cualquier réplica (principal o con nombre) no se ven afectadas por las consultas de ejecución prolongada que se ejecutan en otras réplicas.

El objetivo principal de las réplicas con nombre es permitir una amplia variedad de escenarios de escalado horizontal de lectura y mejorar las cargas de trabajo de procesamiento transaccional y analítico híbrido (HTAP). Aquí hay ejemplos de cómo crear estas soluciones:

Además, las réplicas con nombre ofrecen flexibilidad y elasticidad para satisfacer también muchos otros casos de uso:

  • Aislamiento del acceso: puede conceder acceso a una réplica con nombre específica, pero no a la réplica principal ni a otras réplicas con nombre.
  • Objetivo de nivel de servicio en función de la carga de trabajo: dado que una réplica con nombre puede tener su propio objetivo de nivel de servicio, es posible usar diferentes réplicas con nombre para diferentes cargas de trabajo y casos de uso. Por ejemplo, una réplica con nombre podría utilizarse para atender solicitudes de Power BI, mientras que otra se puede usar para servir datos a Apache Spark para tareas de ciencia de datos. Cada una puede tener un objetivo de nivel de servicio independiente y escalar de forma independiente.
  • Enrutamiento en función de la carga de trabajo: con hasta 30 réplicas con nombre, es posible usar réplicas con nombre en grupos para que una aplicación pueda aislarse de otra. Por ejemplo, se podría usar un grupo de cuatro réplicas con nombre para atender solicitudes procedentes de aplicaciones móviles, mientras que otro grupo de dos réplicas con nombre se puede usar para atender solicitudes procedentes de una aplicación web. Este enfoque permitiría una optimización detallada del rendimiento y los costos de cada grupo.

Nota:

Para ver las preguntas más frecuentes sobre las réplicas con nombre de Hiperescala, consulte Preguntas frecuentes sobre réplicas con nombre de Hiperescala de Azure SQL Database.

Redundancia de zona para réplicas con nombre de Hiperescala

Las réplicas con nombre de hiperescala configuradas para la redundancia de zona usan Azure Availability Zones para distribuir nodos de proceso de réplicas con nombre en diferentes ubicaciones físicas dentro de una región de Azure. Al elegir la redundancia de zona para las réplicas con nombre, puede mejorar la resistencia de todas las capas de las bases de datos de Hiperescala a una gama más amplia de errores, incluidas las interrupciones de centros de datos, sin modificaciones de la lógica de aplicación. Para obtener más información, consulte Disponibilidad con redundancia de zona de Hiperescala.

Para ver un tutorial sobre cómo crear una réplica con nombre de Hiperescala con redundancia de zona, consulte Creación de una réplica con nombre de Hiperescala.

Para solucionar problemas y probar la resistencia a errores de la aplicación, consulte Prueba de la resistencia a errores de la aplicación.

Replicación geográfica

Con la replicación geográfica activa, puede crear una réplica secundaria de lectura de la base de datos de Hiperescala principal en la misma región de Azure o en otra. Las réplicas geográficas se deben crear en un servidor lógico diferente. El nombre de la base de datos de una réplica geográfica siempre coincide con el nombre de la base de datos de la réplica principal.

Al crear una réplica geográfica, todos los datos se copian de la base de datos principal en un conjunto diferente de servidores de páginas. Una réplica geográfica no comparte servidores de páginas con el principal, aunque estén en la misma región. Esta arquitectura proporciona la redundancia necesaria para las conmutaciones por error geográficas.

Las replicaciones geográficas se usan para mantener una copia transaccionalmente coherente de la base de datos mediante la replicación asincrónica. Si una réplica geográfica se encuentra en una región de Azure diferente, se puede usar para la recuperación ante desastres en caso de un desastre o una interrupción en la región primaria. Las réplicas geográficas también se pueden usar para escenarios de escalado horizontal de lectura geográfica. A partir de octubre de 2022, se admite la copia de base de datos desde una réplica secundaria geográfica de Hiperescala.

La replicación geográfica para la base de datos de Hiperescala tiene las siguientes limitaciones actuales:

  • Solo se puede crear una réplica geográfica (en la misma región o en otra).
  • No se admite la restauración a un momento dado de la réplica geográfica.
  • No se admite la creación de una réplica geográfica de una réplica geográfica (también conocida como "encadenamiento de réplica geográfica").

Solución de problemas

Solución de problemas de réplicas con nombre de Hiperescala con redundancia de zona

  • Para solucionar problemas y probar la resistencia a errores de la aplicación, consulte Prueba de la resistencia a errores de la aplicación.

  • Asegúrese de que se especifique al menos una réplica de alta disponibilidad al crear una réplica con nombre con redundancia de zona en PowerShell y la CLI. Para obtener un ejemplo, consulte Creación de una réplica con nombre de Hiperescala.

    • En la CLI de Azure, debe especificar los parámetros ha-replicas y redundant.
    • En PowerShell, debe especificar el parámetro HighAvailabilityReplicaCount y ZoneRedundant.
    • Si se omiten, recibirá el mensaje de error (ProvisioningDisabled) There is an insufficient number of high availability replicas to enable zone redundancy for a Hyperscale database.

  • La base de datos de Hiperescala debe tener la redundancia de zona ya habilitada como requisito previo para habilitar esta característica para las réplicas con nombre.

    • Es opcional habilitar la redundancia de zona para las réplicas con nombre, incluso si la base de datos principal tiene habilitada la redundancia de zona.
    • Si no se habilita, recibe el mensaje de error (DatabaseNamedReplicaSourceDatabaseNotZoneRedundant) Zone Redundancy cannot be enabled on this Named Replica since the primary Hyperscale Database is not zone redundant.

Problemas conocidos

Datos parcialmente incorrectos devueltos desde sys.databases

Los valores de filas devueltos desde sys.databases para las réplicas con nombre, en las columnas que no sean name y database_id, pueden ser incoherentes e incorrectos. Por ejemplo, la compatibility_level columna de una réplica con nombre podría notificarse como 140 incluso si la base de datos principal correspondiente a la réplica con nombre está establecida en el nivel de compatibilidad 150. Una solución alternativa, cuando sea posible, es obtener los mismos datos mediante la DATABASEPROPERTYEX() función, la cual devolverá los datos correctos.

Contenido relacionado

Para ver tutoriales sobre cómo configurar y administrar réplicas con nombre de Hiperescala, consulte:

Para más información, vea: