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. Las réplicas secundarias son compatibles con los niveles de proceso sin servidor y 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 principalmente para aumentar la disponibilidad de la base de datos, ya que 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 también es siempre el mismo que para la réplica principal. Las réplicas de alta disponibilidad no son visibles ni se pueden administrar como un recurso independiente desde el portal ni desde cualquier otra API.

Puede haber de cero a cuatro réplicas de alta disponibilidad. Su número se puede cambiar durante la creación de una base de datos o después de que se haya creado la base de datos, mediante el punto de conexión de administración y las herramientas habituales (por ejemplo: PowerShell, la CLI de Azure, el portal o la API REST). La creación o eliminación de réplicas de alta disponibilidad no afecta a las conexiones activas que se ejecutan 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 está establecido en ReadOnly y la base de datos no tiene una réplica secundaria, la conexión se enrutará a la réplica principal y de forma predeterminada tendrá el comportamiento 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, en función de la carga de trabajo que procese una réplica de alta disponibilidad, la aplicación de las entradas de registro se puede producir a velocidades diferentes y, por tanto, 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:

  • La réplicas con nombre aparecen como bases de datos normales (de solo lectura) de Azure SQL en el portal y en las llamadas de API (AZ CLI, PowerShell y 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 sufrirán ninguna desconexión si la réplica principal se escala o reduce verticalmente; al mismo tiempo, los usuarios conectados a la réplica principal no se verán afectados por el escalado o reducción vertical de las réplicas con nombre.
  • Las cargas de trabajo que se ejecutan en cualquier réplica, principal o con nombre, no se verán afectadas por consultas de larga duración que se ejecuten 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 de los escenarios principales enumerados anteriormente, 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

Nota:

La redundancia de zona para réplicas con nombre de Hiperescala de Azure SQL Database actualmente está en versión preliminar.

La redundancia de zona para réplicas con nombre de Hiperescala de Azure SQL Database usa Azure Availability Zones para distribuir nodos de proceso de réplicas con nombre entre 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 desde la réplica principal a un conjunto diferente de servidores de páginas. Una réplica geográfica no comparte servidores de páginas con el servidor 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 (lo que también se conoce como "encadenamiento de réplicas geográficas").

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 los parámetros 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.

    • La habilitación de la redundancia de zona para las réplicas con nombre es opcional, 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 columna compatibility_level de una réplica con nombre se podría mostrar como 140 aunque la base de datos principal a partir de la que se creó la réplica con nombre esté establecida en 150. Una solución alternativa, siempre que sea posible, es obtener los mismos datos mediante la función DATABASEPROPERTYEX(), que devuelve 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: