Partager via

Utiliser des bases de données d’abonné

  • Article

La fonctionnalité de base de données d’abonné vous permet de joindre 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. Le stockage appartient à la base de données de responsable. 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. Elles doivent être détachées par le responsable ou l’abonné avant de pouvoir être supprimées.

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.

Quelles sont les bases de données suivies ?

  • 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.
  • Les clusters EngineV3 peuvent être uniquement abonnés aux clusters EngineV3, tout comme les clusters EngineV2 qui peuvent être uniquement abonnés aux clusters V2.

Prérequis

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 leader et le cluster follower. 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.

Partage au niveau de la table

Lorsque vous attachez la base de données, toutes les tables, les tables externes et les 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, externalTablesToExcludematerializedViewsToInclude, materializedViewsToExclude, , functionsToIncludeet functionsToExclude. Le nombre maximal d’entrées pour l’ensemble des tableaux est de 100.

Notes

Le partage au niveau de la table n’est pas pris en charge lors de l’utilisation de la notation « * » toutes les bases de données.

Notes

Quand des vues matérialisées sont ajoutées, leurs tables sources sont également incluses.

Exemples

  1. Inclure toutes les tables. Aucun signe « * » n’est nécessaire, car toutes les tables sont suivies par défaut :

    tablesToInclude = []

  2. Incluez toutes les tables dont le nom commence par « Logs » :

    tablesToInclude = ["Logs*"]

  3. Excluez toutes les tables externes :

    externalTablesToExclude = ["*"]

  4. Excluez toutes les vues matérialisées :

    materializedViewsToExclude=["*"]

Remplacement du nom de la base de données

Vous pouvez éventuellement faire en sorte que le nom de la base de données dans le cluster follower diffère du cluster leader. Par exemple, vous souhaiterez peut-être attacher le même nom de base de données de plusieurs clusters de leader à un cluster 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 requis

Exemple en code C#

var tenantId = "xxxxxxxx-xxxxx-xxxx-xxxx-xxxxxxxxx"; //Directory (tenant) ID
var clientId = "xxxxxxxx-xxxxx-xxxx-xxxx-xxxxxxxxx"; //Application ID
var clientSecret = "PlaceholderClientSecret"; //Client Secret
var followerSubscriptionId = "xxxxxxxx-xxxxx-xxxx-xxxx-xxxxxxxxx";
var credentials = await ApplicationTokenProvider.LoginSilentAsync(tenantId, clientId, clientSecret);
var resourceManagementClient = new KustoManagementClient(credentials) { SubscriptionId = followerSubscriptionId };
var followerResourceGroupName = "followerResourceGroup";
var followerClusterName = "follower";
var attachedDatabaseConfigurationName = "attachedDatabaseConfiguration"
var leaderSubscriptionId = "xxxxxxxx-xxxxx-xxxx-xxxx-xxxxxxxxx";
var leaderResourceGroup = "leaderResourceGroup";
var leaderClusterName = "leader";
var attachedDatabaseConfigurationData = new AttachedDatabaseConfiguration
{
    ClusterResourceId = $"/subscriptions/{leaderSubscriptionId}/resourceGroups/{leaderResourceGroup}/providers/Microsoft.Kusto/Clusters/{leaderClusterName}",
    DatabaseName = "<databaseName>", // Can be specific database name or * for all databases
    DefaultPrincipalsModificationKind = "Union",
    Location = "North Central US"
};
// 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 TableLevelSharingProperties(
        tablesToInclude:new List<string> { "table1" },
        tablesToExclude:new List<string> { "table2" },
        externalTablesToInclude:new List<string> { "exTable1" },
        externalTablesToExclude:new List<string> { "exTable2" },
        materializedViewsToInclude:new List<string> { "matTable1" },
        materializedViewsToExclude:new List<string> { "matTable2" }
    );
}
await resourceManagementClient.AttachedDatabaseConfigurations.CreateOrUpdateAsync(
    followerResourceGroupName, followerClusterName, 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

  1. Accédez au cluster d’adeptes et sélectionnez Bases de données.

  2. Dans la liste des bases de données, recherchez de nouvelles bases de données en lecture seule.

    Capture d’écran des bases de données d’suiveur en lecture seule dans le portail.

    Vous pouvez également afficher cette liste dans la page vue d’ensemble de la base de données :

    Capture d’écran de la page de vue d’ensemble des bases de données avec la liste des clusters d’adeptes.

Vérifier votre cluster leader

  1. Accédez au cluster leader et sélectionnez Bases de données

  2. Vérifiez que les bases de données concernées sont marquées comme PARTAGÉES AVEC D’AUTRESOui

  3. Basculez le lien de relation pour afficher les détails.

    Capture d’écran des bases de données partagées avec d’autres personnes pour case activée cluster leader.

    Vous pouvez également l’afficher dans la page vue d’ensemble de la base de données :

    Capture d’écran de la vue d’ensemble avec la liste des bases de données partagées avec d’autres personnes.

Détacher la base de données follower

Notes

Pour détacher une base de données du côté follower ou leader, 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 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 tenantId = "xxxxxxxx-xxxxx-xxxx-xxxx-xxxxxxxxx"; //Directory (tenant) ID
var clientId = "xxxxxxxx-xxxxx-xxxx-xxxx-xxxxxxxxx"; //Application ID
var clientSecret = "PlaceholderClientSecret"; //Client Secret
var followerSubscriptionId = "xxxxxxxx-xxxxx-xxxx-xxxx-xxxxxxxxx";
var credentials = await ApplicationTokenProvider.LoginSilentAsync(tenantId, clientId, clientSecret);
var resourceManagementClient = new KustoManagementClient(credentials) { SubscriptionId = followerSubscriptionId };
var followerResourceGroupName = "testrg";
//The cluster and database attached database configuration are created as part of the prerequisites
var followerClusterName = "follower";
var attachedDatabaseConfigurationsName = "attachedDatabaseConfiguration";
await resourceManagementClient.AttachedDatabaseConfigurations.DeleteAsync(
    followerResourceGroupName, followerClusterName, attachedDatabaseConfigurationsName
);

Détacher la base de données follower attachée du cluster leader en utilisant C#

Le cluster leader peut détacher toute base de données attachée comme suit :

var tenantId = "xxxxxxxx-xxxxx-xxxx-xxxx-xxxxxxxxx"; //Directory (tenant) ID
var clientId = "xxxxxxxx-xxxxx-xxxx-xxxx-xxxxxxxxx"; //Application ID
var clientSecret = "PlaceholderClientSecret"; //Client Secret
var leaderSubscriptionId = "xxxxxxxx-xxxxx-xxxx-xxxx-xxxxxxxxx";
var credentials = await ApplicationTokenProvider.LoginSilentAsync(tenantId, clientId, clientSecret);
var resourceManagementClient = new KustoManagementClient(credentials) { SubscriptionId = leaderSubscriptionId };
var leaderResourceGroupName = "testrg";
var leaderClusterName = "leader";
var followerSubscriptionId = "xxxxxxxx-xxxxx-xxxx-xxxx-xxxxxxxxx";
var followerResourceGroupName = "followerResourceGroup";
//The cluster and attached database configuration that are created as part of the Prerequisites
var followerClusterName = "follower";
var attachedDatabaseConfigurationsName = "attachedDatabaseConfiguration";
var followerDatabaseDefinition = new FollowerDatabaseDefinition
{
    ClusterResourceId = $"/subscriptions/{followerSubscriptionId}/resourceGroups/{followerResourceGroupName}/providers/Microsoft.Kusto/Clusters/{followerClusterName}",
    AttachedDatabaseConfigurationName = attachedDatabaseConfigurationsName
};
await resourceManagementClient.Clusters.DetachFollowerDatabasesAsync(
    leaderResourceGroupName, leaderClusterName, 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

Type 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é.
Replace 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 plus d’informations sur l’utilisation des commandes de contrôle pour configurer les principaux autorisés, consultez Commandes de contrôle pour la gestion du cluster follower.

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. Consultez Gérer les autorisations dans le Portail Azure.

Configurer la stratégie de mise en cache

L’administrateur de base de données follower 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 leader pour exécuter des rapports mensuels et d’une stratégie de mise en cache de trois jours sur la base de données follower pour interroger uniquement les données récentes pour la résolution des problèmes. Pour plus d’informations sur l’utilisation des commandes de contrôle pour configurer la stratégie de mise en cache sur la table ou la base de données follower, consultez Commandes de contrôle pour la gestion du cluster follower.

Notes

  • 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 l’historique et le journal d’activité du cluster et exécutées sur un cluster d’abonné montrent l’activité et l’historique sur le cluster d’abonné et leurs jeux de résultats n’incluent pas les résultats du ou des clusters de responsable.
    • Par exemple : une commande .show queries exécutée sur le cluster d’abonné affiche uniquement les requêtes exécutées sur les bases de données suivies par le cluster d’abonné et non les requêtes exécutées sur la même base de données dans le cluster de responsable.

Limites

  • Les clusters follower et leader 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 chiffrement des données à l’aide de clés gérées par le client n’est pas pris en charge sur les clusters d’abonné ni de responsable.
  • 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.

Étapes suivantes