Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous,
J'aimerais obtenir vos avis concernant la mise en œuvre d'une stratégie d'archivage de données.
La stratégie est la suivante :
Instance1 possède 4 années de données alimentée et mise à jour par une application.
Je souhaiterais :
1) Obtenir une instance (Instance2) qui contiendrait une sauvegarde complète de Instance1.
2) supprimer quotidiennement les données de Instance1 de plus d'un an
3) rejouer les transactions de Instance1 sur Instance2 excepté la purge quotidienne de Instance1.
Je pensais mettre en oeuvre une réplication par flux de Instance1 vers Instance2 mais je crains que la purge quotidienne appliquée sur I1 sera rejouée sur Instance2.
Alors que l'objectif de I2 est de conserver les données jusqu'à 4 ans.
Autre idée: toujours en réplication par flux,
Exporter les données à purger sur une autre base avant la purge.
Puis les importer sur I2 après purge.
--> dans ce cas, a-t-on le droit d'écrire sur une instance secondaire ? N'est ce pas trop compliquer à gérer cela ?
Avez vous des idées et des suggestions à proposer pour réaliser chaque étape ?
Ou une proposition pour une autre solution ?
Si un outil permet de faciliter ce genre de gestion je serais bien intéressé ?
La version de Postgresql est la 9.5 sur Red Hat 7.1
Merci à tous.
Dernière modification par Mika313 (01/03/2018 19:42:30)
Hors ligne
Je pensais mettre en oeuvre une réplication par flux de Instance1 vers Instance2 mais je crains que la purge quotidienne appliquée sur I1 sera rejouée sur Instance2.
Je confirme que ce sera immédiatement rejoué.
--> dans ce cas, a-t-on le droit d'écrire sur une instance secondaire ? N'est ce pas trop compliquer à gérer cela ?
Il n'est pas possible d'écrire sur une instance secondaire.
Ou une proposition pour une autre solution ?
Vous parlez de données, sans dire si cela concerne une ou plusieurs tables. Ça a un impact sur la solution potentielle. Donc vous voulez répliquer une ou plusieurs tables ou toutes les tables ? et la purge se fait sur une ou plusieurs tables ?
Guillaume.
Hors ligne
Merci pour votre réactivité.
La réplication (ou l'archivage) concerne toute les tables de la base de Instance1.
--> quelques soit la modification jouée sur I1, elle devra se faire sur I2. Sauf les suppressions qui seront seulement dûes à la purge.
Il n'y a pas de contraintes critique sur la mise à jour de I2. Elle pourrait s'aligner une fois par jour par exemple.
Et concernant la purge, quelques tables ne seront pas concernées.
--> On purge tout sauf quelques tables.
Hors ligne
Une personne expérimentée sur Postgresql, me conseille :
1) migrer en version 10 pour mettre en place la réplication logique. L'instance d'archivage I2 s'abonnerait aux INSERT et UPDATE de I1.
2) si pas de migration possible, peut-être voir une solution basée sur des triggers. En déclarant I2 table externe, les déclencheurs créés sur I1 reproduiraient les INSERT et UPDATE sur I2. Mais ceci dépend des fréquences d'ecritures journalières...
3) utiliser un outil communautaire.
Pour le point 3, j'ai répertorié pglogical qui (d'après la documentation) permet de filtrer la réplication avec une granularité sur les ordres. C'est à dire : réplique uniquement INSERT et UPDATE.
La personne à qui j'ai exposé le problème m'oriente vers Slony à condition qu'il puisse filtrer la réplication.
Donc mes questions sont :
Est-ce que Slony permet de répliquer uniquement les ordres INSERT et UPDATE ?
Est-ce qu'une personne parmi vous a déjà mis en place Pglogical (en production si possible) ? Quels sont vos retex svp ? J'ai beaucoup de mal avec sa documentation.
Merci à tous.
Hors ligne
Bonjour,
PG10 avec la réplication logique semble être le mieux quand même.
Slony ne peux pas faire ça.
Hors ligne
Oui j'ai bien compris qu'une mise à jour en version 10 est la solution la plus simple et la plus pérenne.
Reste à voir si cela sera prévue assez rapidement.
Merci pour vos réponses.
Hors ligne
Pour répondre aux questions
Est-ce que Slony permet de répliquer uniquement les ordres INSERT et UPDATE ?
Non. Soit il réplique toutes les modifications d'une table, soit aucune.
Est-ce qu'une personne parmi vous a déjà mis en place Pglogical (en production si possible) ? Quels sont vos retex svp ? J'ai beaucoup de mal avec sa documentation.
Il faut bien noté que pglogical n'est pas développé par la communauté mais par une société. En cas de problème (bug ou autres), vous devez voir avec eux. Je pense qu'il est nettement préférable d'utiliser la v10. C'est pglogical mais intégré dans PostgreSQL, et supporté par la communauté.
Guillaume.
Hors ligne
Merci pour vos réponses gleu.
Hors ligne
Pages : 1
