Partager via

Réplicas secondaires Hyperscale

S’applique à :Azure SQL Database

Comme décrit dans Architecture des fonctions distribuées, Azure SQL Database Hyperscale a deux types différents de nœuds de calcul, également appelés « réplicas » :

Les réplicas secondaires sont toujours en lecture seule et peuvent être de trois types différents :

  • Réplica de haute disponibilité
  • Géoréplica
  • Réplica nommé

Chaque type a une architecture, un ensemble de fonctionnalités, un objectif et des coûts différents. En fonction des fonctionnalités dont vous avez besoin, vous pouvez utiliser un seul type comme l’ensemble des trois types. Vous pouvez utiliser des réplicas secondaires avec des niveaux de calcul serverless ou approvisionnés.

Pour des didacticiels sur la configuration et la gestion des réplicas nommés Hyperscale, consultez :

Réplica de haute disponibilité

Un réplica de haute disponibilité (HA) utilise les mêmes serveurs de pages que le réplica principal. Ainsi, aucune copie de données n’est nécessaire pour ajouter un réplica de haute disponibilité. Les réplicas HA sont utilisés pour augmenter la disponibilité de la base de données. Ils agissent comme des réplicas de secours à des fins de basculement. Si la réplique principale devient indisponible, la bascule vers l’une des répliques de haute disponibilité existantes est automatique et rapide. La chaîne de connexion n’a pas besoin d’être changée ; pendant le basculement, les applications peuvent connaître un temps d’arrêt minimal en raison de la suppression des connexions actives. Comme d’ordinaire dans ce scénario, une logique de nouvelle tentative appropriée est recommandée. Plusieurs pilotes fournissent déjà un certain degré de logique de nouvelle tentative automatique. Si vous utilisez .NET, la dernière bibliothèque Microsoft.Data.SqlClient offre une prise en charge native complète de la logique de nouvelle tentative automatique configurable.

Les réplicas HA utilisent les mêmes noms de serveur et de base de données que le réplica principal. Leur objectif de niveau de service (SLO) est aussi toujours le même que pour le réplica principal. Les réplicas HA ne sont pas visibles ou gérables en tant que ressources autonomes à partir du portail ou d’une API. Ils sont facturés au même tarif de calcul que le réplica principal, mais les coûts de stockage ne s’appliquent pas aux réplicas secondaires.

Il peut y avoir de zéro à quatre réplicas HA. Vous pouvez spécifier le nombre de réplicas lors de la création d’une base de données ou mettre à jour le nombre de réplicas pour une base de données existante. Vous pouvez utiliser les points de terminaison et outils de gestion courants (par exemple, Azure PowerShell, Azure CLI, Portail Azure, API REST) ​​pour spécifier le nombre de réplicas HA. La création ou la suppression de réplicas HA n’affecte pas les connexions actives sur le réplica principal.

Connexion à un réplica HA

Dans les bases de données Hyperscale, l’argument ApplicationIntent de la chaîne de connexion utilisée par le client détermine si la connexion est routée vers le réplica principal en lecture-écriture ou vers un réplica de haute disponibilité (HA) en lecture seule. Si ApplicationIntent est défini sur ReadOnly et que la base de données n’a pas de réplica secondaire, la connexion est acheminée vers le réplica principal et prend par défaut le comportement ReadWrite.

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

Tous les réplicas HA sont identiques dans leur capacité de ressources. Si plusieurs réplicas à haute disponibilité sont présents, la charge de travail d’intention de lecture est distribuée arbitrairement sur tous les réplicas à haute disponibilité disponibles. Quand il existe plusieurs réplicas HA, gardez à l’esprit que chacun d’eux peut avoir une latence de données différente en ce qui concerne les modifications de données effectuées sur le réplica principal. Chaque réplica HA utilise les mêmes données que le réplica principal sur le même ensemble de serveurs de pages. Cependant, les caches de données locaux sur chaque réplica HA reflètent les modifications apportées sur le réplica principal par le biais du service de journal des transactions, qui transfère les enregistrements de journal du réplica principal vers les réplicas HA. Par conséquent, en fonction de la charge de travail exécutée sur le réplica HA, l’application d’enregistrements de journal peut se produire à des vitesses différentes, si bien que différents réplicas peuvent avoir une latence de données différente de celle du réplica principal.

Réplica nommé

Un réplica nommé, tout comme un réplica HA, utilise les mêmes serveurs de pages que le réplica principal. Comme pour les réplicas HA, aucune copie de données n’est nécessaire pour ajouter un réplica nommé.

Il existe des différences entre les répliques HA et les répliques nommées :

  • Les réplicas nommés apparaissent en tant que bases de données Azure SQL standard (en lecture seule) dans le portail et dans les appels d’API (Azure CLI, Azure PowerShell, T-SQL).
  • Les réplicas nommés peuvent avoir un nom de base de données différent du réplica principal et éventuellement être situés sur un autre serveur logique (à condition qu’il se trouve dans la même région que le réplica principal).
  • Les réplicas nommés ont leur propre objectif de niveau de service qui peut être défini et changé indépendamment du réplica principal.
  • Les réplicas nommés prennent en charge un maximum de 30 réplicas nommés (pour chaque réplica principal).
  • Les réplicas nommés prennent en charge des processus d’authentification différents pour chaque réplica nommé en créant des connexions différentes sur les serveurs logiques hébergeant les réplicas nommés.

Par conséquent, les réplicas nommés offrent plusieurs avantages par rapport aux réplicas HA pour ce qui est des charges de travail en lecture seule :

  • Les utilisateurs connectés à un réplica nommé ne sont pas déconnectés si le réplica principal fait l’objet d’un scale-up ou d’un scale-down.
  • Les utilisateurs connectés au réplica principal ne sont pas affectés quand des réplicas nommés font l’objet d’un scale-up ou d’un scale-down.

L’objectif principal des réplicas nommés est de permettre un vaste éventail de scénarios d’échelle horizontale en lecture, et d’améliorer les charges de travail de traitement transactionnel et analytique hybride (HTAP, Hybrid Transactional and Analytical Processing). Des exemples de création de solutions de ce type sont disponibles ici :

De plus, les réplicas nommés offrent flexibilité et élasticité pour répondre également à nombreux autres cas d’utilisation :

  • Isolation d’accès : Vous pouvez accorder l’accès à une réplique nommée spécifique, mais pas à la réplique principale ou à d’autres répliques nommées.
  • Objectif de niveau de service dépendant de la charge de travail : une réplique nommée pouvant avoir son propre objectif de niveau de service, il est possible d’utiliser différentes répliques nommées pour différentes charges de travail et cas d'usage. Par exemple, une réplique nommée peut être utilisée pour répondre à des demandes Power BI, tandis qu’une autre peut être utilisée pour fournir des données à Apache Spark pour des tâches de science des données. Chaque élément peut avoir son propre objectif de niveau de service et évoluer de manière autonome.
  • Routage dépendant de la charge de travail : dans la limite de 30 réplicas nommés, il est possible d’utiliser des réplicas nommés dans des groupes afin qu’une application puisse être isolée d’une autre. Par exemple, un groupe de quatre réplicas nommés peut être utilisé pour traiter les demandes provenant des applications mobiles, tandis qu’un autre groupe de deux réplicas nommés peut être utilisé pour traiter les demandes provenant d’une application web. Cette approche permet un réglage affiné des performances et des coûts pour chaque groupe.

Remarque

Pour obtenir les réponses aux questions fréquemment posées sur les réplicas nommés Hyperscale, consultez Questions fréquentes (FAQ) sur les réplicas nommés Hyperscale Azure SQL Database.

Redondance de zone pour les réplicas nommés Hyperscale

Les réplicas nommés Hyperscale configurés pour la redondance de zone utilisent Zones de disponibilité Azure pour distribuer les nœuds de calcul des réplicas nommés sur différents emplacements physiques au sein d’une région Azure. En choisissant la redondance de zone pour les réplicas nommés, vous pouvez améliorer la résilience de toutes les couches de vos bases de données Hyperscale contre un éventail plus large de défaillances, y compris des interruptions de centre de données, sans aucune modification de la logique d’application. Pour plus d’informations, consultez Disponibilité de la redondance de zone Hyperscale.

Pour consulter un tutoriel sur la création d'un réplica nommé Hyperscale à redondance de zone, consultez Créer un réplica nommé Hyperscale.

Pour résoudre les problèmes et tester la résilience des erreurs de l’application, consultez Tester la résilience des erreurs de l’application.

Géoréplica

Avec la géoréplication active, vous pouvez créer un réplica secondaire accessible en lecture de la base de données Hyperscale primaire dans la même région ou dans une autre région Azure. Les géoréplicas doivent être créés sur un serveur logique différent. Le nom de la base de données d’un géoréplica correspond toujours au nom de la base de données du réplica primaire.

Lorsque vous créez un géoréplica, toutes les données sont copiées du réplica primaire vers un autre ensemble de serveurs de pages. Un géoréplica ne partage pas les serveurs de pages avec le réplica primaire, même s’ils se trouvent dans la même région. Cette architecture fournit la redondance nécessaire pour les basculements géographiques.

La géo-réplica est utilisée pour maintenir une copie transactionnellement cohérente de la base de données via une réplication asynchrone. Si un géoréplica se trouve dans une autre région Azure, il peut être utilisé pour la récupération d’urgence dans l’éventualité d’un sinistre ou d’une panne dans la région primaire. Les géoréplicas peuvent également être utilisés dans le cadre de scénarios de scale-out en lecture. À compter d’octobre 2022, la copie de base de données à partir d’un réplica géo-secondaire Hyperscale est prise en charge.

La géoréplication de base de données Hyperscale présente actuellement les limitations suivantes :

  • Une seule réplique géographique peut être créée (soit dans la même région, soit dans une région différente).
  • La restauration à un instant dans le passé du géoréplica n’est pas prise en charge.
  • La création d’un géoréplica d’un géoréplica (on parle également de « chaînage de géoréplicas ») n’est pas prise en charge.

Résolution des problèmes

Résoudre les problèmes liés aux réplicas nommés Hyperscale à redondance de zone

  • Pour résoudre les problèmes et tester la résilience des erreurs de l’application, consultez Tester la résilience des erreurs de l’application.

  • Vérifiez qu’au moins un réplica HA est spécifié lors de la création d’un réplica nommé à redondance de zone dans PowerShell et l’interface CLI. Pour obtenir un exemple, consultez Créer une réplique nommée Hyperscale.

    • Dans Azure CLI, vous devez spécifier les paramètres ha-replicas et redundant.
    • Dans PowerShell, vous devez spécifier les paramètres HighAvailabilityReplicaCount et ZoneRedundant.
    • Si vous ne le faites pas, vous recevez le message d’erreur : (ProvisioningDisabled) There is an insufficient number of high availability replicas to enable zone redundancy for a Hyperscale database.

  • La base de données Hyperscale doit avoir la redondance de zone déjà activée comme condition préalable à l’activation de cette fonction pour les réplicas nommés.

    • L’activation de la redondance de zone pour les réplicas nommés est facultative, même si la redondance de zone de la base de données primaire est activée.
    • Si elle n’est pas activée, vous recevez le message d’erreur : (DatabaseNamedReplicaSourceDatabaseNotZoneRedundant) Zone Redundancy cannot be enabled on this Named Replica since the primary Hyperscale Database is not zone redundant.

Problèmes connus

Données partiellement incorrectes retournées par sys.databases

Les valeurs de ligne retournées à partir de sys.databases, pour les réplicas nommés, dans des colonnes autres que name et database_id, peuvent être incohérentes et incorrectes. Par exemple, la colonne compatibility_level d’un réplica nommé peut être signalée comme étant égale à 140 même si la base de données primaire correspondant au réplica nommé est définie avec un niveau de compatibilité de 150. Dans la mesure du possible, une solution de contournement consiste à obtenir les mêmes données en utilisant la fonction DATABASEPROPERTYEX(), qui retourne les données correctes.

Contenu connexe

Pour des didacticiels sur la configuration et la gestion des réplicas nommés Hyperscale, consultez :

Pour plus d’informations, consultez l’article suivant :