pgactive - extension de réplication active-active pour Postgres

• Une extension de réplication active-active pour PostgreSQL, créée et publiée par AWS
• Lorsqu’il est nécessaire d’écrire et de modifier des données sur plusieurs instances PostgreSQL, il est possible de mettre en place une architecture permettant des modifications simultanées et leur réplication sur plusieurs instances, au lieu du modèle actif-standby classique où une instance donnée est la seule à accepter les changements
• Adapté à des scénarios tels qu’une base de données hautement disponible sur plusieurs régions, la réduction de la latence d’écriture, les mises à jour blue/green d’une application ou encore la migration bidirectionnelle de données
• S’appuie sur la réplication logique pour prendre en charge la détection des conflits, la résolution des conflits d’écriture et la conversion du format de la base de données cible

Concept de réplication active-active

• La réplication (Replication) est une technologie qui synchronise les modifications entre bases de données
• Dans l’architecture actif-standby classique de PostgreSQL, une seule instance accepte les modifications tandis que les autres sont en lecture seule, ce qui en fait une source de données unique
• pgactive fournit une topologie de réplication active-active qui permet l’écriture simultanée de données sur plusieurs instances
• Cette approche convient aux environnements nécessitant plusieurs points d’écriture, comme les déploiements multi-région ou les migrations bidirectionnelles
• Le modèle active-active nécessite une gestion spécifique des conflits, de la latence et de certaines limitations fonctionnelles

Technologie clé : réplication logique

• La réplication logique (Logical Replication) transmet les données dans un format interprétable par des systèmes externes
• Grâce à la réplication logique, il est possible d’implémenter diverses fonctions supplémentaires dans la base cible, comme la détection des conflits, la résolution des conflits d’écriture ou la transformation des requêtes
• PostgreSQL a introduit une réplication logique native en 2017 avec la version 10, mais la réplication active-active nécessite des fonctionnalités supplémentaires
• En raison des caractéristiques de conception de PostgreSQL, ces fonctionnalités peuvent être développées et appliquées sous forme d’extension
• La communauté de développement PostgreSQL ajoute elle aussi progressivement ces capacités au projet principal

[GN⁺]

Avis Hacker News

• J’ai essayé de résumer l’historique de BDR, pglogical, pgactive et Postgres Distributed (PGD) d’après ce que j’ai entendu de collègues des équipes 2nd Quadrant et EDB
  Le tout premier, et toujours open source aujourd’hui, est BDR1 (lien), et pgactive en est dérivé
  BDR2 était une réécriture de BDR1 en closed source, puis a fini par être abandonné
  pglogical v1 et v2 (tous deux open source, lien) sont ensuite sortis, et la v1 a été largement remaniée avant d’être intégrée à Postgres 10
  Fort de l’expérience de la réplication logique de Postgres 10, 2nd Quadrant a lancé le développement de pglogical v2, d’où est aussi issu pgEdge
  Ensuite, 2nd Quadrant a créé les versions closed source pglogical v3 et BDR v3, qui ont ensuite été fusionnées dans BDR v4
  Le nom du produit BDR a ensuite été changé en Postgres Distributed (PGD, lien)
  Après le rachat de 2ndQuadrant par EDB, EDB a publié PGD v6
  • PostgresPro dispose aussi de son propre système distinct de réplication multi-master documentation
  • Quelqu’un demande si PGDv6 est toujours closed source
• Ce système utilise la réplication logique de Postgres pour transmettre les changements d’une instance à une autre
  En cas de conflit, c’est la dernière valeur écrite selon l’horodatage qui est finalement appliquée
  L’historique des conflits est conservé dans une table spéciale appelée pgactive_conflict_history, ce qui permet d’inspecter l’historique et de les résoudre manuellement
  Voir ici pour plus de détails et la documentation
  • Quelqu’un se demande si cela correspond bien à de la réplication multi-master
    Si cette fonctionnalité pouvait être officiellement intégrée à Postgres, ce serait intéressant
  • Du point de vue utilisateur, on aimerait savoir si ses écritures sont validées immédiatement ou si l’on est simplement dans un modèle à convergence finale
• Quelqu’un demande si d’autres ont récemment utilisé directement la base de données de Bloomberg, comdb2
• Sujet connexe mais un peu à côté : existe-t-il un moyen de faire de la « réplication avec écriture locale possible (basée sur une read replica) » ?
  Par exemple, lire les données de production ou de staging, mais pouvoir les modifier uniquement en local, sans que ces résultats ne soient répercutés en amont
  Aujourd’hui, le plus courant semble être de créer périodiquement des snapshots via des scripts (cron, etc.) en envoyant des dumps ou des requêtes, de les stocker sur S3, puis de les récupérer en local pour restaurer les données
  Cette méthode fonctionne généralement bien, sauf quand la construction des index prend beaucoup trop de temps
  • À noter qu’à cause des données sensibles, comme les informations personnelles, il est risqué de faire entrer directement ce type de données dans des environnements de staging ou de dev
    Les enjeux juridiques et éthiques étant importants, la plupart des entreprises ne recommandent pas cette approche
  • Avec la réplication logique de Postgres et des filtres, on peut faire de la réplication unidirectionnelle, puis une fois le replication slot supprimé, on peut modifier librement les données en local
    Cela permet de modifier uniquement les tables locales sans impact sur le primary
  • Garder une base locale « propre » comme sauvegarde, puis la cloner à la demande pour l’utiliser comme base de développement, permet des copies très rapides sans reconstruction d’index
    La commande createdb --template est recommandée
  • Quelqu’un demande comment gérer les conflits entre écritures locales et mises à jour distantes
    Il ne voit pas de stratégie de fusion applicable à tous les cas
  • À sa connaissance, c’est le comportement standard d’une configuration de réplication logique Postgres
    Ce n’est pas que les écritures soient bloquées sur la replica, c’est simplement que leur résultat ne se propage pas ailleurs
• Il faut toujours garder à l’esprit que le terme « Conflict resolution » signifie au fond « sacrifier la durabilité en jetant des données déjà validées et commit »
  Le mieux est de concevoir l’architecture de sorte qu’il n’y ait pas de chevauchement des zones d’écriture entre les instances actives
  Dans ce cas, un outil comme pgactive peut être utile
  Sinon, mieux vaut partir directement sur une base de données distribuée comme Yugabyte
  • La documentation officielle recommande aussi d’éviter les conflits en répartissant les schémas entre les masters, de sorte que « chaque master soit l’unique writer de son schéma »
    Tous les masters peuvent lire tous les schémas, mais chacun n’écrit que sur sa propre partie
    Quelqu’un demande si, au lieu des schémas, on pourrait aussi répartir les responsabilités via des partitions ou autre
• On en vient à se demander pourquoi AWS a développé ça
  On ne voit pas immédiatement dans quel produit maison cette fonctionnalité serait utilisée
  RDS utilise la block replication, Aurora une SAN replication propriétaire
  L’hypothèse est que cela pourrait servir du côté de DMS
  • C’est peut-être lié à la sortie récente de Aurora DSQL
  • En réalité, certains ont du mal à y voir un grand intérêt
    Ils se demandent pourquoi faire cela avec une base relationnelle fortement ACID
  • À leur connaissance, la SAN replication d’Aurora n’est pas utilisée pour la cross region replication
  • Le readme du dépôt précise aussi que l’usage principal est la « construction de clusters de bases de données hautement disponibles en multi-région »
  • En pratique, cette fonctionnalité était déjà proposée sur RDS Postgres depuis deux ans (lien associé)
    Mais il y a un mois, elle a été officiellement publiée en open source pour la communauté (annonce officielle)
• J’ai déjà fait tourner plusieurs clusters avec repmgr et patroni dans des environnements réellement sans interruption, et ce plugin est vraiment le genre de chose que je n’installerais qu’en dernier recours
  Pour bien dormir la nuit, mieux vaut l’éviter autant que possible
• Coïncidence : je cherchais récemment un moyen simple de mettre en place un cluster Postgres hautement disponible avec « failover automatique, récupération de nœud et restauration à un instant donné »
  La combinaison patroni+etcd+haproxy est souvent recommandée, et vu l’enthousiasme de ceux qui l’ont utilisée, il doit y avoir une bonne raison
  Cela dit, quand on regarde les fichiers d’exemple en docker compose, ça peut sembler un peu intimidant
  pgpool paraît plus simple puisqu’il semble suffire de le placer devant chaque Postgres
  Je serais curieux d’avoir des recommandations ou retours d’expérience de gens qui aiment Postgres en production
  L’objectif est de monter, aussi simplement que possible avec docker compose, un cluster offrant haute disponibilité, pertes minimales voire nulles, et restauration à un instant donné
  • Quelqu’un demande si la personne cherche un outil comme Barman
  • Quelqu’un utilise cloudnativepg, et dit que la plupart des fonctionnalités nécessaires marchent immédiatement avec ça
• Partage d’autres ressources sur pgactive et des cas liés
  <i>Pgactive: Active-Active Replication Extension for PostgreSQL on Amazon RDS</i>
  Post Hacker News (post d’octobre 2023, 1 commentaire)
• Cela semble être asynchrone, et il doit donc y avoir des problèmes importants du côté de l’isolation des transactions
  • Au final, c’est une question de compromis
    Autrement dit, il faut accepter les avantages et inconvénients selon son contexte