Partager via

Réplication d’un serveur flexible Azure Database pour PostgreSQL

La mise en miroir dans Fabric offre une expérience simple pour éviter les opérations ETL complexes (Extraction, Transformation et Chargement) et intégrer votre ensemble de serveurs flexible Azure Database pour PostgreSQL existant avec le reste de vos données dans Microsoft Fabric. Vous pouvez répliquer en continu votre serveur flexible Azure Database pour PostgreSQL existant directement dans OneLake de Fabric. 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.

Pour savoir comment configurer la mise en miroir de votre serveur flexible Azure Database pour PostgreSQL dans Fabric (maintenant disponible de manière générale), consultez Tutoriel : Configuration des bases de données miroirs de Microsoft Fabric à partir d’un serveur flexible Azure Database pour PostgreSQL.

Pourquoi utiliser la mise en miroir dans Fabric ?

Avec la mise en miroir dans Fabric, vous n’avez pas besoin de regrouper différents services de plusieurs fournisseurs. Au lieu de cela, vous pouvez profiter d’un produit hautement intégré, de bout en bout et facile à utiliser qui est conçu pour simplifier vos besoins d’analyse, et conçu pour l’ouverture et la collaboration entre Microsoft, Azure Database pour PostgreSQL flexible et les 1000 solutions technologiques qui peuvent lire le format de table Delta Lake open source.

Quelles expériences d’analytique sont intégrées ?

Les bases de données mises en miroir sont un élément de l’entreposage de données Fabric distinct de l’entrepôt et du point de terminaison d’analytique SQL.

Diagramme de la mise en miroir de bases de données Fabric pour un serveur flexible Azure Database pour PostgreSQL.

La mise en miroir crée ces éléments dans votre espace de travail Fabric :

  • Élément de base de données mis en miroir. La mise en miroir gère la réplication des données dans OneLake et la conversion en Parquet, dans un format prêt pour l'analyse. Cela permet des scénarios en aval tels que l’ingénierie des données, la science des données et bien plus encore.
  • Un point de terminaison d’analyse SQL

Chaque base de données mise en miroir dans un serveur flexible Azure Database pour PostgreSQL dispose d’un point de terminaison d’analytique SQL généré automatiquement qui offre une expérience analytique enrichie sur les tables Delta créées par le processus de mise en miroir. Les utilisateurs ont accès aux commandes T-SQL familières qui peuvent définir et interroger des objets de données, mais qui ne manipulent pas les données à partir du point de terminaison d’analyse SQL, car il s’agit d’une copie en lecture seule. Vous pouvez effectuer les actions suivantes dans le point de terminaison d’analytique SQL :

  • Explorez les tables qui référencent les données de vos tables Delta Lake à partir d’un serveur flexible Azure Database pour PostgreSQL.
  • Créez des requêtes et des vues sans code et explorez les données de manière visuelle sans avoir à programmer.
  • Développez des vues SQL, des fonctions valeurs de table en ligne (TVFs) et des procédures stockées pour encapsuler les sémantiques et la logique métier dans T-SQL.
  • Gérer les autorisations sur les objets.
  • Interroger des données dans d’autres entrepôts et Lakehouses dans le même espace de travail.

En plus de l’éditeur de requête SQL, il existe un vaste écosystème d’outils qui peut interroger le point de terminaison d’analyse SQL, y compris SQL Server Management Studio (SSMS),l’extension mssql avec Visual Studio Code, et même GitHub Copilot.

Configuration réseau requise

Si votre serveur flexible n’est pas accessible publiquement et n’autorise pas les services Azure à se connecter à celui-ci, vous pouvez créer une passerelle de données de réseau virtuel pour mettre en miroir les données. Vérifiez que le réseau virtuel Azure ou le réseau de la machine de passerelle peut se connecter au serveur flexible Azure Database pour PostgreSQL via un point de terminaison privé ou est autorisé par la règle de pare-feu.

Transactions actives, charges de travail et comportements du moteur de réplication

Les transactions actives continuent de retenir la troncation du journal d’écriture anticipée (WAL) jusqu’à ce que la transaction soit validée et que le serveur flexible Azure Database pour PostgreSQL mis en miroir soit synchronisé, ou que la transaction soit abandonnée. Les transactions de longue durée peuvent entraîner un remplissage du WAL plus que d’habitude. Le WAL sur le serveur flexible Azure Database pour PostgreSQL source doit être surveillé pour éviter que le stockage soit saturé. Pour plus d'informations, consultez WAL augmente en raison de transactions de longue durée et de CDC.

Chaque charge de travail utilisateur varie. Lors de l’instantané initial, il peut y avoir davantage d’utilisation des ressources sur la base de données source, pour le processeur et les IOPS (opérations d’entrée/sortie par seconde, pour lire les pages). Les opérations de mise à jour/suppression des tables peuvent entraîner une génération de journaux accrue. Apprenez-en davantage sur la surveillance des ressources pour votre serveur flexible Azure Database pour PostgreSQL.

Prise en charge des niveaux de calcul

Le serveur flexible Azure Database pour PostgreSQL source peut être un niveau de calcul à usage général ou à mémoire optimisée. Le niveau de calcul burstable n’est pas pris en charge comme source pour la mise en miroir.

Pour en savoir plus sur les niveaux de calcul disponibles dans le serveur flexible Azure Database pour PostgreSQL, consultez les options de calcul dans le serveur flexible Azure Database pour PostgreSQL.

Étape suivante

Tutoriel : Configurer des bases de données mises en miroir Microsoft Fabric à partir d’un serveur flexible Azure Database pour PostgreSQL

Contenu connexe

  • Last updated on