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

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

  • Comportement de Datastream concernant la gestion des données extraites d'une base de données PostgreSQL source
  • 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
  • Limites connues de l'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 des schémas ou des tables spécifiques.
  • Toutes les données historiques sont répliquées.
  • Toutes les modifications apportées au 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ÉPLICA 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. 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é des sources et calculer la fraîcheur des données. 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

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 même table à fort volume 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 à fort taux de churn et d'éviter qu'elles ne retardent la réplication des autres tables.

Recommandation : identifiez les tables dont les taux d'écriture (INSERT/UPDATE/DELETE) sont 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 de transaction (WAL). Comme le WAL est séquentiel, PostgreSQL ne peut pas le vider tant que la longue transaction n'est pas terminée, même si d'autres transactions sont en cours. Cela peut augmenter la taille de l'emplacement de réplication et ralentir le décodage logique, car les modifications apportées par les transactions de longue durée qui se chevauchent avec la transaction actuelle doivent être décodées à plusieurs reprises.

Recommandation : dans 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 de tableau 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 de décodage logique.

Gérer proactivement les emplacements de réplication

Datastream utilise un emplacement de réplication logique sur votre instance PostgreSQL principale, 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 veille ou supprimé sans que l'emplacement de réplication 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. Recommandation : 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 : s'il n'existe aucune clé primaire, créez un index UNIQUE NOT NULL et définissez REPLICA IDENTITY USING INDEX INDEX_NAME.
  3. Solution 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 acceptés pour les clés primaires si vous effectuez une réplication vers BigQuery.

Limites connues

Voici quelques-unes des limites connues de l'utilisation de Datastream avec une base de données PostgreSQL comme source :

  • 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 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 nulle.
    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 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 FULL ou NOTHING pour REPLICA IDENTITY. Elle doit être définie sur DEFAULT.
  • Datastream ne peut pas répliquer à partir d'une instance répliquée avec accès en lecture, car PostgreSQL n'est pas compatible avec le décodage logique dans les instances répliquées avec accès en lecture.
  • 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'un tableau
    • Modifier le type de données d'une colonne.
    • Réorganiser les colonnes
    • Suppression de tables (pertinente si la même table est ensuite recréée avec de nouvelles données ajoutées).
  • Datastream n'accepte pas les colonnes de type de données geometric.
  • Datastream n'accepte pas les colonnes de type de données range.
  • Datastream n'est pas compatible avec les tableaux de types de données non acceptés, 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.
  • 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 ignorés.
  • 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 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 de type de données hstore. Les valeurs de ces colonnes sont remplacées par des valeurs NULL.
  • Datastream ne permet pas de répliquer les 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 les tables pour lesquelles des règles de sécurité au niveau des lignes sont définies. Pour savoir comment contourner cette limite, consultez Comportement et limites des sources PostgreSQL.
  • Datastream ne capture pas les modifications apportées aux colonnes générées.
  • Il est possible que Datastream cesse de fonctionner ou ne capture aucun nouvel événement 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, puis effectuez un remplissage si la cohérence des données est requise.

Étape suivante