Partager via

Limitations dans les bases de données mises en miroir Microsoft Fabric à partir d’un serveur flexible Azure Database pour PostgreSQL

Les limitations actuelles dans les bases de données mises en miroir Microsoft Fabric à partir d’un serveur flexible Azure Database pour PostgreSQL sont répertoriées dans cette page. Cette page est susceptible d’être modifiée.

Pour résoudre les problèmes, voir :

Limitations au niveau du serveur

  • La mise en miroir dans Fabric est prise en charge pour PostgreSQL versions 14, 15, 16 et 17.
  • Les serveurs du niveau de calcul burstable ne sont pas pris en charge.
  • La mise en miroir dans Fabric ne peut pas être configurée sur un serveur de réplica en lecture ou sur un serveur principal sur lequel un réplica en lecture existe.
  • Le basculement transparent pour les serveurs compatibles haute disponibilité est pris en charge uniquement pour PostgreSQL version 17 et ultérieure. Pour les versions précédentes, la session de mise en miroir doit être rétablie manuellement après un basculement.
  • La récupération d’un serveur avec la mise en miroir activée dans Fabric via la restauration à un point dans le temps (PITR) nécessite de reconfigurer la mise en miroir sur le nouveau serveur.
  • Avant d’exécuter une mise à niveau de version majeure (MVU), désactivez la mise en miroir dans Fabric et réactivez une fois la mise à niveau terminée.

Limitations au niveau de la base de données

  • Le serveur flexible Fabric Mirroring pour Azure Database pour PostgreSQL est pris en charge uniquement sur une base de données primaire accessible en écriture.
  • Une base de données serveur flexible Azure Database pour PostgreSQL ne peut être mise en miroir qu’à un seul élément Fabric à la fois.
  • Le nombre maximal de tables pouvant être mises en miroir dans Fabric est de 500 tables. Aucune table au-dessus de la limite de 500 ne peut actuellement être répliquée.
    • Si vous sélectionnez Mettre en miroir toutes les données lors de la configuration de la mise en miroir, les tables à mettre en miroir sont les 500 premières tables lorsque toutes les tables sont triées par ordre alphabétique en fonction du nom du schéma, puis du nom de la table. Les tables restantes au bas de la liste alphabétique ne sont pas mises en miroir.
    • Si vous désélectionnez mettre en miroir toutes les données et sélectionnez des tables individuelles, vous ne pouvez pas sélectionner plus de 500 tables.

Autorisations dans la base de données source

  • Les autorisations définies dans le serveur flexible Azure Database pour PostgreSQL ne sont pas propagées aux données répliquées dans Fabric OneLake.
  • Pour configurer la mise en miroir pour le serveur flexible Azure Database pour PostgreSQL, le rôle de base de données utilisé pour se connecter au serveur source doit disposer des autorisations nécessaires pour la mise en miroir fabric dans la base de données. Vous devez accorder les autorisations CREATEDB, CREATEROLE, LOGIN, REPLICATION et azure_cdc_admin à un nouveau rôle ou à un rôle existant. Pour obtenir un exemple de script, consultez Tutoriel : Configurer des bases de données mises en miroir Microsoft Fabric à partir d’Azure Database pour PostgreSQL.
  • Le rôle de base de données utilisé doit également être owner des tables de la base de données source. Cela signifie que les tables ont été créées par cet utilisateur ou que la propriété de ces tables a été modifiée à l’aide ALTER TABLE xxx OWNER TO <user>;de . Lorsque vous basculez la propriété vers un nouvel utilisateur, vous devrez peut-être accorder à cet utilisateur tous les privilèges sur public le schéma 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.

Sécurité des réseaux et de la connectivité

  • 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.
  • L’identité managée affectée par le système (SAMI) du serveur flexible Azure Database pour PostgreSQL doit être activée et doit être l’identité principale.

Niveau de table

  • Les opérations DDL sur les tables mises en miroir existantes ne sont pas prises en charge (ajouter/supprimer une colonne, modifier le type de données, etc.). La modification des tables existantes nécessite l’arrêt et le redémarrage de la réplication à partir de la base de données mise en miroir dans Microsoft Fabric.
  • TRUNCATE TABLE les commandes sur les tables mises en miroir ne sont pas prises en charge
  • La mise en miroir n’est actuellement pas prise en charge pour les vues, les vues matérialisées, les tables étrangères, les tables toast ou les tables partitionnées.
  • Les hypertables TimescaleDB ne sont pas prises en charge pour le Fabric Mirroring.

Au niveau des colonnes

  • Les données d’une colonnedécimale numérique/ dépassant la précision de 38 ne seront pas répliquées dans la base de données mise en miroir et apparaîtront comme NULL.

  • Si la table source contient des colonnes avec l’un de ces types de données, ces colonnes ne peuvent pas être mises en miroir dans Fabric OneLake. Les types de données suivants ne sont actuellement pas pris en charge pour la mise en miroir :

    • bit
    • bit varying [ (n) ], varbit
    • box
    • cidr
    • circle
    • inet
    • interval [ fields ] [ (p) ]
    • json
    • jsonb
    • line
    • lseg
    • macaddr
    • macaddr8
    • path
    • pg_lsn
    • pg_snapshot
    • point
    • polygon
    • tsquery
    • tsvector
    • txid_snapshot
    • xml

  • La mise en miroir prend en charge la réplication de colonnes contenant des espaces ou des caractères spéciaux dans des noms (tels que ,;{}()\n\t=). Pour les tables sous réplication avant que cette fonctionnalité soit activée, vous devez mettre à jour les paramètres de base de données mis en miroir ou redémarrer la mise en miroir pour inclure ces colonnes. En savoir plus sur la Prise en charge du mappage de colonnes Delta.

Limitations de l’entrepôt

  • La hiérarchie de schéma source est répliquée dans la base de données mise en miroir. Pour les bases de données mises en miroir créées avant l’activation de cette fonctionnalité, le schéma source est aplatit et le nom du schéma est encodé dans le nom de la table. Si vous souhaitez réorganiser des tables avec des schémas, recréez votre base de données mise en miroir. En savoir plus sur la hiérarchie de schémas source de réplication.

Limitations des éléments en miroir

  • L’utilisateur doit être membre du rôle Administrateur/Membre de l’espace de travail pour créer une mise en miroir de bases de données PostgreSQL. 
  • L’arrêt de la mise en miroir désactive complètement la mise en miroir. 
  • Le démarrage de la mise en miroir réalimente toutes les tables, ce qui revient à repartir de zéro. 

Limitations du point de terminaison analytique SQL

Régions prises en charge

La mise en miroir de bases de données et la mise en miroir ouverte sont disponibles dans toutes les régions Microsoft Fabric. Pour plus d'informations, voir Disponibilité des régions Fabric.

É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