Cet article est la suite d’une série d’articles sur la réplication logique dans la version 10 de PostgreSQL :

  1. PostgreSQL 10 et la réplication logique – Fonctionnement
  2. PostgreSQL 10 et la réplication logique – Mise en oeuvre
  3. PostgreSQL 10 et la réplication logique – Restrictions

 

Celui-ci va porter sur les restrictions de la réplication logique.

Restrictions

La documentation de postgreSQL est très bien faite. Il y a toute une page sur les restrictions.

Ordres DDL

Le schéma et les ordres DDL ne sont pas répliqués. Il faudra donc veiller à bien reporter toute modification de schéma. Dans le cas contraire un conflit de réplication pourrait se produire ce qui bloque toute réplication. Une fois la correction apportée la réplication peut reprendre. Pour éviter toute erreur il est préférable d’appliquer les changements de schéma sur le “secondaire” en premier.

Séquences

Les séquences ne sont pas répliquées. Les données d’une colonne serial seront bien répliquées mais le compteur de la séquence ne sera pas incrémenté. Si le “secondaire” est seulement utilisé en lecture seule ça ne posera pas de problème. En revanche, en cas de bascule il faudra mettre à jour la séquence ou la placer à une valeur supérieure à la valeur la plus haute présente dans la table.

Ordre TRUNCATE

Les ordres TRUNCATE ne sont pas répliqués. Il peut être utile de révoquer le droit de TRUNCATE sur les tables répliquées avec : REVOKE TRUNCATE ON TABLE matable FROM utilisateur.

Large Objects

Les Large Objets ne sont pas répliqués

Schéma et tables

La réplication logique ne réplique que des tables, il n’est pas possible de répliquer des vues, vues matérialisées, partition racine, foreign tables… Les schéma « source » et « destination » doivent être identiques. Il n’est pas possible de répliquer la table t1 du schéma s1 dans un schéma s2 sur un secondaire.

Replica Identity

Pour les opérations UPDATE et DELETE, la table doit avoir une replica identity. Dans le cas contraire le moteur remontera une erreur. Par défaut c’est la clé primaire qui est utilisée.

Share

3 thoughts on “PostgreSQL 10 et la réplication logique – Restrictions

  1. Bonjour,

    Serait il possible de « contourner » la non-réplication du truncate en faisant un truncate suivi d’un delete (Gain de temps sur la source et résultat identique sur la destination avec un gros temps de latence)

    Répondre
    • Bonjour,

      Je viens de faire quelques tests. Votre solution ne fonctionnera pas : le TRUNCATE n’est pas répliqué, du coup lors du DELETE il n’y a aucune ligne à supprimer car elles n’existent plus. Les lignes restent donc toujours présente sur le secondaire.

      Répondre

Ecrire un commentaire

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url=""> 

requis