Vous n'êtes pas identifié(e).
Résolu par la séparation du serveur de test et de celui de réplication : mise en place d'une réplication physique et l'utilisation de pg_dumpalll une fois par mois et pg_dump pour les bases tests
Bonjour.
Je souhaite répliquer un cluster de production vers un serveur de test en mode lecture/écriture mais pas en mode master/master?
La réplication logique doit permettre de le faire.Mais le cluster contenant une dizaine de bases de données, ça veut dire que je vais devoir créer une dizaine de publications, une dizaine de souscriptions et autant de slots de réplication.
Et pour couronner le tout, certaines tables n'ont pas de clef primaire ce qui veut dire que je devrais les rajouter manuellement avant de mettre en place la réplication.
N'y aurait-il pas une possibilité plus globale du type pg_basebackup permettant de garder la cible en lecture/écriture?
Merci d'avance.
Dernière modification par PEREZ J. (06/11/2023 13:24:26)
Hors ligne
Bonjour,
Voulez-vous maintenir la réplication une fois les écritures activées sur le serveur de test?
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour,
Voulez-vous maintenir la réplication une fois les écritures activées sur le serveur de test?
Bonjour.
Idéalement oui si la même instance me permet de faire des tests sur une copie des bases répliquées. Par exemple : avoir une base activite à jour et la possibilité de créer et travailler sur une base activite_test avec les données à jour.
Mais la priorité reste quand même de pouvoir travailler avec un cluster conforme à mon instance de production sans impact sur elle et de ne pas être obligé de détruire/reconstruire tout le cluster quand je veux repartir de quelque chose de propre.
Hors ligne
Ce n'est toujours pas très clair. Voulez vous créer localement une base de données XXX_test à chaque fois depuis la base originale XXX, ou souhaitez-vous répliquer les données de chaque base vers 2 bases: une base identique et une base XXX_test ?
Julien.
https://rjuju.github.io/
Hors ligne
Ce n'est toujours pas très clair. Voulez vous créer localement une base de données XXX_test à chaque fois depuis la base originale XXX, ou souhaitez-vous répliquer les données de chaque base vers 2 bases: une base identique et une base XXX_test ?
Dans l'idéal, je souhaiterais pouvoir répliquer chaque base vers 2 bases: une base identique et une base XXX_test que je pourrai bidouiller tranquillement. Sinon je pourrais me contenter de la version créer localement une base de données XXX_test à chaque fois depuis la base originale XXX avec XXX_test en lecture/écriture (dans ce cas, ça serait bien de pouvoir le faire plus facilement qu'à la main avec pg_dump, transfert du fichier vers le serveur test puis psql ou pg_restore)
Hors ligne
Si j'étais vous je partirais plutôt sur une approche basée sur l'automatisation d'un pg_dump / pg_restore plutôt que de la réplication logique, surtout si vous avez une bonne bonne passante entre les serveurs. Cela devrait être plus simple à mettre en place, et risque moins d'impacter votre serveur de production. La réplication logique est loin d'être gratuite : il faut redémarrer l'instance pour changer le niveau de WAL, les WAL générés sont plus volumineux, les grosses transactions sont assez couteuses à décoder et peuvent entraîner de nombreux problèmes, la syncronisation initiale est loin d'être rapide etc etc. Surtout qu'en plus vous avez en plus des tables relativement incompatibles avec la réplication logique (celles sans clé primaires).
Julien.
https://rjuju.github.io/
Hors ligne
Merci pour votre réponse.
Je vais commencer par mettre en place une réplication continue de tout le cluster de production vers un serveur de réplication.
Mais je suppose qu'en dehors d'une réplication logique on ne peut pas répliquer les bases XXX sans les XXX_test si il y en a.
Est-ce que les drop sont répercutés en wal_level : logical?
Dernière modification par PEREZ J. (26/10/2023 17:27:52)
Hors ligne
Aucune opération DDL (sauf TRUNCATE) n'est répliquée dans une réplication logique.
Guillaume.
Hors ligne
C'est noté!.
Encore merci
Hors ligne
Aucune opération DDL (sauf TRUNCATE) n'est répliquée dans une réplication logique.
Quand je parle de wal_level : logical c'est le niveau de WAL de la réplication physique que j'ai mise en place, ce n'est pas celui d'une réplication logique par souscription.
Du coup les opérations DDl semblent bien prises en compte....ce qui m'arrange.
Hors ligne
Bonjour,
avec la réplication physique, toutes les opérations sur le leader sont effectuées automatiquement sur le ou les replicas.
Mais contrairement à la replication logique, les réplicas en réplication physique sont en read-only.
Dernière modification par ruizsebastien (07/11/2023 12:56:25)
Cordialement,
Sébastien.
Hors ligne
