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

Vous pouvez utiliser Datastream pour répliquer des données historiques et des modifications en cours d'une base de données PostgreSQL vers votre destination pour l'analyse en temps réel et la synchronisation de la base de données.

Pour préparer la réplication PostgreSQL dans Datastream, consultez le comportement de réplication, les versions et types de bases de données compatibles, les bonnes pratiques, les exigences pour les instances dupliquées avec accès en lecture et les limites connues.

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 dans 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 REPLICA IDENTITY 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. Ces messages sont requis par Datastream pour garantir la disponibilité de la source et calculer l'actualisation. 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 Réplication à partir d'instances dupliquées avec accès en lecture. Nous vous recommandons d'en tenir compte si d'autres configurations de réplication lisent à partir 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 bases 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 d'AlloyDB pour PostgreSQL vers BigQuery à l'aide du niveau sans frais, qui fournit jusqu'à 100 Gio de données de capture de 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 ligne

Pour les sources PostgreSQL, Datastream utilise un seul emplacement de réplication logique pour l'ensemble d'un flux. Une transaction volumineuse 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 de tête de ligne, 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 à fort taux de renouvellement et d'éviter qu'elles ne retardent la réplication des autres tables.

Recommandation : Identifiez les tables présentant 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 l'accumulation de journaux WAL. Comme le 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. Le ralentissement est dû au fait que les transactions volumineuses déversent les modifications sur le disque, ce qui nécessite un réassemblage lent et gourmand en E/S lors du commit, bloquant ainsi 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 que les modifications de quelques tables, veillez à créer un PUBLICATION qui n'inclut que ces tables. Lorsqu'une publication est limitée à des tables spécifiques, PostgreSQL ne conserve efficacement que les modifications apportées à 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 de décodage logique.

Gérer les emplacements de réplication de manière proactive

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 soit supprimé, PostgreSQL continue de conserver les fichiers WAL indéfiniment. Cela peut remplir 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 l'instance répliquée

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 journalisé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. Idéal : utilisez une clé primaire. Le paramètre par défaut de REPLICA IDENTITY DEFAULT utilise automatiquement et efficacement la clé primaire existante.
  2. Bonne pratique : si aucune clé primaire n'existe, créez un index UNIQUE NOT NULL et définissez REPLICA IDENTITY USING INDEX INDEX_NAME.
  3. Moins recommandé : 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 sur les types de données acceptés pour les clés primaires en cas de 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 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. Lors de la connexion à une instance principale, Datastream gère la génération de ces signaux de pulsation. 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 qui exécutera la tâche. Habituellement : postgres.

Limitations connues

Voici certaines des limites connues affectant l'utilisation de Datastream avec une base de données PostgreSQL comme source :

  • Les flux sont limités à 10 000 tables.
  • PostgreSQL rejette strictement les octets NULL (0x00) dans les colonnes de chaînes UTF-8. Datastream ne supprime pas les octets NULL. Si une chaîne source contient des octets nuls 0x00, l'insertion par lot échoue et la réplication s'arrête. Nous vous recommandons de nettoyer ou de remplacer les caractères CHAR(0) dans la base de données source avant la réplication.
  • Vous ne pouvez pas configurer les flux PostgreSQL pour qu'ils démarrent à partir de la position la plus récente.
  • Une table contenant plus de 500 millions de lignes ne peut pas être remplie, sauf si les conditions suivantes sont remplies :
    1. La table possède un index B-tree unique.
    2. L'index n'inclut pas les 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 ne peut être nullable.
    4. Toutes les colonnes de l'index sont classées par ordre croissant ou toutes les colonnes de l'index sont classées par ordre décroissant.
    5. Toutes les colonnes de l'index sont incluses dans le flux.
  • Les tables sans clé primaire doivent avoir une REPLICA IDENTITY. Sinon, seuls les événements INSERT sont répliqués vers la destination.
  • Les tables avec des clés primaires ne peuvent pas avoir la valeur REPLICA IDENTITY définie sur FULL ou NOTHING. Il doit être défini 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 :
    • Suppression de colonnes…
    • Ajout de colonnes au milieu d'un tableau
    • Modifier le type de données d'une colonne.
    • Réorganisation des colonnes.
    • Suppression de tables (pertinent 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 types de données geometric, tels que BOX, CIRCLE, LINE, LSEG, PATH, POINT et POLYGON. Ces colonnes sont répliquées en tant que NULL.
  • Datastream n'est pas compatible avec les colonnes des types de données range.
  • Datastream n'est pas compatible avec les tableaux de types de données non compatibles (tels que les types spatiaux), les tableaux de LTREE, les tableaux de types de données définis par l'utilisateur (y compris ENUM) ou les tableaux de DATE, TIMESTAMP ou TIMESTAMP WITH TIME ZONE (TIMESTAMPTZ). Datastream ignore ces colonnes lors de la réplication.
  • Pour les flux créés avant le 17 février 2026 : Datastream ne permet pas de répliquer les événements UPDATE pour les lignes qui incluent des valeurs TOAST dans les colonnes faisant partie de l'identité de l'instance répliquée de la table. Ces événements sont supprimés. Les flux créés après cette date ne sont pas soumis à cette exception.
  • Datastream ne permet pas de répliquer les lignes qui incluent des valeurs JSON ou JSONB avec plus de 2 950 objets imbriqués. Les événements contenant de telles valeurs JSON ou JSONB ne sont pas répliqués dans la base de données de destination.
  • Datastream ne permet pas de répliquer les 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 ne permet pas de répliquer les colonnes du type de données hstore. Les valeurs de ces colonnes sont remplacées par des valeurs NULL.
  • Datastream ne prend pas en charge la réplication d'enregistrements non ASCII à partir d'une base de données source encodée en SQL_ASCII. Ces enregistrements sont supprimés.
  • Datastream ne permet pas de répliquer 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 Comportement et limites de la source PostgreSQL.
  • Pour les colonnes de flux avec des types de données de longueur variable qui utilisent la technique TOAST (The Oversized-Attribute Storage Technique) : Si une valeur TOAST inchangée est supprimée du journal WAL lors d'une opération UPDATE, Datastream effectue une recherche active dans la base de données source pour tenter de récupérer la valeur manquante. Par conséquent, les modifications intermédiaires peuvent ne pas être capturées dans les scénarios impliquant des mises à jour rapides et consécutives, ou une suppression rapide après une insertion. Notez que les opérations DELETE ne déclenchent pas cette opération de recherche active. Cette limitation pour les colonnes de longueur variable qui utilisent TOAST est particulièrement pertinente lorsque vous utilisez le mode d'écriture "Ajout uniquement", qui s'attend à ce que toutes les modifications intermédiaires soient capturées.
  • 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 de l'emplacement de réplication, puis effectuez un backfill si la cohérence des données est requise.
  • Datastream ne permet pas de répliquer les tables système PostgreSQL lorsque vous utilisez le processus de configuration de flux 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 sans avertissement et ne réplique aucune donnée ni modification de celles-ci.

Étapes suivantes