Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’applique à :
Azure SQL DatabaseAzure SQL Managed Instance
Dans le cadre d’une architecture haute disponibilité, chaque base de données unique ou chaque base de données du pool élastique des niveaux de service Premium et Critique pour l’entreprise sont automatiquement provisionnées avec un réplica principal en lecture-écriture et un ou plusieurs réplicas secondaires en lecture seule. Les réplicas secondaires sont configurés avec la même capacité de calcul que le réplica principal. La fonctionnalité Échelle horizontale en lecture vous permet de décharger les charges de travail en lecture seule à l'aide de la capacité de calcul de l'un des réplicas en lecture seule au lieu de les exécuter sur le réplica en lecture-écriture. De cette façon, certaines charges de travail en lecture seule peuvent être isolées des charges de travail en lecture-écriture et n’impacteront pas leurs performances. Cette fonctionnalité est destinée aux applications qui incluent des charges de travail en lecture seule séparées logiquement, telles que des analyses. Aux niveaux de service Premium et Critique pour l’entreprise, les applications peuvent bénéficier d’avantages en matière de performances en exploitant cette capacité supplémentaire sans coût supplémentaire.
La fonctionnalité scale-out en lecture est également disponible dans le niveau de service Hyperscale lorsqu’au moins un réplica secondaire est ajouté. Les répliques nommées secondaires Hyperscale offrent une mise à l’échelle indépendante, l’isolation des accès, l’isolation des charges de travail, la prise en charge de divers scénarios de montée en charge en lecture, ainsi que d’autres avantages. Plusieurs réplicas secondaires haute disponibilité (HA) peuvent être utilisés pour équilibrer la charge des charges de travail en lecture seule qui nécessitent plus de ressources que celles disponibles sur un réplica HA secondaire.
L’architecture à haute disponibilité des niveaux de service De base, Standard et Usage général n’inclut pas de réplica. La fonctionnalité de scale-out horizontal en lecture n’est pas disponible dans ces niveaux de service. Toutefois, quand vous utilisez Azure SQL Database, les géoréplicas peuvent fournir des fonctionnalités similaires dans ces niveaux de service. Quand vous utilisez Azure SQL Managed Instance et des groupes de basculement, l’écouteur en lecture seule du groupe de basculement peut fournir des fonctionnalités similaires, respectivement.
Le diagramme suivant illustre la fonctionnalité des bases de données Premium et Critique pour l’entreprise et les instances managées SQL.
La fonctionnalité Échelle horizontale en lecture est activée par défaut sur les nouvelles bases de données Premium, Critique pour l’entreprise et Hyperscale.
Remarque
Le scale-out en lecture est toujours activé dans le niveau de service Business Critical de SQL Managed Instance, ainsi que pour les bases de données Hyperscale disposant d’au moins une réplique secondaire.
Si votre chaîne de connexion SQL est configurée avec ApplicationIntent=ReadOnly, l’application est redirigée vers un réplica en lecture seule de cette base de données ou instance managée. Pour plus d’informations sur la manière d’utiliser la propriété ApplicationIntent, voir Spécification de l’intention de l’application.
Pour Azure SQL Database uniquement, si vous souhaitez vous assurer que l’application se connecte au réplica principal, quelle que soit la valeur de ApplicationIntent dans la chaîne de connexion SQL, vous devez désactiver explicitement le scale-out en lecture lors de la création de la base de données ou de la modification de sa configuration. Par exemple, si vous mettez à niveau votre base de données du niveau Standard ou General Purpose au niveau Premium ou Business Critical et que vous voulez vous assurer que toutes vos connexions continuent d'aller vers le réplica primaire, désactivez le read scale-out. Pour plus d'informations sur la façon de le désactiver, consultez la rubrique Activer et désactiver le transfert en lecture.
Remarque
La fonctionnalité SQL Profiler n’est pas prise en charge sur les réplicas en lecture seule.
Cohérence des données
Les modifications de données apportées au réplica principal sont répercutées sur les réplicas en lecture seule de manière synchrone ou asynchrone, selon le type de réplica. Toutefois, pour tous les types de réplica, les lectures effectuées depuis un réplica en lecture seule sont toujours asynchrones par rapport à l’instance principale. Dans une session connectée à une réplique en lecture seule, les lectures sont toujours cohérentes sur le plan transactionnel. Étant donné que la latence de propagation des données est variable, différents réplicas peuvent renvoyer des données à des instants légèrement différents par rapport au réplica principal et les uns par rapport aux autres. Si un réplica en lecture seule devient indisponible et qu’une session se reconnecte, elle peut se connecter à un réplica à un moment différent de celui du réplica d’origine. De même, si une application modifie des données dans une session en lecture-écriture sur le principal et les lit aussitôt après dans une session en lecture seule sur un réplica en lecture seule, il est possible que les dernières modifications ne soient pas visibles immédiatement.
La latence de propagation des données entre la réplique principale et les répliques en lecture seule varie généralement de quelques dizaines de millisecondes à quelques secondes. Toutefois, il n’existe aucune limite supérieure fixe sur la latence de propagation des données. Des conditions comme l’utilisation élevée des ressources sur le réplica peuvent augmenter considérablement la latence. Les applications qui requièrent la cohérence des données entre les sessions ou requièrent que les données validées soient lisibles immédiatement doivent utiliser le réplica principal.
Remarque
La latence de propagation des données inclut le temps nécessaire pour envoyer et conserver (le cas échéant) les enregistrements de journal sur un réplica secondaire. Cela inclut également le temps nécessaire pour réexécuter (appliquer) ces enregistrements du journal aux pages de données. Pour garantir la cohérence des données, les modifications ne sont pas visibles tant que l’enregistrement du journal de validation de transaction n’a pas été appliqué. Lorsque la charge de travail utilise des transactions plus volumineuses, la latence de propagation des données effective est augmentée.
Pour analyser la latence de propagation des données, consultez Analyse et résolution des problèmes de réplicas en lecture seule.
Se connecter à une réplique en lecture seule
Lorsque vous activez la mise à l’échelle en lecture pour une base de données, l’option ApplicationIntent de la chaîne de connexion fournie par le client détermine si la connexion est dirigée vers le réplica d’écriture ou vers un réplica en lecture seule. Plus précisément, si la valeur ApplicationIntent est ReadWrite (la valeur par défaut), la connexion est dirigée vers la réplique de lecture-écriture. Ce comportement est identique à celui qui se produit lorsque ApplicationIntent n’est pas inclus dans la chaîne de connexion. Si la valeur ApplicationIntent est ReadOnly, la connexion est acheminée vers une réplique en lecture seule.
Par exemple, la chaîne de connexion suivante connecte le client à une réplique en lecture seule (en remplaçant les éléments entre chevrons par les valeurs appropriées à votre environnement et en supprimant les chevrons) :
Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;User ID=<myLogin>;Password=<password>;Trusted_Connection=False; Encrypt=True;
Pour vous connecter à un réplica en lecture seule à l’aide de SQL Server Management Studio (SSMS), sélectionnez Options :
Sélectionnez Paramètres de connexion supplémentaires , puis entrez ApplicationIntent=ReadOnly, puis sélectionnez Se connecter :
L’une ou l’autre des chaînes de connexion suivantes permettent au client de se connecter à une réplique en lecture-écriture (en remplaçant les éléments entre chevrons par les valeurs correctes pour votre environnement et en supprimant les chevrons) :
Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadWrite;User ID=<myLogin>;Password=<password>;Trusted_Connection=False; Encrypt=True;
Server=tcp:<server>.database.windows.net;Database=<mydatabase>;User ID=<myLogin>;Password=<password>;Trusted_Connection=False; Encrypt=True;
Vérifier que la connexion se fait vers un réplica en lecture seule
Vous pouvez vérifier si vous êtes connecté à un réplica en lecture seule en exécutant la requête suivante dans le contexte de votre base de données. Elle renvoie READ_ONLY lorsque vous êtes connecté à une réplique en lecture seule.
SELECT DATABASEPROPERTYEX(DB_NAME(), 'Updateability');
Remarque
Dans les niveaux de service Premium et Critique pour l’entreprise, une seule des répliques en lecture seule est accessible à tout moment. Hyperscale prend en charge plusieurs réplicas en lecture seule.
Analyser et résoudre des problèmes de réplicas en lecture seule
Vous disposez de différentes façons de surveiller les réplicas en lecture seule, notamment les DMV, les événements étendus et l’observateur de base de données (préversion).
Lors d’une connexion à un réplica en lecture seule, les vues de gestion dynamique (DMV) reflètent l’état du réplica et peuvent être interrogées à des fins de suivi et de dépannage. Le moteur de base de données fournit plusieurs affichages pour exposer un large éventail de données de surveillance.
Les vues suivantes sont couramment utilisées pour la surveillance et le dépannage des répliques :
| Nom | Objectif |
|---|---|
| sys.dm_db_resource_stats | Fournit des métriques sur l'utilisation des ressources au cours de la dernière heure, y compris sur le processeur, les E/S de données et l'utilisation des écritures de journal par rapport aux limites d'objectif de service. |
| sys.dm_os_wait_stats | Fournit des statistiques d'attente agrégées pour l'instance du moteur de base de données. |
| sys.dm_database_replica_states | Fournit des statistiques sur l'état de santé et la synchronisation des réplicas. La taille de la file d’attente de redo et le débit de redo sont des indicateurs de la latence de propagation des données sur la réplique en lecture seule. |
| sys.dm_os_performance_counters | Fournit les compteurs de performances du moteur de base de données. |
| sys.dm_exec_query_stats | Fournit des statistiques d'exécution par requête, telles que le nombre d'exécutions, le temps processeur utilisé, etc. |
| sys.dm_exec_query_plan() | Fournit les plans de requête mis en cache. |
| sys.dm_exec_sql_text() | Fournit un texte de requête pour un plan de requête mis en cache. |
| sys.dm_exec_query_profiles | Fournit la progression des requêtes en temps réel pendant leur exécution. |
| sys.dm_exec_query_plan_stats() | Fournit le dernier plan d'exécution réel connu, y compris les statistiques d'exécution relatives à une requête. |
| sys.dm_io_virtual_file_stats() | Fournit des statistiques de stockage IOPS, de débit et de latence pour tous les fichiers de base de données. |
Remarque
Les DMV sys.resource_stats et sys.elastic_pool_resource_stats de la base de données logique master renvoient des données sur l’utilisation des ressources du réplica principal.
Surveiller les réplicas en lecture seule avec Extended Events
Il n’est pas possible de créer une session d’événements étendus lorsqu’on est connecté à un réplica en lecture seule. Toutefois, dans Azure SQL Database et Azure SQL Managed Instance, les définitions des sessions Extended Event au niveau de la base de données, créées et modifiées sur le réplica principal, sont répliquées vers les réplicas en lecture seule, y compris les géo-réplicas, et capturent des événements sur ces réplicas en lecture seule.
Dans Azure SQL Database, une session d’événements étendus sur un réplica en lecture seule basé sur une définition de session du réplica principal peut être démarrée et arrêtée indépendamment de la session sur le réplica principal.
Dans Azure SQL Managed Instance, pour démarrer une trace sur un réplica en lecture seule, vous devez d’abord démarrer la trace sur le réplica principal avant de pouvoir démarrer la trace sur le réplica en lecture seule. Si vous ne commencez pas d’abord par démarrer la trace sur le réplica principal, le message d’erreur suivant s’affiche lorsque vous essayez de démarrer la trace sur le réplica en lecture seule :
Msg 3906, Niveau 16, État 2, Ligne 1 Échec de la mise à jour de la base de données « master », car la base de données est en lecture seule.
Après avoir démarré la trace d’abord sur la réplica principale, puis sur la réplica en lecture seule, vous pouvez arrêter la trace sur la réplica principale.
Pour supprimer une session d'événements sur un réplica en lecture seule, procédez comme suit :
- Connecter l’Explorateur d’objets de SSMS ou une fenêtre de requête au réplica en lecture seule.
- Arrêtez la session sur le réplica en lecture seule, soit en sélectionnant Arrêter la session dans le menu local de la session dans l'Explorateur d'objets, soit en exécutant
ALTER EVENT SESSION [session-name-here] ON DATABASE STATE = STOP;dans une fenêtre Requête. - Connectez-vous au réplica principal à l’aide de l’Explorateur d’objets ou d’une fenêtre de requête.
- Supprimez la session sur le réplica principal, soit en sélectionnant Supprimer dans le menu local de la session, soit en exécutant
DROP EVENT SESSION [session-name-here] ON DATABASE;.
Niveau d'isolement des transactions sur les réplicas en lecture seule
Les transactions sur les réplicas en lecture seule utilisent toujours le niveau d’isolation des transactions d’instantané, quel que soit le niveau d’isolation des transactions de la session, et indépendamment des indicateurs de requête. L’isolation des instantanés utilise la gestion de versions de lignes pour éviter les situations de blocage dans lesquelles les lecteurs bloquent les rédacteurs.
Dans de rares cas, si une transaction d'isolation par instantané accède aux métadonnées d'objet qui ont été modifiées dans une autre transaction simultanée, elle peut rencontrer l'erreur 3961, la transaction d'isolation par instantané a échoué dans la base de données « nom-base de données », car l'objet accessible par l'instruction a été modifié par une instruction DDL dans une autre transaction simultanée depuis le début de cette transaction. Elle n'est pas autorisée, car les métadonnées ne possèdent pas de versionnement. Une mise à jour simultanée des métadonnées peut entraîner des incohérences si elles sont combinées à une isolation par instantané.
Requêtes de longue durée sur les réplicas en lecture seule
Les requêtes exécutées sur des répliques en lecture seule doivent accéder aux métadonnées des objets référencés dans la requête (tables, index, statistiques, etc.) Dans de rares cas, si les métadonnées d'un objet sont modifiées sur la réplique primaire alors qu'une requête détient un verrou sur le même objet sur la réplique en lecture seule, la requête peut bloquer le processus qui applique les modifications de la réplique primaire à la réplique en lecture seule. Traduit avec www.DeepL.com/Translator (version gratuite) Si une telle requête devait s’exécuter pendant une longue période, la réplique en lecture seule se retrouverait fortement désynchronisée par rapport à la réplique principale. Pour les répliques qui sont des cibles potentielles de basculement (répliques secondaires dans les niveaux de service Premium et Business Critical, répliques Hyperscale HA et toutes les répliques géographiques), cela retarderait également la récupération de la base de données si un basculement devait se produire, ce qui entraînerait des temps d'arrêt plus longs que prévu.
Si une requête longue sur un réplica en lecture seule provoque directement ou indirectement ce type de blocage, elle peut être automatiquement arrêtée pour éviter une latence excessive des données et un impact potentiel sur la disponibilité de la base de données. La session reçoit l’erreur 1219, votre session a été déconnectée en raison d’une opération DDL de priorité élevée ou de l’erreur 3947, la transaction a été abandonnée, car le calcul secondaire n’a pas pu rattraper le rétablissement. Réessayez la transaction.
Étant donné que les transactions sur les réplicas en lecture seule utilisent toujours le niveau d’isolation des transactions d’instantané, une requête longue sur un réplica en lecture seule peut bloquer le nettoyage du magasin de versions fantôme ou du magasin de versions persistantes (PVS) sur le réplica principal s’il lit des lignes récemment supprimées ou des versions de lignes antérieures. Un retard dans le nettoyage des fantômes ou le nettoyage du système PVS peut avoir un impact sur les charges de travail du réplique principal. Pour plus d’informations sur la résolution des problèmes de retards de nettoyage PVS, consultez Surveiller et résoudre les problèmes de récupération accélérée de la base de données.
À l’inverse, si une requête longue sur un réplica en lecture seule lit des lignes récemment supprimées ou des versions de lignes antérieures, et que ces lignes ou versions peuvent ne plus être disponibles sur la réplique principale (par exemple, en raison d’une opération de mise à l’échelle), la requête est arrêtée avec l’erreur 3948, la transaction a été arrêtée en raison du changement de configuration/d’état de la réplique de disponibilité ou parce que les enregistrements fantômes sont supprimés sur la réplique principale et la réplique de disponibilité secondaire qui peuvent être requis par les requêtes s’exécutant sous isolation d’instantané. Réessayez la transaction.
Remarque
Si vous recevez l’erreur 3961, 1219, 3947 ou 3948 lors de l’exécution de requêtes sur un réplica en lecture seule, réessayez la requête. Vous pouvez également éviter les opérations qui modifient les métadonnées d’objet (modifications de schéma, maintenance d’index, mises à jour des statistiques, etc.) sur le réplica principal, ou l'extension de celui-ci pendant que les requêtes de longue durée s’exécutent sur des réplicas secondaires.
Conseil
Dans les niveaux de service Premium et Critique pour l’entreprise, lorsqu’ils sont connectés à un réplica en lecture seule, les colonnes redo_queue_size et redo_rate du DMV sys.dm_database_replica_states peuvent être utilisées pour surveiller le processus de synchronisation des données, servant d’indicateurs de latence de propagation des données sur le réplica en lecture seule.
Activer et désactiver l’échelle horizontale en lecture pour SQL Database
Pour SQL Managed Instance, le scale-out horizontal en lecture est automatiquement activé sur le niveau de service Critique pour l’entreprise, mais il n’est pas disponible dans le niveau de service Usage général. Il n’est pas possible de désactiver puis de réactiver le scale-out en lecture.
Pour SQL Database, la montée en charge en lecture est activée par défaut sur les niveaux de service Premium, Business Critical et Hyperscale. Le scale-out en lecture ne peut pas être activé dans les niveaux de service Basique, Standard ou Usage général. La montée en charge en lecture est automatiquement désactivée pour les bases de données Hyperscale configurées avec zéro réplique secondaire.
Pour les bases de données uniques et mises en pool dans Azure SQL Database, vous pouvez désactiver et réactiver la montée en charge en lecture dans les niveaux de service Premium ou Business Critical à l’aide du portail Azure et d’Azure PowerShell. Ces options ne sont pas disponibles pour SQL Managed Instance, car le scale-out horizontal en lecture ne peut pas être désactivé.
Remarque
Pour les bases de données individuelles et les bases de données dans des pools élastiques, la possibilité de désactiver la montée en charge en lecture est proposée pour assurer la compatibilité descendante. Le scale-out en lecture ne peut pas être désactivé sur les instances gérées Business Critical.
Portail Azure
Pour Azure SQL Database, vous pouvez gérer le paramètre de scale-out en lecture dans le volet Calcul + stockage de la base de données, disponible sous Paramètres. L’activation ou la désactivation du scale-out en lecture à l’aide du portail Azure n’est pas disponible pour Azure SQL Managed Instance.
PowerShell
Importante
Le module PowerShell Azure Resource Manager est toujours pris en charge, mais tous les développements à venir sont destinés au module Az.Sql. Le module PowerShell Azure Resource Manager (AzureRM) ne reçoit plus de correctifs de bogues. Les arguments des commandes dans le module Az sont sensiblement identiques à ceux des modules Azure Resource Manager. Pour plus d’informations sur leur compatibilité, consultez Présentation du nouveau module Az Azure PowerShell.
La gestion du scale-out en lecture dans Azure PowerShell nécessite la version Azure PowerShell de décembre 2016 ou une version plus récente. Pour obtenir la version de PowerShell la plus récente, consultez Azure PowerShell.
Dans Azure SQL Database, vous pouvez activer ou désactiver l’échelle horizontale en lecture dans Azure PowerShell en appelant l’applet de commande Set-AzSqlDatabase et en transmettant la valeur souhaitée (Enabled ou Disabled) pour le paramètre -ReadScale. La désactivation du scale-out horizontal en lecture pour SQL Managed Instance n’est pas possible.
Pour désactiver la mise à l’échelle en lecture pour une base de données existante (en remplaçant les éléments entre crochets angulaires par les valeurs appropriées à votre environnement, puis en supprimant les crochets angulaires) :
Set-AzSqlDatabase -ResourceGroupName <resourceGroupName> -ServerName <serverName> -DatabaseName <databaseName> -ReadScale Disabled
Pour désactiver le scale-out en lecture sur une nouvelle base de données (en remplaçant les éléments entre chevrons par les valeurs correctes pour votre environnement et en supprimant les chevrons) :
New-AzSqlDatabase -ResourceGroupName <resourceGroupName> -ServerName <serverName> -DatabaseName <databaseName> -ReadScale Disabled -Edition Premium
Pour réactiver le scale-out en lecture sur une base de données existante (en remplaçant les éléments entre chevrons par les valeurs correctes pour votre environnement et en supprimant les chevrons) :
Set-AzSqlDatabase -ResourceGroupName <resourceGroupName> -ServerName <serverName> -DatabaseName <databaseName> -ReadScale Enabled
API REST
Pour créer une base de données avec échelle horizontale en lecture désactivée, ou pour modifier le paramétrage d’une base de données existante, utilisez la méthode suivante avec la propriété readScale définie sur Enabled ou Disabled, comme dans l’exemple de requête suivant.
Method: PUT
URL: https://management.azure.com/subscriptions/{SubscriptionId}/resourceGroups/{GroupName}/providers/Microsoft.Sql/servers/{ServerName}/databases/{DatabaseName}?api-version= 2014-04-01-preview
Body: {
"properties": {
"readScale":"Disabled"
}
}
Pour plus d’informations, consultez Bases de données - Créer ou mettre à jour.
Utilisez la base de données tempdb sur une réplica en lecture seule
La base de données tempdb du réplica principal n’est pas répliquée sur les réplicas en lecture seule. Chaque réplica possède sa propre base de données tempdb générée lors de la création du réplica. Il vérifie que la base de données tempdb peut être mise à jour et modifiée pendant l'exécution de votre requête. Si votre charge de travail en lecture seule dépend de l'utilisation d'tempdbobjets, vous devez créer ces objets dans le cadre de la même charge de travail, tout en étant connecté à une réplique en lecture seule.
Utiliser la mise à l’échelle en lecture avec des bases de données géo-répliquées
Les bases de données secondaires géo-répliquées ont la même architecture de haute disponibilité que les bases de données primaires. Si vous vous connectez à la base de données secondaire géorépliquée avec la mise à l’échelle en lecture activée, vos sessions avec ApplicationIntent=ReadOnly sont routées vers l’un des réplicas de haute disponibilité, de la même manière qu’elles le sont sur la base de données primaire accessible en écriture. Les sessions sans ApplicationIntent=ReadOnly sont routées vers le réplica principal de la base de données secondaire géorépliquée, qui est également en lecture seule.
De cette façon, la création d'une géo-réplique peut fournir plusieurs répliques supplémentaires en lecture seule pour une base de données primaire en lecture-écriture. Chaque géo-réplique supplémentaire ajoute un nouvel ensemble de répliques en lecture seule. Des géo-réplicas peuvent être créés dans n'importe quelle région Azure, y compris dans la région de la base de données primaire.
Remarque
Il n'y a pas de round-robin automatique ou tout autre routage équilibré en fonction de la charge entre les répliques d'une base de données secondaire géo-répliquée, à l'exception d'une géo-réplique Hyperscale avec plus d'une réplique HA. Dans ce cas, les sessions avec une intention de lecture seule sont distribuées sur toutes les répliques HA d'une géo-réplique.
Prise en charge des fonctionnalités sur les répliques en lecture seule
Le Magasin des requêtes sur les réplicas secondaires est supporté dans Azure SQL Database et Azure SQL Managed Instance. Pour plus d’informations, consultez Magasin des requêtes pour des réplicas secondaires lisibles.
L’audit est activé automatiquement sur les réplicas en lecture seule. Pour plus d’informations sur la hiérarchie des dossiers de stockage, des conventions d’affectation de noms et du format de journal, consultez le format du journal d’audit SQL Database.
Query Performance Insight pour Azure SQL Database s’appuie sur les données du Magasin des requêtes. Query Performance Insights
does notprend actuellement en charge lereplica_group_idconcept associé au Magasin des requêtes pour la fonctionnalité secondaire lisible . Les données affichées dans le tableau de bord Query Performance Insights agrègent toutes les données de statistiques d’exécution et d’attente de tous les réplicas.Le composant Correction de plan automatique de la fonctionnalité de réglage automatique est pris en charge sur les réplicas en lecture seule. Chaque base de données doit être activée pour prendre en charge la correction automatique du plan. Pour plus d’informations, consultez la correction automatique des plans pour les répliques secondaires.
Les paramètres de diagnostic dans Azure Monitor prennent en charge la diffusion en continu des statistiques d’exécution du Magasin des requêtes via les paramètres de diagnostic Azure. Deux colonnes sont incluses pour aider à identifier la source de réplique des données de télémétrie :
-
is_primary_b: valeur booléenne indiquant si les données proviennent du réplica principal (true) ou d’un réplica secondaire (false) -
replica_group_id: Un entier qui correspond au rôle de réplique
Ces colonnes sont essentielles pour désambiguer les métriques et les données de performances lors de l'analyse des charges de travail au sein des ensembles de réplicas. Lors de la configuration des paramètres de diagnostic pour diffuser en continu des statistiques d’exécution du Magasin des requêtes vers Log Analytics, Event Hubs ou un Stockage Azure, assurez-vous que vos requêtes et tableaux de bord prennent en compte ces colonnes afin de segmenter correctement les données par rôle de réplica.
-