Réplicas secondaires Hyperscale

  • Article

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éo-ré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. Les réplicas secondaires sont pris en charge par les niveaux de calcul serverless et provisionné.

Pour obtenir 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 principalement utilisés pour augmenter la disponibilité de la base de données. Ils agissent comme réplicas de serveur de secours à des fins de basculement. Si le réplica principal devient indisponible, le basculement vers l’un des réplicas de haute disponibilité existants 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 de haute disponibilité utilisent les mêmes noms de serveur et de base de données que le réplica principal. Leur objectif de niveau de service est aussi toujours le même que pour le réplica principal. Les réplicas de haute disponibilité ne peuvent pas être vus ou gérés en tant que ressources autonomes à partir du portail ou de n’importe quelle API.

Il peut y avoir de zéro à quatre réplicas de haute disponibilité. Leur nombre peut être changé lors de la création d’une base de données ou après la création de celle-ci, par le biais des outils et du point de terminaison de gestion communs (par exemple : PowerShell, AZ CLI, portail, API REST). La création ou la suppression de réplicas de haute disponibilité n’affecte pas les connexions actives sur le réplica principal.

Connexion à un réplica de haute disponibilité

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 écriture-lecture ou vers un réplica de haute disponibilité en lecture seule. Si l’option ApplicationIntent est définie sur ReadOnly et que la base de données ne dispose pas de réplica secondaire, la connexion est routée vers le réplica principal et le comportement adopté par défaut est 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;

Tous les réplicas à haute disponibilité 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 de haute disponibilité, 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 de haute disponibilité 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 de haute disponibilité 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 de haute disponibilité. En conséquence, en fonction de la charge de travail traitée par un réplica de haute disponibilité, 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 par rapport au réplica principal.

Réplica nommé

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

Il existe des différences entre les réplicas de haute disponibilité et les réplicas nommés :

  • 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 (AZ CLI, 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 à haute disponibilité, pour ce qui est des charges de travail en lecture seule :

  • Les utilisateurs connectés à un réplica nommé ne subissent aucune déconnexion si le réplica principal fait l’objet d’un scale-up ou d’un scale-down. De même, les utilisateurs connectés au réplica principal ne sont pas affectés par le scale-up ou le scale-down des réplicas nommés.
  • Les charges de travail exécutées sur un réplica, principal ou nommé, ne sont pas affectées par les requêtes longues exécutées sur d’autres réplicas.

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 :

Les réplicas nommés offrent flexibilité et élasticité pour répondre à de nombreux autres cas d’usage, en plus des principaux scénarios listés ci-dessus :

  • Isolation d’accès : Vous pouvez accorder l’accès à un réplica nommé spécifique, mais pas au réplica principal ou d’autres réplicas nommés.
  • Objectif de niveau de service dépendant de la charge de travail : un réplica nommé pouvant avoir son propre objectif de niveau de service, il est possible d’utiliser différents réplicas nommés pour différentes charges de travail et cas d’usage. Par exemple, un réplica nommé peut être utilisé pour traiter des demandes Power BI, tandis qu’un autre peut être utilisé pour fournir des données à Apache Spark dans le cadre de tâches de science des données. Chacun d’eux peut avoir un objectif de niveau de service indépendant et être mis à l’échelle indépendamment.
  • 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

Remarque

La redondance de zone pour les réplicas nommés Azure SQL Database Hyperscale est actuellement en préversion.

La redondance de zone pour les réplicas nommés Azure SQL Database Hyperscale utilise les zones de disponibilité Azure pour distribuer des nœuds de calcul de réplicas nommés entre 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 à un large éventail d’échecs, y compris les pannes de centre de données, sans aucune modification de la logique d’application. Pour plus d'informations, consultez Disponibilité redondante interzone Hyperscale.

Pour obtenir un didacticiel sur la création d’un réplica nommé Hyperscale redondant interzone, 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éo-ré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.

Lors de la création d’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.

Les géo-réplicas sont utilisés pour maintenir une copie transactionnelle de la base de données via une réplication asynchrone. Si un géo-réplica se trouve dans une autre région Azure, il peut être utilisé pour la récupération d’urgence en cas de sinistre ou de 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 :

  • Un seul géoréplica peut être créé (dans la même région ou dans une autre région).
  • La limite de restauration dans le temps du géoréplica n’est pas prise en charge.
  • La création d’un réplica géographique pour un réplica géographique (également appelée « 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ées Hyperscale redondants interzone

  • 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 à haute disponibilité est spécifié lors de la création d’un réplica nommé redondant interzone, dans PowerShell et l’interface CLI. Pour obtenir un exemple, consultez Créer un réplica nommé Hyperscale.

    • Dans Azure CLI, vous devez spécifier les paramètres « ha-replicas » et « redundant ».
    • Dans PowerShell, vous devez spécifier le paramètre « 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.

    • Il est facultatif d’activer la redondance de zone pour les réplicas nommés, 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 ayant pour valeur 140 même si la base de données primaire à partir de laquelle le réplica nommé a été créé est définie sur 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 obtenir des didacticiels sur la configuration et la gestion des réplicas nommés Hyperscale, consultez :

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