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.
Important
Cette fonctionnalité est en version préliminaire.
La mise en miroir dans Fabric offre une expérience simple afin d'éviter des opérations ETL complexes (Extraction, Transformation et Chargement) et d'intégrer votre infrastructure existante de base de données MySQL 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 MySQL directement dans OneLake de Fabric, que vos serveurs soient accessibles publiquement, isolés via des réseaux virtuels ou des points de terminaison privés, ou configurés pour la haute disponibilité. Dans Fabric, vous pouvez découvrir des scénarios puissants d'intelligence d'affaires, d’intelligence artificielle, d’ingénierie des données, de science des données et de partage de données.
Pour obtenir un didacticiel sur la configuration de votre mise en miroir Azure Database pour MySQL dans Fabric, consultez Tutoriel : Créer une base de données mise en miroir à partir d’Azure Database pour MySQL dans Microsoft Fabric (préversion).
Pourquoi utiliser la mise en miroir dans Fabric ?
En utilisant la mise en miroir dans Fabric, vous n’avez pas besoin de regrouper différents services de plusieurs fournisseurs. Au lieu de cela, utilisez un produit hautement intégré, de bout en bout et facile à utiliser qui simplifie vos besoins d’analyse. Il est conçu pour l’ouverture et la collaboration entre Microsoft, Azure Database pour MySQL et les milliers de 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.
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. Ce processus permet des scénarios en aval tels que l’ingénierie des données, la science des données et bien plus encore.
- Un Serveur d'analyse SQL
Chaque base de données mise en miroir dans Azure Database pour MySQL a 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 à des commandes T-SQL familières qui peuvent définir et interroger des objets de données, mais qui ne peuvent pas manipuler 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 des données dans vos tables Delta Lake à partir d’Azure Database pour MySQL.
- 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 à valeur de table en ligne (TVF) et des procédures stockées pour encapsuler votre sémantique et votre logique métier dans T-SQL.
- Gérer les autorisations sur les objets.
- Interroger des données dans des entrepôts et des Lakehouses différents 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.
Les bases de données mises en miroir offrent également une intégration en un clic à Microsoft Power BI dans Fabric, ce qui permet de créer rapidement des rapports directement à partir des données mises en miroir ou du point de terminaison d’analyse SQL.
Configuration réseau requise
La mise en miroir prend en charge les serveurs accessibles publiquement et les configurations isolées du réseau, y compris les serveurs hébergés dans des réseaux virtuels. Si votre serveur n’est pas accessible publiquement et n’autorise pas l’accès public à celui-ci, vous pouvez créer une passerelle de données de réseau virtuel ou configurer une passerelle de données locale 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 à Azure Database pour MySQL et est autorisé par la règle de pare-feu.
Transactions actives, charges de travail et comportements du moteur de réplication
Les transactions actives ou longues peuvent retarder la purge du journal binaire (binlog) jusqu’à ce que la transaction soit validée et que tout processus de réplication ou de migration en aval rattrape son retard. Ce délai peut entraîner une croissance inattendue du stockage binlog, de sorte que surveiller l’utilisation du stockage sur le serveur source pour éviter l’épuisement de l’espace.
Pendant la charge initiale d’instantané ou de données, une utilisation plus élevée du processeur et des E/S par seconde est normale, car les données sont lues et copiées. Les charges de travail avec des opérations UPDATE ou DELETE fréquentes peuvent générer une activité de restauration et de journal binaire supplémentaire, ce qui augmente davantage la consommation d’E/S et de stockage.
Surveillez le stockage, les IOPS et les transactions de longue durée pour garantir une capacité suffisante tout au long du processus.
Prise en charge des niveaux de calcul
La base de données Azure source pour MySQL peut utiliser 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 de mise en miroir.
Pour plus d’informations sur les niveaux de calcul disponibles dans Azure Database pour MySQL, consultez les niveaux de service.