Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous,
Après avoir parcouru le web pour regarder les solutions existantes assurant le mécanisme de réplication de bases PG je viens demander l'avis de la communauté (vaut mieux un qui sait que 10 qui cherchent 
).
Voila le topo :
Nous avons un serveur postgres présent dans un site A. Jusqu'ici tout va bien. Le projet consiste à mettre en place un autre serveur dans un site B et que ce dernier devienne le maître. Il est donc nécessaire, lors de la mise en place de synchroniser B sur A (il est possible de dumper la base, mais si une solution existe pour gérer l'ensemble des cas c'est top).
Il n'y a aucune garantie que le site B ait une connexion permanente sur A, mais il est primordial de ne perdre aucune infos. La réplication doit donc être asynchrone (et fiable !).
La base à répliquer possède des "larges objects".
Les mises à jour de la structure de la base doivent être propagées (dans un sens ou dans l'autre, les changements de structure seront rétro-compatible au point de vue données : ajout de table/colonnes uniquement).
Et pour finir, la base A doit rester accessible en lecture.
J'ai parcouru les documentation de Slony, bucardo, et Londiste mais il y a beaucoup d'infos à assimiler et je n'ai pas assez de temps pour jauger chaque solution....Et je n'ai pas d'expérience (encore) dans cet aspect de PG.
Alors la question est simple... d'après votre expérience qu'elle est la meilleure solution à mettre en place pour ce genre de problématique ?
Merci d'avance pour vos réponses.
Hors ligne
Vous êtes sûr que ce sont des Larges Objects ? les données binaires peuvent aussi être stockées dans une colonne de type bytea.
Si ce sont des Larges Objects, vous n'avez pas beaucoup de choix. Vous ne pouvez utiliser que pgpool ou la réplication par journaux de transactions de PostgreSQL. Et vu votre pré-requis sur les connexions, pgpool serait certainement à exclure.
Comme vous avez aussi besoin de propager (automatiquement je suppose) les modifications de schéma, là-aussi, pas beaucoup de choix, c'est pgpool ou la réplication des journaux de transactions.
Bref, en gros, il me semble que ce qui se rapproche le plus de votre demande, c'est la réplication avec les journaux de transactions. Le problème, c'est que vous allez l'air de vouloir des esclaves en lecture seule, ce que la dernière version de PostgreSQL (la 8.4) ne permet pas. Il vous faudra donc attendre la version 9.0.
Pour ce qui est des solutions que vous avez regardé (Slony, Londiste et Bucardo), aucun ne propage automatiquement les modifications de schémas. Slony et Londiste ne propagent pas les Large Objects (et je suis prêt à parier que c'est aussi le cas de Bucardo).
Voilà.
Guillaume.
Hors ligne
Merci à vous Gleu !
Pour les larges objects effectivement vous avez eu du nez, il s'agit en fait de Bytea (j'ai vérifié ce matin), donc.. ben pas de large object (pourtant j'en étais quasi sûr :-/ ).
Dans le cadre du projet, il est plus important que les esclaves soient en lecture que de propager automatiquement les modifications de schémas (on trouvera bien un moyen de moyenner pour patcher les bases).
De plus il est malheureusement impossible d'attendre la version 9 de pg qui semble être prévu pour courant 2010 (au pire dans 6 mois ce qui est un peu trop long).
L'impossibilité de lire sur les slaves par l'utilisation des journaux de transaction exclue de facto cette possibilité.
Donc pour résumer, si pas de Large object et si on met en place un moyen de propager les modifications de schémas, les solutions telles que Slony, Londiste et Bucardo peuvent être utilisées.
La lecture du slave et la synchronisation asynchrone sont les 2 points les plus importants et interdépendants => si le master est coupé du slave, il faut qu'on puisse lire le slave et que la synchronisation reprenne au plus tôt sans perte de données. C'est absolument fondamental.
Il est dommage qu'une solution ne gère pas tous les cas de figure nécessaire à notre projet (qui a dit fainéant ?!) mais il faut que la solution choisie permette de mettre en place toutes les fonctionnalités.
En ce qui concerne les points cruciaux une solution ressort-elle du lot ?
Encore merci pour vos éclaircissement !
Hors ligne
Pour les larges objects effectivement vous avez eu du nez, il s'agit en fait de Bytea (j'ai vérifié ce matin), donc.. ben pas de large object (pourtant j'en étais quasi sûr :-/ ).
C'est une bonne nouvelle, les possibilités en terme de réplication sont plus intéressantes.
Dans le cadre du projet, il est plus important que les esclaves soient en lecture que de propager automatiquement les modifications de schémas (on trouvera bien un moyen de moyenner pour patcher les bases).
Bah, avec les bytea, vous pouvez pratiquement toutes les utiliser, surtout si la propagation des modifications de schémas n'est pas si importante.
De plus il est malheureusement impossible d'attendre la version 9 de pg qui semble être prévu pour courant 2010 (au pire dans 6 mois ce qui est un peu trop long).
Mi-Août, c'est ce qui se dit actuellement.
L'impossibilité de lire sur les slaves par l'utilisation des journaux de transaction exclue de facto cette possibilité.
Sauf en 9.0.
Donc pour résumer, si pas de Large object et si on met en place un moyen de propager les modifications de schémas, les solutions telles que Slony, Londiste et Bucardo peuvent être utilisées.
Exact.
La lecture du slave et la synchronisation asynchrone sont les 2 points les plus importants et interdépendants => si le master est coupé du slave, il faut qu'on puisse lire le slave et que la synchronisation reprenne au plus tôt sans perte de données. C'est absolument fondamental.
Je n'ai jamais utilisé Bucardo mais il semble capable de le faire. Slony et Londiste peuvent le faire. Slony à coup sûr.
Il est dommage qu'une solution ne gère pas tous les cas de figure nécessaire à notre projet (qui a dit fainéant ?!) mais il faut que la solution choisie permette de mettre en place toutes les fonctionnalités.
Bah, une solution qui règle tout, j'en connais pas personnellement... quelque soit le domaine.
En ce qui concerne les points cruciaux une solution ressort-elle du lot ?
Slony à coup sûr. Peut-être Londiste.
Guillaume.
Hors ligne
Merci beaucoup du temps consacré et de la rapidité des réponses !
A moi la documentation de Slony et de Londiste .
Encore merci !
Hors ligne
Pour commencer, http://www.dalibo.org/hs44_slony_la_rep … ar_trigger pour Slony et http://www.dalibo.org/hs44_londiste_la_ … _par_skype pour Londiste. En ce qui concerne Slony, basez-vous pour l'instant sur la version 1.2 (http://www.slony.fr/documentation-1.2/ en français et http://lists.slony.info/adminguide/1.2/ … index.html en anglais).
Et bon courage
PS : c'est pas forcément simple mais ça en vaut le coup.
Guillaume.
Hors ligne
Pages : 1
