Résoudre les problèmes liés aux bases de données mises en miroir Fabric à partir d’un serveur flexible Azure Database pour PostgreSQL

Cet article décrit les étapes de résolution des problèmes de mise en miroir d’un serveur flexible Azure Database pour PostgreSQL.

Résoudre les erreurs / messages d’avertissement lors de la sélection de la table pour la mise en miroir

Lorsque vous créez une base de données mise en miroir, dans la page Choisir des données , vous pouvez recevoir des commentaires visuels concernant des tables spécifiques dans la base de données source. Le tableau suivant fournit une liste des problèmes potentiels, y compris le message affiché et la description associée sur la façon de résoudre le problème.

¹ Identificateurs d’objet avec un caractère d’espace (' ') ne sont pas pris en charge.

² Ce type de tableau n’est pas pris en charge pour la mise en miroir. Actuellement, les vues, les vues matérialisées, les tables étrangères et les tables partitionnées ne sont pas prises en charge. Les hypertables TimescaleDB ne sont également pas prises en charge pour le mirroring Fabric.

³ Pour obtenir la liste des types de données non pris en charge, consultez Limitations. Seules les colonnes avec les types suivants sont prises en charge :

• bigint
• bigserial
• boolean
• bytea
• character
• character varying
• date
• double precision
• integer
• numeric
• real
• serial
• oid
• money
• smallint
• smallserial
• text
• time without time zone
• time with time zone (* pas comme clé primaire)
• timestamp without time zone
• timestamp with time zone
• uuid
• xml
• json
• jsonb
• inet
• cidr
• macaddr
• macaddr8
• tsvector
• tsquery
• int4range
• int8range
• numrange
• tsrange
• tstzrange
• daterange
• circle
• line
• lseg
• box
• path
• point
• polygon
• interval

Dans Postgres, deux valeurs « heure avec fuseau horaire » qui correspondent exactement au même moment, mais dans des fuseaux horaires différents, sont considérées comme distinctes. Par exemple : 06:24:00.59+05 et 05:24:00.59+04 correspondent au même temps d’époque, mais Postgres les traite différemment.

Les colonnes numériques non contraintes par défaut dans les schémas de base de données source (sans précision et échelle définies) sont converties en Decimal128(38, 0) avant d’être répliquées dans des tables OneLake, en alignant avec la convention standard SQL dont l’échelle non spécifiée signifie une précision entière.

Opérations de langage de définition de données (DDL) prises en charge sur la base de données source

• Rename column : une colonne portant le nouveau nom est ajoutée à la table mise en miroir dans Fabric et contient des données pour les lignes nouvellement insérées (pour les lignes existantes sera NULL). L'ancienne colonne est toujours conservée avec des valeurs pour les lignes existantes (les nouvelles lignes ont des valeurs NULL).
• Ajouter une colonne : la colonne ajoutée est visible dans la table mise en miroir et contient des données pour les lignes nouvellement insérées (pour les lignes existantes sont NULL).
• Supprimer la colonne : la colonne supprimée reste visible dans la table mise en miroir et contient des données pour les lignes existantes (pour les nouvelles lignes sont NULL).
• Modifier la clé primaire : la session de mise en miroir continue régulièrement.

Toute autre opération DDL sur les tables sources n’est actuellement pas prise en charge et peut entraîner des échecs de réplication.

Modifications de la capacité de Fabric ou de l’espace de travail

Requêtes SQL pour la résolution des problèmes

Si vous rencontrez des problèmes de mise en miroir, connectez-vous au serveur Azure Database pour PostgreSQL source et effectuez ces vérifications à l'aide des vues système et des fonctions pour valider la configuration.

1. Exécutez la requête suivante pour vérifier si toutes les conditions préalables sont remplies avant de démarrer la mise en miroir CDC. Cette fonction vérifie les différentes exigences de système et de configuration pour vous assurer que le serveur est prêt pour les opérations de capture de données modifiées.

-- Check if all prerequisites are met
SELECT * FROM azure_cdc.check_prerequisites();

-- Example output when all checks pass (on mock mode with identity configured):
 status |                                                               data
--------+----------------------------------------------------------------------------------------------------------------------------------
 ERROR  | [{"status": "ERROR", "details": {"current_value": "12", "required_value": "13"}, "status_code": "MAX_WORKER_PROCESSES_TOO_LOW"}]

-- Example output on standby replica:
 status |                                               data
--------+---------------------------------------------------------------------------------------------------
 ERROR  | [{"status": "ERROR", "status_code": "SERVER_IN_RECOVERY"}]

-- Example output when identity not configured:
 status |                                data
--------+---------------------------------------------------------------------
 ERROR  | [{"status": "ERROR", "status_code": "IDENTITY_NOT_CONFIGURED"}]

Retour:(status text, data jsonb)

• status: État global : OK si toutes les vérifications passent, ERROR si une vérification échoue
• data: tableau JSONB contenant des entrées d’état détaillées avec status, status_codeet facultatif details

Codes d’état :

2. Exécutez la requête suivante pour vérifier si les tables de votre base de données source sont éligibles à la réplication. Exclut les schémas système (pg_catalog, information_schema, pg_toast) et les tables appartenant à l’extension.

SELECT * FROM azure_cdc.get_all_tables_mirror_status();
 table_schema | table_name | mirroring_status |                      mirroring_data
--------------+------------+------------------+------------------------------------------------------
 public       | customers  | OK               | [{"status": "OK", "status_code": "HAS_PRIMARY_KEY"}]
 public       | orders     | OK               | [{"status": "OK", "status_code": "HAS_UNIQUE_INDEX"}]
 public       | logs       | WARNING          | [{"status": "WARNING", "status_code": "NO_INDEX_FULL_IDENTITY"}]

Renvoie: Ensemble de (table_schema text, table_name text, mirroring_status text, mirroring_data jsonb)

• table_schema: Nom du schéma de la table
• table_name: Nom de la table
• mirroring_status: État global - OK, WARNINGou ERROR
• mirroring_data: tableau JSONB contenant des entrées d’état détaillées avec status, status_codeet facultatif details

Codes d’état :

3. Exécutez la requête suivante pour retourner des erreurs et des problèmes détectés pendant les opérations de réplication, notamment les erreurs à l’échelle du système, les erreurs spécifiques à la publication et les erreurs par table.

-- Get only system-wide errors
SELECT * FROM azure_cdc.get_health_status('', '');

-- Get system-wide errors and publication-specific errors
SELECT * FROM azure_cdc.get_health_status('my_database', 'my_publication');

Paramètres :

• db_name (texte) : Nom de la base de données
• pub_name (texte) : Nom de la publication

Comportement:

• Lorsqu’elle est appelée avec des chaînes vides pour les deux paramètres (azure_cdc.get_health_status('', '')) : renvoie uniquement les erreurs à l’échelle du système (type d’erreur « S »).
• Lorsqu’elle est appelée avec des noms de base de données et de publication valides : retourne les erreurs à l’échelle du système et les erreurs spécifiques à la table/publication pour la publication spécifiée.

Renvoie: Ensemble de (error_time timestamptz, schema_name text, table_name text, error_type char(1), error_code text, params jsonb)

Types d’erreurs :

Codes d’erreur :

4. Exécutez la requête suivante pour vérifier si la publication est créée correctement et que la réplication change correctement le flux :

   select * from azure_cdc.tracked_publications;
   

   Vérifiez si la publication est active et que l’instantané a été généré. Vous pouvez également vérifier si les lots de modifications suivants ont été générés en interrogeant :

   select * from azure_cdc.tracked_batches;
   

5. Si la azure_cdc.tracked_publications vue n’affiche aucune progression lors du traitement des modifications incrémentielles, exécutez la requête SQL suivante pour vérifier s’il existe des problèmes signalés :

   SELECT * FROM pg_stat_activity WHERE state = 'idle in transaction';
   

6. Si aucun problème n’est signalé, exécutez la commande suivante pour passer en revue la configuration actuelle de la base de données PostgreSQL mise en miroir. Confirmez qu'il a bien été activé.

   SELECT * FROM pg_replication_slots;
   

   Les colonnes clés à rechercher ici sont les slot_name et active. Toute valeur en plus t (true) indique un problème potentiel.

7. Contactez le support si un dépannage est nécessaire.

Identité managée

L'identité managée affectée par le système (SAMI) du serveur flexible Azure Database pour PostgreSQL doit être activée en tant qu'identité principale. Pour plus d’informations, consultez l’identité managée affectée par le système pour le serveur flexible PostgreSQL.

Après l’activation, si l’état du paramètre SAMI est désactivé ultérieurement, puis réactivé, la mise en miroir du serveur flexible Azure Database pour PostgreSQL vers Fabric OneLake échoue.

Vérifiez que le SAMI est activé avec la requête suivante : show azure.service_principal_id;

Autorisations SAMI

Ne supprimez pas les autorisations de contributeur SAMI (System Assigned Managed Identity) du serveur flexible Azure Database pour PostgreSQL sur l’élément de base de données mis en miroir Fabric.

Si vous supprimez accidentellement les autorisations SAMI, la mise en miroir d’un serveur flexible Azure Database pour PostgreSQL ne fonctionne pas comme prévu. Aucune nouvelle donnée ne peut être mise en miroir à partir de la base de données source.

Si vous supprimez les autorisations SAMI du serveur flexible Azure Database pour PostgreSQL ou que les autorisations ne sont pas configurées correctement, procédez comme suit.

1. Ajoutez le serveur flexible SAMI en tant qu'utilisateur en sélectionnant l’option ... d’ellipse sur l’élément de base de données miroir.
2. Sélectionnez l’option Gérer les autorisations .
3. Entrez le nom du serveur flexible Azure Database pour PostgreSQL. Fournissez des autorisations de lecture et d’écriture .

Contenu connexe

• Limitations de Microsoft Fabric Data Warehouse
• Questions fréquemment posées sur la réplication de serveurs flexibles dans Azure Database pour PostgreSQL au sein de Microsoft Fabric