Partager via

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. Vous pouvez utiliser des réplicas secondaires avec des niveaux de calcul serverless ou approvisionnés.

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 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 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 (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 de haute disponibilité. 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 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 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=<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é. 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 de haute disponibilité, 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é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 (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 à haute disponibilité, 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.
  • 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 :

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 à 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’utilisation. 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

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 à 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.

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.

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é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 :

  • Un seul géoréplica peut être créé (dans la même région ou dans une autre région).
  • 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é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 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 obtenir des didacticiels sur la configuration et la gestion des réplicas nommés Hyperscale, consultez :

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