Mise en miroir de la base de données Azure pour PostgreSQL dans Microsoft Fabric

La mise en miroir dans Fabric (désormais en disponibilité générale) offre une expérience simple pour éviter les opérations ETL complexes (Extraction, Transformation, Chargement) et intégrer votre parc existant de bases de données PostgreSQL sur Azure avec le reste de vos données dans Microsoft Fabric. Vous pouvez répliquer en continu votre base de données Azure existante pour PostgreSQL directement dans Fabric OneLake. Dans Fabric, vous pouvez découvrir des scénarios de décisionnel puissants, d’intelligence artificielle, d’ingénierie des données, de science des données et de partage de données.

Architecture

La mise en miroir de la trame dans Azure Database pour PostgreSQL repose sur des concepts tels que la réplication logique et le modèle de conception de la capture de données modifiées (CDC).

Une fois que vous avez établi la mise en miroir Fabric pour une base de données dans une instance de serveur flexible Azure Database pour PostgreSQL, un processus en arrière-plan PostgreSQL crée un instantané initial pour les tables sélectionnées à mettre en miroir. Il envoie l’instantané à une zone d’atterrissage Fabric OneLake au format Parquet. Un processus de réplication s’exécutant dans Fabric prend ces fichiers d’instantanés initiaux et crée des tables Delta dans l’artefact de base de données mise en miroir.

La base de données source capture les modifications suivantes appliquées aux tables sélectionnées. Il envoie ces modifications à la zone d’atterrissage OneLake par lots à appliquer aux tables Delta respectives de l’artefact de base de données mise en miroir.

Qu’est-ce que la capture de données modifiées (CDC) ?

Capture de données modifiées (CDC) est une méthode qui permet aux applications de détecter et de capturer les modifications apportées à une base de données.

Elle ne s’appuie pas sur des requêtes SQL explicites pour suivre les modifications.

Au lieu de cela, il implique un flux continu d’événements de modification publiés par le serveur de base de données.

Les clients peuvent s’abonner à ce flux pour surveiller les modifications, se concentrer sur des bases de données spécifiques, des tables individuelles ou même des sous-ensembles de colonnes au sein d’une table.

Pour la mise en miroir Fabric, le modèle CDC est implémenté dans une extension PostgreSQL propriétaire appelée azure_cdc. Le plan de contrôle d’une instance de serveur flexible Azure Database pour PostgreSQL est installé et inscrit dans les bases de données sources pendant le flux de travail d’activation de la mise en miroir Fabric.

Extension Azure de capture de données modifiées (CDC)

Azure CDC est une extension pour PostgreSQL qui améliore les fonctionnalités de décodage logique.

Il interprète et transforme les données Write-Ahead Journal (WAL) dans un format logique compréhensible.

L’extension convertit les modifications de base de données en une séquence d’opérations logiques telles que INSERT, UPDATE et DELETE.

Azure CDC est une couche sur le plug-in de décodage logique intégré de PostgreSQL. pgoutput

Azure CDC exporte des instantanés de table et des modifications sous forme de fichiers Parquet qu'il copie ensuite dans une zone d’atterrissage Microsoft Fabric OneLake pour un traitement ultérieur.

Activer la mise en miroir Fabric dans le portail Azure

La mise en miroir de structure dans le portail Azure pour une instance de serveur flexible Azure Database pour PostgreSQL vous permet de répliquer vos bases de données PostgreSQL dans Microsoft Fabric. Cette fonctionnalité vous permet d’intégrer vos données en toute transparence à d’autres services dans Microsoft Fabric, ce qui permet des analyses avancées, l’intelligence décisionnelle et les scénarios de science des données. En suivant quelques étapes simples dans le portail Azure, vous pouvez configurer les prérequis nécessaires et commencer à mettre en miroir vos bases de données pour utiliser le plein potentiel de Microsoft Fabric.

Versions prises en charge

Azure Database pour PostgreSQL prend en charge PostgreSQL 14 et versions ultérieures pour la mise en miroir Fabric.

Prerequisites

Avant de pouvoir utiliser la mise en miroir Fabric dans une instance de serveur flexible Azure Database pour PostgreSQL, vous devez configurer plusieurs prérequis.

• L’identité managée affectée par le système (SAMI) doit être activée.
  • Azure CDC utilise cette identité pour authentifier les communications avec Fabric OneLake, copier les instantanés initiaux et modifier les lots vers la zone d’atterrissage.

Vous configurez des prérequis supplémentaires via un flux de travail d’activation dédié décrit dans la section suivante. Ces conditions préalables sont les suivantes :

• wal_level paramètre de serveur doit être défini sur « logique ».

  • Active la réplication logique pour le serveur source.

• max_worker_processes paramètre de serveur doit être augmenté pour prendre en charge davantage de processus en arrière-plan pour la mise en miroir.

• azure_cdc extension . L’extension Azure CDC (azure_cdc) est préchargée sur le serveur source et inscrite pour que les bases de données sélectionnées soient mises en miroir (il nécessite un redémarrage).

Une nouvelle page est disponible dans le portail Azure pour automatiser ces configurations préalables sur le serveur source.

Sélectionnez Prise en main pour lancer le flux de travail d’activation.

Cette page affiche l’état actuel des prérequis requis. Si l'Identité managée attribuée par le système n’est pas activée pour ce serveur, sélectionnez le lien pour être redirigé vers la page où vous pouvez activer cette fonctionnalité.

Lorsque vous avez terminé, sélectionnez les bases de données pour activer la mise en miroir Fabric (jusqu’à trois par défaut, mais vous pouvez augmenter cette limite en modifiant le paramètre de serveur max_mirrored_databases ), puis sélectionnez Préparer.

Le flux de travail présente une fenêtre contextuelle intitulée "Redémarrer le serveur". En sélectionnant Redémarrer, vous démarrez le processus. Le flux de travail automatise toutes les étapes de configuration restantes. Vous pouvez commencer à créer votre base de données mise en miroir à partir de l’interface utilisateur Fabric.

Créer un rôle de base de données pour la mise en miroir Fabric

Ensuite, vous devez fournir ou créer un rôle PostgreSQL pour que le service Fabric se connecte à votre serveur flexible Azure Database pour PostgreSQL.

Vous pouvez accomplir cette tâche en spécifiant un rôle de base de données pour la connexion à votre système source.

Utiliser un rôle de base de données

1. Connectez-vous à votre base de données Azure pour PostgreSQL à l’aide de Visual Studio Code ou pgAdmin. Connectez-vous à un principal membre du rôle azure_pg_admin.

2. Créez un rôle PostgreSQL nommé fabric_user. Vous pouvez choisir n’importe quel nom pour ce rôle. Fournissez votre propre mot de passe fort. Accordez les autorisations nécessaires pour la mise en miroir Fabric dans la base de données. Exécutez le script SQL suivant pour accorder les autorisations CREATEDB, CREATEROLE, LOGIN, REPLICATION et azure_cdc_admin au nouveau rôle nommé fabric_user.

   -- create a new user to connect from Fabric
   CREATE ROLE fabric_user CREATEDB CREATEROLE LOGIN REPLICATION PASSWORD '<strong password>';
   
   -- grant role for replication management to the new user
   GRANT azure_cdc_admin TO fabric_user;
   -- grant create permission on the database to mirror to the new user
   GRANT CREATE ON DATABASE <database_to_mirror> TO fabric_user;
   

3. L’utilisateur de base de données que vous avez créé doit être également des tables owner à répliquer dans la base de données mise en miroir. Cette exigence signifie que l’utilisateur crée les tables ou modifie la propriété de ces tables à l’aide de ALTER TABLE <table name here> OWNER TO fabric_user;.

   • Lorsque vous basculez la propriété vers un nouvel utilisateur, vous devrez peut-être accorder à cet utilisateur tous les privilèges sur le schéma public avant. Pour plus d’informations sur la gestion des comptes d’utilisateur, consultez la documentation de gestion des utilisateurs Azure Database pour PostgreSQL, la documentation produit PostgreSQL pour les rôles et privilèges de base de données, la syntaxe GRANT et les privilèges.

Paramètres de serveur

Ces paramètres de serveur affectent directement la mise en miroir Fabric pour Azure Database pour PostgreSQL et peuvent être utilisés pour paramétrer le processus de réplication vers Fabric OneLake :

• Azure.fabric_mirror_enabled : la valeur par défaut est désactivée. Ce paramètre spécifie l’indicateur indiquant si la mise en miroir est activée sur le serveur. Il est défini automatiquement à la fin du flux de travail d’activation du serveur. Vous ne devez donc pas le modifier manuellement.

• max_replication_slots : valeur par défaut 10. Nous consommons un emplacement de réplication par base de données mise en miroir, mais les clients peuvent envisager de l’augmenter s’ils créent davantage de miroirs ou ont d’autres emplacements de réplication créés à d’autres fins (réplication logique).

• max_wal_senders : la valeur par défaut est 10. Comme avec le paramètre précédent, nous utilisons un wal processus d’expéditeur par miroir, qui doit être augmenté lors de la mise en miroir d’autres bases de données.

• max_worker_processes : la valeur par défaut est 8. Après l’instantané initial, nous utilisons un processus par base de données mise en miroir ou où la mise en miroir est activée (mais aucun artefact mis en miroir n’a encore été créé dans Fabric). Vous devez augmenter cette valeur si vous avez d’autres extensions ou charges de travail à l’aide de processus de travail supplémentaires.

• max_parallel_workers : la valeur par défaut est 8, ce qui limite le nombre de workers qui peuvent s’exécuter simultanément. Si vous activez plusieurs sessions de mise en miroir sur le même serveur, vous pouvez envisager d’augmenter ce paramètre pour autoriser davantage d’opérations parallèles (par exemple, augmenter le parallélisme dans les instantanés initiaux).

• azure_cdc.max_fabric_mirrors La valeur par défaut est 3. Les clients peuvent augmenter cette valeur s’ils doivent mettre en miroir plus de trois bases de données sur ce serveur. Il est important de tenir compte du fait que chaque nouvelle base de données mise en miroir consomme des ressources serveur (cinq processus en arrière-plan utilisant des ressources processeur et mémoire pour la création et le traitement par lots de modifications d’instantanés). Ainsi, selon la disponibilité de votre serveur, vous devez surveiller l’utilisation des ressources et augmenter la taille de calcul à la taille suivante disponible si l’utilisation du processeur et de la mémoire est constamment supérieure à 80% ou les performances ne sont pas ce que vous attendez.

• azure_cdc.max_snapshot_workers : la valeur par défaut est 3. Nombre maximal de processus de travail utilisés lors de la création initiale d’instantanés. Augmentez cette valeur pour accélérer la création initiale d’instantanés lors de l’augmentation du nombre de bases de données mises en miroir. Toutefois, vous devez prendre en compte tous les autres processus en arrière-plan s’exécutant dans le système avant de le faire.

• azure_cdc.change_batch_buffer_size : la valeur par défaut est de 16 Mo. Taille maximale de la mémoire tampon (en Mo) pour le lot de modifications. Le tableau montre que beaucoup de données sont mises en mémoire tampon jusqu’à ce qu’elles soient écrites sur le disque local. En fonction de la fréquence de modification des données sur vos bases de données mises en miroir, vous pouvez ajuster cette valeur pour réduire la fréquence de traitement des modifications ou l’augmenter si vous souhaitez hiérarchiser le débit global.

• azure_cdc.change_batch_export_timeout : la valeur par défaut est 30. Durée d'inactivité maximale (en secondes) entre les messages par lots de modification. En cas de dépassement, nous marqueons le lot actuel comme étant terminé. En fonction de la fréquence de modification des données sur vos bases de données mises en miroir, vous pouvez ajuster cette valeur pour réduire la fréquence de traitement des modifications ou l’augmenter si vous souhaitez hiérarchiser le débit global.

• azure_cdc.parquet_compression : la valeur par défaut est ZSTD. Ce paramètre est destiné uniquement à une utilisation interne. Vous ne devez donc pas le modifier.

• azure_cdc.snapshot_buffer_size : la valeur par défaut est 1 000. Taille maximale (en Mo) de la mémoire tampon d’instantané initiale. Selon la table, une grande quantité de données est mise en mémoire tampon jusqu'à ce qu'elle soit envoyée à Fabric. N’oubliez pas que azure_cdc.snapshot_buffer_size*azure_cdc.max_snapshot_workers est la mémoire tampon totale utilisée lors de l’instantané initial.

• azure_cdc.snapshot_export_timeout : la valeur par défaut est 180. Durée maximale (en minutes) d’exportation de l’instantané initial. Si la durée maximale est dépassée, elle redémarre.

• azure_cdc.prune_local_batches : la valeur par défaut est True. Si ce paramètre est défini, supprimez les données de lot du disque local une fois qu'elles ont été téléchargées et acclamées par wal_sender.

Monitor

La surveillance de la mise en miroir Fabric dans les instances de serveur flexibles de la base de données Azure pour PostgreSQL est essentielle pour garantir que le processus de mise en miroir fonctionne sans accroc et de manière efficace. En surveillant l’état des bases de données mises en miroir, vous pouvez identifier tous les problèmes potentiels et prendre des mesures correctives.

Vous pouvez utiliser plusieurs fonctions et tables définies par l'utilisateur pour surveiller les métriques importantes de CDC dans les instances de serveur flexible Azure Database pour PostgreSQL et résoudre les problèmes liés au processus de réplication vers Fabric.

Surveillance des fonctions

La fonction de mise en miroir pour la mise en miroir de structure dans Azure Database pour PostgreSQL réplique vos bases de données PostgreSQL en toute transparence dans Microsoft Fabric, ce qui vous permet d’utiliser des scénarios d’intégration avancés d’analytique et de données.

• azure_cdc.list_tracked_publications() : pour chaque publication de l’instance de serveur flexible source, retourne une chaîne séparée par des virgules contenant les informations suivantes

  • publicationName (texte)
  • includeData (bool)
  • includeChanges (bool)
  • actif (bool)
  • baseSnapshotDone (bool)
  • generationId (int)

• azure_cdc.publication_status('pub_name') : pour chaque publication dans la source, l’instance de serveur flexible retourne une chaîne séparée par des virgules avec les informations suivantes

  • <état, start_lsn, stop_lsn, flush_lsn>.
  • L’état se compose de [« Nom du slot », « Nom d’origine », « Chemin de destination des données CDC », « Actif », « Instantané terminé », « Pourcentage de progression », « ID de génération », « ID de lot terminé », « ID de lot chargé », « Chemin de démarrage CDC »]

• azure_cdc.get_all_tables_mirror_status() : retourne l’état de mise en miroir pour toutes les tables éligibles de la base de données. Exclut les schémas système (pg_catalog, information_schema, pg_toast) et les tables appartenant à l’extension.

• Pour qu’une table puisse être mise en miroir, elle doit satisfaire aux conditions suivantes :
  • Les noms de colonnes ne contiennent aucun des caractères suivants : [ ;{}\n\t=()]
  • Les types de colonnes sont l’un des types suivants :
    • bigint
    • bigserial
    • boolean
    • bytes
    • character
    • character varying
    • date
    • double precision
    • integer
    • numeric
    • real
    • serial
    • oid
    • money
    • smallint
    • smallserial
    • text
    • time without time zone
    • time with time zone
    • timestamp without time zone
    • timestamp with time zone
    • uuid
  • La table n’est pas une vue, une vue matérialisée, une table étrangère, une table toast ou une table partitionnée
  • La table a une clé primaire ou un index unique, non nullable et nonpartial. Si ces conditions ne sont pas remplies, la mise en miroir continuera de fonctionner en appliquant replica identity FULL, mais cela aura un impact significatif sur les performances globales de la réplication et sur l'utilisation du WAL. Nous vous recommandons d’avoir une clé primaire ou un index unique pour les tables de taille nontriviale.

Tables de suivi

• azure_cdc.tracked_publications : une ligne pour chaque base de données mise en miroir existante dans Fabric. Interrogez cette table pour comprendre l’état de chaque publication.

• azure_cdc.tracked_batches : une ligne pour chaque lot de modifications capturé et livré à Fabric OneLake. Interrogez cette table pour comprendre quel lot est déjà capturé et chargé dans Fabric OneLake. Avec la last_written_lsn colonne, vous pouvez comprendre si une transaction donnée dans votre base de données source est déjà livrée à Fabric.

• azure_cdc.tracked_tables : une ligne pour chaque table suivie sur toutes les publications. Contient les champs suivants pour toutes les tables publiées, dans toutes les publications. Si une table fait partie de deux publications, elle est répertoriée deux fois.

Contenu connexe

• Identité gérée attribuée par le système
• Règles de pare-feu dans Azure Database pour PostgreSQL
• Vue d’ensemble de la mise en réseau pour les instances Azure Database pour PostgreSQL avec accès public