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.
La fonctionnalité de base de données d’abonné vous permet d’attacher une base de données située dans un cluster différent à votre cluster Azure Data Explorer. La base de données d’abonné est jointe en mode lecture seule, ce qui permet d’afficher les données et d’exécuter des requêtes sur les données ingérées dans la base de données du responsable. La base de données d’abonné synchronise les modifications apportées aux bases de données de responsable. En raison de la synchronisation, il existe un décalage de données de quelques secondes à quelques minutes au niveau de la disponibilité des données. La durée du décalage dépend de la taille globale des métadonnées de la base de données du responsable. Les bases de données de responsable et d’abonné utilisent le même compte de stockage pour extraire les données. La base de données leader possède le stockage. La base de données d’abonné affiche les données sans qu’il soit nécessaire de les ingérer. Étant donné que la base de données jointe est une base de données en lecture seule, les données, les tables et les stratégies de la base de données ne peuvent pas être modifiées, à l’exception de la stratégie de mise en cache, des principaux et des autorisations. Les bases de données jointes ne peuvent pas être supprimées. Le responsable ou le suiveur doit détacher les bases de données avant la suppression.
L’attachement d’une base de données à un autre cluster à l’aide de la fonctionnalité de l’abonné est utilisé en tant qu’infrastructure pour partager des données entre les organisations et les équipes. La fonctionnalité est utile pour séparer les ressources de calcul afin de protéger un environnement de production contre les cas d’utilisation hors production. L’abonné peut également être utilisé pour associer le coût du cluster Azure Data Explorer au tiers qui exécute des requêtes sur les données.
Remarque
Pour obtenir des exemples de code fondés sur les versions précédentes du kit de développement logiciel (SDK), consultez l’article archivé.
Quelles sont les bases de données suivies ?
Les éléments suivants s’appliquent aux clusters :
- Un cluster peut suivre une base de données, plusieurs bases de données ou toutes les bases de données d’un cluster de responsable.
- Un cluster unique peut suivre des bases de données à partir de plusieurs clusters de responsable.
- Un cluster peut contenir à la fois des bases de données d’abonné et des bases de données de responsable.
Prérequis
- Un abonnement Azure. Créez un compte Azure gratuit.
- Un cluster et une base de données Azure Data Explorer pour le leader et l’abonné. Créez un cluster et une base de données.
- La base de données du leader doit contenir des données. Vous pouvez ingérer des données en tirant parti de l’une des méthodes présentées dans Vue d’ensemble de l’ingestion.
Attacher une base de données
Vous pouvez utiliser différentes méthodes pour joindre une base de données. Dans cet article, nous traitons de l’attachement d’une base de données en utilisant C#, Python, PowerShell ou un modèle Azure Resource Manager. Pour attacher une base de données, vous devez disposer d’un utilisateur, d’un groupe, d’un principal du service ou d’une identité managée avec au moins le rôle de contributeur sur le cluster du responsable et le cluster de l’abonné. Ajoutez ou supprimez des attributions de rôles avec le portail Azure, PowerShell, Azure CLI et un modèle ARM. Apprenez-en davantage sur le contrôle d’accès en fonction du rôle Azure (RBAC Azure) et les différents rôles.
Remarque
La création préalable d’une base de données d’abonné n’est pas nécessaire, car il en est créé une pendant le processus d’attachement.
Partage au niveau de la table
Lorsque vous attachez des bases de données, toutes les tables, tables externes et vues matérialisées sont également suivies. Vous pouvez partager des tables/tables externes/vues matérialisées spécifiques en configurant « TableLevelSharingProperties ».
« TableLevelSharingProperties » contient huit tableaux de chaînes : tablesToInclude, tablesToExclude, externalTablesToInclude, externalTablesToExclude, materializedViewsToInclude, materializedViewsToExclude, functionsToInclude et functionsToExclude. Le nombre maximal d’entrées pour l’ensemble des tableaux est de 100.
Remarque
- Le partage au niveau de la table n'est pas pris en charge lorsque l'on utilise la notation « * » pour toutes les bases de données.
- Quand des vues matérialisées sont ajoutées, leurs tables sources sont également incluses.
Exemples
L’exemple suivant comprend toutes les tables. Par défaut, toutes les tables sont suivies sans utiliser la notation « * » :
tablesToInclude = []
L’exemple suivant comprend toutes les fonctions. Par défaut, toutes les fonctions sont suivies sans utiliser la notation « * » :
functionsToInclude = []
L’exemple suivant inclut toutes les tables ayant un nom commençant par « Journaux » :
tablesToInclude = ["Logs*"]
L’exemple suivant comprend toutes les tables externes :
externalTablesToExclude = ["*"]
L’exemple suivant comprend toutes les vues matérialisées :
materializedViewsToExclude=["*"]
Remplacement du nom de base de données
Vous pouvez éventuellement différencier le nom de base de données dans le cluster d’abonné par rapport à celui du cluster du leader. Par exemple, vous pouvez attacher le même nom de base de données de plusieurs clusters de leader au cluster d’abonné. Pour spécifier un autre nom de base de données, configurez la propriété « DatabaseNameOverride » ou « DatabaseNamePrefix ».
Attacher une base de données avec C#
Packages NuGet exigés
- Installez Azure.ResourceManager.Kusto.
- Installez Azure.Identity pour l’authentification.
Exemple C#
var followerClusterId = KustoClusterResource.CreateResourceIdentifier(subscriptionId: "xxxxxxxx-xxxxx-xxxx-xxxx-xxxxxxxxx", resourceGroupName: "followerResourceGroup", clusterName: "follower");
var leaderClusterId = KustoClusterResource.CreateResourceIdentifier(subscriptionId: "xxxxxxxx-xxxxx-xxxx-xxxx-xxxxxxxxx", resourceGroupName: "leaderResourceGroup", clusterName: "leader");
var attachedDatabaseConfigurationName = "attachedDatabaseConfiguration";
var credentials = new ManagedIdentityCredential();
var resourceManagementClient = new ArmClient(credentials);
var followerCluster = resourceManagementClient.GetKustoClusterResource(followerClusterId);
var attachedDatabaseConfigurations = followerCluster.GetKustoAttachedDatabaseConfigurations();
var attachedDatabaseConfigurationData = new KustoAttachedDatabaseConfigurationData
{
ClusterResourceId = leaderClusterId,
DatabaseName = "<databaseName>", // Can be a specific database name in a leader cluster or * for all databases
DefaultPrincipalsModificationKind = KustoDatabaseDefaultPrincipalsModificationKind.Union,
Location = AzureLocation.NorthCentralUS
};
// Table level sharing properties are not supported when using '*' all databases notation.
if (attachedDatabaseConfigurationData.DatabaseName != "*")
{
// Set up the table level sharing properties - the following is just an example.
attachedDatabaseConfigurationData.TableLevelSharingProperties = new KustoDatabaseTableLevelSharingProperties();
attachedDatabaseConfigurationData.TableLevelSharingProperties.TablesToInclude.Add("table1");
attachedDatabaseConfigurationData.TableLevelSharingProperties.TablesToExclude.Add("table2");
attachedDatabaseConfigurationData.TableLevelSharingProperties.ExternalTablesToExclude.Add("exTable1");
attachedDatabaseConfigurationData.TableLevelSharingProperties.ExternalTablesToInclude.Add("exTable2");
attachedDatabaseConfigurationData.TableLevelSharingProperties.MaterializedViewsToInclude.Add("matTable1");
attachedDatabaseConfigurationData.TableLevelSharingProperties.MaterializedViewsToExclude.Add("matTable2");
attachedDatabaseConfigurationData.TableLevelSharingProperties.FunctionsToInclude.Add("func1");
attachedDatabaseConfigurationData.TableLevelSharingProperties.FunctionsToExclude.Add("func2");
}
await attachedDatabaseConfigurations.CreateOrUpdateAsync(WaitUntil.Completed, attachedDatabaseConfigurationName, attachedDatabaseConfigurationData);
Vérifiez que la base de données a bien été attachée.
Pour vérifier que la base de données a été attachée avec succès, recherchez vos bases de données attachées dans le Portail Azure. Vous pouvez vérifier que les bases de données ont été correctement attachées dans les clusters « follower » ou « leader ».
Vérifier votre cluster follower
Parcourez le cluster de l’abonné et sélectionnez Bases de données.
Dans la liste de bases de données, recherchez les nouvelles bases de données en lecture seule.
Vous pouvez également afficher cette liste sur la page de vue d’ensemble de la base de données :
Vérifier votre cluster leader
Parcourez le cluster du leader et sélectionnez Bases de données
Vérifiez que les bases de données concernées sont marquées comme PARTAGÉES AVEC D’AUTRES>Oui
Activez/désactivez le lien de relation pour afficher les détails.
Vous pouvez également les afficher sur la page de vue d’ensemble de la base de données :
Détacher la base de données follower
Remarque
Pour détacher une base de données du côté suiveur ou leader, vous devez disposer d’un utilisateur, d’un groupe, d’un principal de service ou d’une identité managée avec au moins un rôle contributeur sur le cluster à partir duquel vous détachez la base de données. Dans l’exemple ci-dessous, nous utilisons le principal du service.
Détacher la base de données follower attachée du cluster follower en utilisant C#**
Le cluster follower peut détacher n’importe quelle base de données attachée comme suit :
var attachedDatabaseConfigurationId = KustoAttachedDatabaseConfigurationResource.CreateResourceIdentifier(
subscriptionId: "xxxxxxxx-xxxxx-xxxx-xxxx-xxxxxxxxx", resourceGroupName: "testrg", clusterName: "follower",
attachedDatabaseConfigurationName: "attachedDatabaseConfiguration");
var credentials = new ManagedIdentityCredential();
var resourceManagementClient = new ArmClient(credentials);
var attachedDatabaseConfiguration = resourceManagementClient.GetKustoAttachedDatabaseConfigurationResource(attachedDatabaseConfigurationId);
await attachedDatabaseConfiguration.DeleteAsync(WaitUntil.Completed);
Détacher la base de données follower attachée du cluster leader en utilisant C#
Le cluster du responsable peut détacher toute base de données attachée comme suit :
var leaderClusterId = KustoClusterResource.CreateResourceIdentifier(subscriptionId: "xxxxxxxx-xxxxx-xxxx-xxxx-xxxxxxxxx", resourceGroupName: "testrg", clusterName: "leader");
var followerClusterId = KustoClusterResource.CreateResourceIdentifier(subscriptionId: "xxxxxxxx-xxxxx-xxxx-xxxx-xxxxxxxxx", resourceGroupName: "followerResourceGroup", clusterName: "follower");
var followerDatabaseDefinition = new KustoFollowerDatabaseDefinition(
clusterResourceId: followerClusterId,
attachedDatabaseConfigurationName: "attachedDatabaseConfiguration"
);
var credentials = new ManagedIdentityCredential();
var resourceManagementClient = new ArmClient(credentials);
var leaderCluster = resourceManagementClient.GetKustoClusterResource(leaderClusterId);
await leaderCluster.DetachFollowerDatabasesAsync(WaitUntil.Completed, followerDatabaseDefinition);
Gérer les principaux, les autorisations et la stratégie de mise en cache
Gérer les principaux
Lors de l’attachement d’une base de données, spécifiez le « type de modification des principaux par défaut ». La valeur par défaut consiste à combiner le remplacement des principaux autorisés avec la collection de bases de données leader des principaux autorisés
| Genre | Description |
|---|---|
| Union | Les principaux de la base de données attachée incluent toujours les principaux de la base de données d’origine ainsi que d’autres nouveaux principaux ajoutés à la base de données d’abonné. |
| Remplacer | Aucun héritage des principaux de la base de données d’origine. De nouveaux principaux doivent être créés pour la base de données attachée. |
| Aucun | Les principaux de la base de données attachée incluent uniquement les principaux de la base de données d’origine sans aucun autre principal. |
Pour découvrir plus d’informations sur l’utilisation des commandes de gestion pour configurer les principaux autorisés, consultez Commandes de gestion pour la gestion du cluster de l’abonné.
Gérer les autorisations
La gestion de l’autorisation de base de données en lecture seule est identique à celle de tous les types de bases de données. Pour attribuer des autorisations, consultez Gérer les autorisations de base de données dans le Portail Azure ou utilisez les commandes de gestion pour Gérer les rôles de sécurité de la base de données.
Configurer la stratégie de mise en cache
L’administrateur de base de données d’abonné peut modifier la stratégie de mise en cache de la base de données attachée ou de l’une de ses tables sur le cluster hôte. La valeur par défaut consiste à combiner les stratégies de base de données source dans la base de données du cluster leader et de mise en cache au niveau de la table avec les stratégies de remplacement définies dans la base de données et les stratégies au niveau de la table. Vous pouvez, par exemple, disposer d’une stratégie de mise en cache de 30 jours sur la base de données du responsable pour exécuter des rapports mensuels et d’une stratégie de mise en cache de trois jours sur la base de données de l’abonné pour interroger uniquement les données récentes pour la résolution des problèmes. Pour découvrir plus d’informations sur l’utilisation des commandes de gestion pour configurer la stratégie de mise en cache sur la table ou la base de données de l’abonné, consultez Commandes de gestion pour la gestion du cluster de l’abonné.
Remarques
Passez en revue les notes suivantes :
- En cas de conflits entre les bases de données de clusters de responsable/d’abonné, lorsque toutes les bases de données sont suivies par le cluster d’abonné, elles sont résolues comme suit :
- Une base de données nommée DB créée sur le cluster d’abonné est prioritaire sur une base de données portant le même nom et créée sur le cluster de responsable. C’est pourquoi la base de données DB dans le cluster d’abonné doit être supprimée ou renommée pour que le cluster d’abonné inclue la base de données DB du responsable.
- Une base de données nommée DB suivie à partir d’au moins deux clusters de responsable est choisie arbitrairement à partir d’un des clusters de responsable et n’est pas suivie plusieurs fois.
- Les commandes permettant d’afficher le journal d’activité du cluster et l’historique s’exécutent sur un cluster de suivi affichent l’activité et l’historique sur le cluster de suivi, et leurs jeux de résultats n’incluent pas ces résultats du cluster ou des clusters leader.
- Par exemple : une
.show queriescommande exécutée sur le cluster de suivi affiche uniquement les requêtes exécutées sur les bases de données suivies d’un cluster de suivi, et non sur la même base de données dans le cluster leader.
- Par exemple : une
Limites
Passez en revue les limitations suivantes :
- Les clusters de l’abonné et du responsable doivent se trouver dans la région.
- Si l’ingestion de streaming est utilisée sur une base de données à suivre, le cluster follower doit être activé pour l’ingestion de streaming pour permettre le suivi des données d’ingestion de streaming.
- Le suivi d’un cluster avec un chiffrement de données en utilisant des clés gérées par le client (CMK) est pris en charge avec les limites suivantes :
- Le cluster de suivi ou le cluster leader ne suit pas d’autres clusters.
- Si un cluster d’abonné suivant un cluster de leader avec une CMK activée et que l’accès du leader à la clé est révoqué, les clusters de leader et d’abonné sont suspendus. Dans cette situation, vous pouvez résoudre le problème de CMK et redémarrer le cluster d’abonné ou vous pouvez détacher les bases de données d’abonné du cluster d’abonné et redémarrer indépendamment du cluster de leader.
- Vous ne pouvez pas supprimer une base de données attachée à un autre cluster avant de la détacher.
- Vous ne pouvez pas supprimer un cluster qui dispose d’une base de données attachée à un autre cluster avant de la détacher.
- Les propriétés de partage au niveau de la table ne sont pas prises en charge quand vous suivez toutes les bases de données.
- Dans les bases de données d’abonné, une identité managée doit être ajoutée au cluster d’abonné pour interroger des tables externes qui utilisent une identité managée comme méthode d’authentification. Cette fonctionnalité ne fonctionne pas quand les clusters leader et abonné sont approvisionnés dans différents tenants.