Diffuser des données depuis des bases de données PostgreSQL

Cette section contient des informations sur les éléments suivants :

  • Le comportement de Datastream lors de la gestion des données extraites d'une base de données PostgreSQL source
  • Les versions de la base de données PostgreSQL compatibles avec Datastream
  • Présentation de la configuration d'une base de données PostgreSQL source afin que les données puissent être diffusées en streaming vers une destination
  • Les limites connues d'utilisation de la base de données PostgreSQL en tant que source

Comportement

La base de données PostgreSQL source s'appuie sur sa fonctionnalité de décodage logique. Le décodage logique expose toutes les modifications validées à la base de données, et permet la consommation et le traitement de ces modifications dans un format convivial à l'aide d'un plug-in de sortie. Datastream utilise le plug-in pgoutput, qui est le plug-in de décodage logique PostgreSQL standard pour PostgreSQL 10 et versions ultérieures.

  • Vous pouvez sélectionner tous les schémas ou des schémas spécifiques d'une source PostgreSQL donnée, ainsi que toutes les tables du schéma ou des tables spécifiques.
  • Toutes les données historiques sont répliquées.
  • Toutes les modifications du langage de manipulation de données (LMD), telles que les insertions, les mises à jour et les suppressions des bases de données et des tables spécifiées, sont répliquées.
  • Seules les modifications validées sont répliquées.
  • Si vous définissez une IDENTITÉ DE RÉPLIQUE sur une table, Datastream traite les colonnes spécifiées comme des clés primaires.
  • Datastream envoie régulièrement des messages de pulsation à la base de données source lorsqu'il est connecté à une instance principale. Par conséquent, les événements de message de décodage logique (op:"m") sont insérés directement dans le fichier WAL. Datastream a besoin de ces messages pour garantir la disponibilité de la source et calculer la fraîcheur. Lorsque vous utilisez une instance répliquée avec accès en lecture comme source, vous devez configurer les messages de pulsation en externe. Pour en savoir plus, consultez la section Réplication à partir d'instances répliquées avec accès en lecture. Nous vous recommandons d'en tenir compte si d'autres configurations de réplication lisent les données de la même base de données source.

Versions

Datastream est compatible avec PostgreSQL 10 et versions ultérieures.

Datastream est compatible avec les types de base de données PostgreSQL suivants :

  • PostgreSQL auto-hébergé
  • Cloud SQL pour PostgreSQL
  • AlloyDB pour PostgreSQL
  • AlloyDB Omni
  • Amazon RDS pour PostgreSQL
  • Amazon Aurora PostgreSQL

Niveau sans frais

Datastream vous permet de diffuser des données en streaming d'AlloyDB pour PostgreSQL vers BigQuery à l'aide du niveau sans frais, qui fournit jusqu'à 100 Gio de données de capture des données modifiées sans frais chaque mois. Pour en savoir plus, consultez la page Tarifs de Datastream.

Bonnes pratiques

Cette section décrit les bonnes pratiques recommandées pour configurer votre source PostgreSQL afin de l'utiliser avec Datastream.

Utiliser plusieurs flux pour éviter le blocage en tête de file

Pour les sources PostgreSQL, Datastream utilise un seul emplacement de réplication logique pour l'ensemble d'un flux. Une transaction importante ou plusieurs mises à jour sur une table à volume élevé peuvent retarder la réplication des données pour toutes les autres tables du même flux.

Pour éviter le blocage en tête de file, créez des flux distincts pour différents ensembles de tables. Par exemple, vous pouvez créer un flux pour les tables à volume élevé et un autre pour les tables à faible volume. Cela permet d'isoler les tables à forte rotation et d'éviter qu'elles ne retardent la réplication pour les autres tables.

Recommandation : identifiez les tables avec des taux d'écriture (INSERT/UPDATE/DELETE) exceptionnellement élevés et placez-les dans leur propre flux Datastream dédié avec un emplacement de réplication distinct.

Éviter les transactions de longue durée

Les transactions de longue durée peuvent entraîner une accumulation de journaux WAL (Write-Ahead Log). Comme WAL est séquentiel, PostgreSQL ne peut pas supprimer les anciens fichiers WAL requis par l'emplacement de réplication tant que la transaction longue n'est pas terminée. Cela augmente l'utilisation du disque WAL.

De plus, cela peut ralentir le décodage logique. Ce ralentissement est dû au fait que les transactions importantes déversent les modifications sur le disque, ce qui nécessite ensuite un réassemblage lent et intensif en E/S lors de la validation, bloquant la réplication de toutes les transactions suivantes. Recommandation : sur la base de données source, configurez les paramètres statement_timeout et idle_in_transaction_session_timeout pour éviter les transactions de longue durée. Pour en savoir plus, consultez la documentation PostgreSQL.

Utiliser le filtrage des tables lors de la création de publications

Si vous ne répliquez les modifications que de quelques tables, assurez-vous de créer une PUBLICATION qui n'inclut que ces tables. Lorsqu'une publication est limitée à des tables spécifiques, PostgreSQL conserve efficacement les modifications uniquement pour ces tables dans l'emplacement de réplication. Cela permet de réduire la taille de l'emplacement de réplication et d'améliorer les performances du décodage logique.

Gérer proactivement les emplacements de réplication

Datastream utilise un emplacement de réplication logique sur votre instance principale PostgreSQL, ce qui garantit que les fichiers WAL sont conservés jusqu'à ce que Datastream confirme qu'ils ont été traités. Si un flux échoue, est mis en pause ou supprimé sans que l'emplacement de réplication ne soit supprimé, PostgreSQL continue de conserver les fichiers WAL indéfiniment. Cela peut saturer le disque de votre serveur de base de données et entraîner une interruption de la production.

Recommandation : configurez des alertes efficaces et surveillez l'utilisation du disque WAL sur votre serveur PostgreSQL source.

Configurer correctement l'identité de la réplique

Le paramètre REPLICA IDENTITY indique à PostgreSQL les données à écrire dans le WAL pour les événements UPDATE et DELETE, ce qui permet à Datastream d'identifier les lignes qui ont été modifiées.

Si vous utilisez BigQuery comme destination, évitez de définir REPLICA IDENTITY sur FULL. Datastream utilise les colonnes enregistrées comme clé logique pour les opérations MERGE BigQuery. Si REPLICA IDENTITY est défini sur FULL et qu'une table comporte plus de 16 colonnes, cela dépasse la limite de 16 colonnes de BigQuery pour les clés primaires dans les opérations MERGE et interrompt le flux.

Recommandations (par ordre de préférence) :

  1. Meilleure option : utilisez une clé primaire. Le paramètre par défaut REPLICA IDENTITY DEFAULT utilise automatiquement et efficacement la clé primaire existante.
  2. Bonne option : si aucune clé primaire n'existe, créez un UNIQUE NOT NULL index et définissez REPLICA IDENTITY USING INDEX INDEX_NAME.
  3. Option la moins recommandée : n'utilisez le paramètre REPLICA IDENTITY FULL que sur les tables sans identifiant unique. Tenez compte de l'impact sur les performances, de la limite de 16 colonnes et de la restriction concernant les types de données compatibles pour les clés primaires si vous effectuez une réplication vers BigQuery.

Réplication à partir d'instances répliquées avec accès en lecture

Datastream est compatible avec la réplication à partir d'instances répliquées avec accès en lecture PostgreSQL pour PostgreSQL 16 et versions ultérieures.

Pour effectuer une réplication à partir d'une instance répliquée avec accès en lecture, vous devez effectuer les étapes de configuration suivantes sur l'instance principale :

  1. Créer des publications sur l'instance principale : lorsque Datastream se connecte à l'instance répliquée avec accès en lecture, les publications qui définissent les données à répliquer doivent être créées sur l'instance principale.
  2. Configurer les pulsations WAL : Datastream s'appuie sur des messages de pulsation WAL périodiques pour son mécanisme de point de contrôle. Lorsqu'il se connecte à une instance principale, Datastream gère la génération de ces pulsations. Toutefois, pour une instance répliquée avec accès en lecture, ces pulsations doivent être générées en externe.

Pour configurer des pulsations périodiques, vous pouvez créer une tâche cron dans PostgreSQL à l'aide de l'extension pg_cron :

SELECT cron.schedule_in_database(
    'datastream-heartbeat',             -- Job name
    '* * * * *',                        -- Every minute
   $$SELECT pg_logical_emit_message(true, 'datastream', 'cdc heartbeat')$$,
    'DATABASE_NAME',              -- Change this to your database name
    'USERNAME',                   -- Username to run as
    true                                -- Enabled
);

Remplacez les éléments suivants :

  • DATABASE_NAME : nom de la base de données pour laquelle vous souhaitez générer des pulsations.
  • USERNAME : nom de l'utilisateur sous lequel exécuter la tâche. Généralement postgres.

Limitations connues

Les limites connues d'utilisation de Datastream avec une base de données PostgreSQL en tant que source incluent les suivantes :

  • Les flux sont limités à 10 000 tables.
  • Une table contenant plus de 500 millions de lignes ne peut pas être remplie, sauf si les conditions suivantes sont remplies :
    1. La table comporte un index B-tree unique.
    2. L'index n'inclut pas de colonnes des types suivants : DOUBLE, FLOAT, MONEY, REAL, JSON, JSONB, BYTEA, TXID, XML, types de données composites ou types de données géométriques.
    3. Aucune des colonnes de l'index n'est annulable.
    4. Toutes les colonnes de l'index sont dans l'ordre croissant, ou toutes les colonnes de l'index sont dans l'ordre décroissant.
    5. Toutes les colonnes de l'index sont incluses dans le flux.
  • Les tables sans clé primaire doivent avoir une IDENTITÉ DE RÉPLIQUE. Sinon, seuls les événements INSERT sont répliqués vers la destination.
  • Les tables avec des clés primaires ne peuvent pas avoir l'IDENTITÉ DE RÉPLIQUE définie sur FULL ou NOTHING. Elle doit être définie sur DEFAULT.
  • Certaines modifications apportées au schéma source ne peuvent pas être détectées automatiquement, ce qui peut provoquer une corruption des données. Les modifications de schéma suivantes peuvent entraîner une corruption des données ou l'échec du traitement des événements en aval :
    • Supprimer des colonnes
    • Ajout de colonnes au milieu d'une table
    • Modifier le type de données d'une colonne
    • Réorganisation des colonnes
    • Suppression de tables (pertinente si la même table est ensuite recréée avec de nouvelles données ajoutées)
  • Datastream n'est pas compatible avec les colonnes des geometric types de données.
  • Datastream n'est pas compatible avec les colonnes des range types de données.
  • Datastream n'est pas compatible avec les tableaux de types de données non compatibles, les tableaux de types de données définis par l'utilisateur (y compris ENUM) ni les tableaux de types de données DATE, TIMESTAMP ou TIMESTAMP WITH TIME ZONE. Ces colonnes sont ignorées.
  • Pour les flux créés avant le 17 février 2026 : Datastream n'est pas compatible avec la réplication des événements UPDATE pour les lignes qui incluent des valeurs TOAST dans les colonnes faisant partie de l'identité de réplique de la table. Ces événements sont supprimés. Les flux créés après cette date ne sont pas soumis à cette exception.
  • Datastream n'est pas compatible avec la réplication des lignes qui incluent des valeurs JSON ou JSONB avec plus de 2 950 objets imbriqués. Les événements contenant ces valeurs JSON ou JSONB ne sont pas répliqués dans la base de données de destination.
  • Datastream n'est pas compatible avec la réplication des lignes qui incluent des valeurs NaN dans les colonnes NUMERIC (precision, scale). Les valeurs de ces colonnes sont remplacées par des valeurs NULL.
  • Datastream n'est pas compatible avec la réplication des colonnes du type de données hstore. Les valeurs de ces colonnes sont remplacées par des valeurs NULL.
  • Datastream n'est pas compatible avec la réplication des enregistrements non ASCII à partir d'une base de données source encodée en SQL_ASCII. Ces enregistrements sont supprimés.
  • Datastream n'est pas compatible avec la réplication des tables pour lesquelles des règles de sécurité au niveau des lignes (RLS) sont définies. Pour savoir comment contourner cette limite, consultez la section Comportement et limites de la source PostgreSQL.
  • Datastream ne capture pas les modifications apportées aux colonnes générées.
  • Datastream peut cesser de fonctionner ou ne pas capturer de nouveaux événements lorsqu'une mise à niveau de version majeure de PostgreSQL est effectuée sur la base de données. Nous vous suggérons de supprimer les emplacements de réplication avant la mise à niveau, puis de mettre à niveau la base de données et de recréer les emplacements de réplication. Si les flux échouent, récupérez-les en spécifiant le nouveau nom d'emplacement de réplication et effectuez un remplissage si la cohérence des données est requise.
  • Datastream n'est pas compatible avec la réplication des tables système PostgreSQL lorsque vous utilisez le flux de configuration automatisé. Si vous modifiez le flux que vous avez créé à l'aide du flux automatisé et que vous ajoutez des tables système, Datastream ignore ces tables et ne réplique aucune donnée ni aucune modification.

Étape suivante