Vous n'êtes pas identifié(e).
Bonjour
Existe-t-il un moyen "simple" mais efficace de synchroniser deux bases distante ?
Hors ligne
Quel sens mettez-vous à « synchroniser » ? si c'est répliquer, il existe plusieurs solutions plus ou moins simples (LogShipping très simple mais pas prévu pour une seule base, ce sera toute l'instance ; Slony plus complexe, mais permet de répliquer à un niveau beaucoup plus fin, etc.)
Guillaume.
Hors ligne
L'idée est que si un enregistrement change dans une table d'une des deux base, est de reproduire la modification dans l'autre base le plus rapidement possible.
Hors ligne
Le mieux dans ce cas est d'utiliser Slony. Mais je ne suis pas sûr que ça réponde au critère « simple » dont vous parliez auparavant. Par contre, ça a beaucoup d'avantages (comme celui que, en cas de coupures réseau ou d'arrêt de l'esclave, la réplication reprend dès que le maître voit de nouveau l'esclave).
Guillaume.
Hors ligne
Merci je vais chercher dans cette voie
Hors ligne
Bonsoir,
vous pouvez aussi regarder du côté de londiste, même principe que slony mais peut-être plus facile à mettre en oeuvre:
https://developer.skype.com/SkypeGarage … ee67b0cbe3
http://pgsql.tapoueh.org/site/html/lond … diste.html
Hors ligne
Merci
Hors ligne
Oui! Luddic a bien raison...
Par contre quand je lis "si un enregistrement change dans une table d'une des deux base, est de reproduire la modification dans l'autre base" j'ai l'impression que vous cherchez un système de réplication multi-maître. Je me trompe ou pas?
Jean-Paul Argudo
https://www.postgresql.fr
https://www.crunchydata.com
Hors ligne
Bonjour
C'est exactement cela
Hors ligne
BONJOUR
Dans une fonction trigger existe-t-il une variable system qui contiendrai l'ordre sql, COMPLET, executé ?
Dernière modification par philippe.pasquali (07/10/2008 12:13:03)
Hors ligne
Non, ça n'existe pas.
PS : pensez à créer un nouveau thread quand vous posez une autre question.
Guillaume.
Hors ligne
Bonjour
C'est exactement cela
Bonjour,
Dans ce cas, Slony et londiste ne vont pas vous satisfaire. Il vous faut regarder du côté d'autres outils (pgcluster ou pgpool-II, sequoia...).
Attention toutefois, ces outils procèdent le plus souvent par propagation de la requête SQL qui modifie les données et non de la valeur modifiée des lignes. De ce fait, toute requête non déterministe conduit à des différences dans les données entre les serveurs.
(Ex : Select now(), exécuté sur les différents serveurs de la réplication ne conduira jamais à une valeur identique).
Stéphane Schildknecht
Conseil, formations et support PostgreSQL
http://www.loxodata.com
Hors ligne
Attention toutefois, ces outils procèdent le plus souvent par propagation de la requête SQL qui modifie les données et non de la valeur modifiée des lignes. De ce fait, toute requête non déterministe conduit à des différences dans les données entre les serveurs.
(Ex : Select now(), exécuté sur les différents serveurs de la réplication ne conduira jamais à une valeur identique).
Dans ce cas, quelle serait la solution efficace pour faire un "vrai" cluster PG, insensible au non-déterminisme d'une requête ?
Hors ligne
Qu'appelez-vous "vrai" cluster PostgreSQL ?
Avec Slony, vous avez un vrai cluster Slony, mais il y a un maître et plusieurs esclaves.
Stéphane Schildknecht
Conseil, formations et support PostgreSQL
http://www.loxodata.com
Hors ligne
Bucardo est une solution de réplication Master-Master. C'est très limité mais si vous n'avez que 2 noeuds dans votre cluster c'est une piste intéressante.
damien clochard
http://dalibo.org | http://dalibo.com
Hors ligne
bonjour a tous,
Quand on parle de replication maitre / esclave. est-ce l'esclave est contactabl.
Mon projet et de mettre une copie de la base de donnée pouvant servir de datamart (sollicitation pour des statistiques) sans engirger le serveur de prod.
Apparemment en log shipping, on ne peut pas se conntecter au serveur esclave.
Alors quelle solution ?
Hors ligne
Quand on parle de replication maitre / esclave. est-ce l'esclave est contactabl.
Oui.
Apparemment en log shipping, on ne peut pas se conntecter au serveur esclave.
En effet, ce n'est pas encore possible. Cela devrait le devenir en 8.4 ou en 8.5.
Alors quelle solution ?
Slony qui est l'outil de la communauté ou Londiste, l'outil de Skype. Les deux font du 1 maître/plusieurs esclaves, avec des esclaves accessibles en lecture seule. Dans ton cadre, l'un comme l'autre peuvent convenir.
Guillaume.
Hors ligne
Moi ça m'intéresse d'avoir une copie locale(sur mon PC) de ma base de données de développement située dans un serveur du réseau local.
Mon objectif est de pouvoir travailler dessus lorsque je suis à l'extérieur.
Pour donner un bon exemple, je veux que ça soit géré comme un SVN pour la gestion des versions des projets ==> Je veux pouvoir faire des mises à jour de la structure de la base dans les deux sens.
Que me conseillez vous?
Hors ligne
SVN et un schéma exporté avec un « pg_dump -s ». Mais la synchro entre la base de dév et celle de prod sera évidemment manuelle.
Guillaume.
Hors ligne
Je vois que je ne suis pas le seul à m'intéresser à ces problèmes de réplication.
Je m'associe à Zied en trouvant que les outils de réplication sous PostgreSQL restent relativement mal intégrés (configuration "lourde", maintenance rendue pénible à cause de la non synchronisation des schémas,...) et, de mon point de vue, "risquées".
Ce que j'entends par là, c'est qu'on peut mettre en place une réplication qui va fonctionner de façon fiable et performante à un instant t, mais qui pourra être "cassée" par inadvertance, parce que quelqu'un aura modifié un schéma sans penser à
1) modifier les esclaves et
2) ajouter/modifier la règle de synchronisation.
De ce point de vue, il faut bien reconnaitre que "l'autre base libre" a une approche mieux intégrée de point de vue de l'utilisateur.
Hors ligne
Si "l'autre base libre" est MySQL, il me semble avoir entendu dire, sans tomber dans le FUD, qu'elle était bien buggée et que c'était au moins une des raisons du départ d'un développeur particulièrement important.
Je préfère une réplication non buggée et pour laquelle je connais les limitations.
Guillaume.
Hors ligne
Comme je ne fais pas de FUD, je me suis mis à chercher les messages en question. Voir donc la news sur linuxfr (http://linuxfr.org/2008/11/30/24743.html) et le billet du blog du créateur de MySQL, Michael Widenius (http://monty-says.blogspot.com/2008/11/ … eased.html).
Donc je maintiens ce que j'ai dis.
Guillaume.
Hors ligne
Je pensais effectivement à MySQL, mais le but n'était pas de polémiquer. Je pense que si les lecteurs de ce forum pensaient que MySQL était meilleur que PostgreSQL, ils seraient plutôt sur un forum dédié à ce SBGD...
Non, par contre, je continue à penser qu'un système de "cluster" au sens où on l'entend traditionnellement (plusieurs machines physiques participant à un seul système logique) reste plus souple pour l'usager que des systèmes de réplications tiers, donc moins intégrés.
Je vais changer d'exemple, afin de ne pas être accusé de troll, mais c'est aussi ce que propose par exemple Oracle avec RAC.
Quelque part, un système de réplication maitre/maitre offre fonctionnellement une approche assez voisine à celle d'un cluster, avec potentiellement certains avantages supplémentaires (possibilité de déconnexion temporaire d'un noeud,...). C'est pourquoi, me semble-t-il, nous sommes plusieurs à nous intéresser à ce sujet.
En ce qui concerne la réplication maitre/esclaves, sur beaucoup d'applications qui réalisent plus de lectures que de modifications, c'est là encore une réponse qui peut être satisfaisante, à condition que les esclaves soient accessibles en lecture. D'ailleurs, je pense que si la "core-team" PostgreSQL cherche à améliorer son actuelle réplication par log-shipping, c'est probablement que leur point de vue n'est pas si éloigné que ça du mien ;-)
Par contre, ce que je regrette dans les systèmes de réplication maitre/esclave, c'est que s'il est généralement assez simple de promouvoir un esclave en tant que nouveau maitre (par exemple en cas de nécessité d'arrêt du maitre pour maintenance), resynchroniser a postériori un serveur pour le "re-promouvoir" maitre n'est pas toujours chose aisée.
J'avais fait des essais avec Slony il y a déjà longtemps. Les choses ont sans doute évolué, et mes moyens sont sans doute limités, mais c'est bien l'impression que cela m'avait laissé: réplication relativement simple à mettre en oeuvre, fail-over quasi-automatique, mais une base difficile à faire ensuite évoluer (nécessité de manuellement modifier le schéma sur tous les noeuds, modifier systématiquement les règles de Slony pour prendre en compte les modifs,...) et une gestion lourde pour re-promouvoir un noeud en tant que maitre après un fail-over.
Enfin, une question un peu naïve. Les systèmes de réplication ont basiquement (c'est très réducteur, je sais !) pour mission de "rejouer" les modifications apportées à une base vers une ou plusieurs autre(s) base(s). Or, sous PostgreSQL, la description de la base est elle-même accessible via le schéma spécifique information_schema (c'est, je trouve, un atout pour PostgreSQL). Pourquoi ne peut-t-on pas mettre les systèmes actuels de réplication à l'écoute de ce schéma particulier ?
En espérant avoir éteint l'incendie que je ne voulais pas allumer,
Cordialement,
Jérôme
Hors ligne
Je vais laisser Guillaume répondre sur le reste.
Mais en tant que 'spécialiste' RAC (j'ai la 'joie' d'en gérer en production), je voulais simplement signaler que ce n'est pas du tout une techno de réplication, ni réellement de haute dispo, mais une techno de répartition de charge.
La partie haute dispo (bascule des service d'un noeud vers un autre) peut être fournie par clusterware d'oracle, qui est sur le 'cd' rac, mais aussi par la techno de clustering de l'OS (HACMP par exemple sur AIX). C'est donc bien une techno 'externe' à RAC. On s'en rend d'ailleurs bien compte quand on administre l'ensemble…
La partie réplication est quand à elle fournie soit par le SAN (réplication inter baie), mais ça rend la bascule compliquée, soit par du mirroring ASM. Encore un composant qui ne fait que partiellement partie de RAC, puisqu'il s'agit à peu de chose près d'un système de fichiers. Et qu'on peut si on est un peu maso l'utiliser sans RAC 
La techno de réplication d'Oracle, c'est dataguard. Et c'est une option de la version enterprise, qui est souvent d'ailleurs couplée à RAC pour avoir une archi réellement haute dispo. Si on a les moyens évidemment
Un dernier point: RAC n'est pas magique : sur le papier c'est très beau, mais une application doit être RAC-Able (il y a des contraintes assez fortes en termes de développement, comme ne pas avoir de hot-blocks dans la base par exemple), et RAC scale assez mal au dessus de 3 noeuds (évidemment, tu ne trouveras pas ça sur des slides Oracle… )
Marc.
Hors ligne
Je vois que la discussion dérive d'un moment à l'autre vers une disscussion sur les SGBD autre que Postgres.
C'est certes intéressant mais ce n'est pas le cœur de cette discussion.
Il faut reconnaitre que Postgresql ne possède pas un outil de réplication assez pointu. C'est un point faible qui vient s'ajouter à la pauvreté des outils "graphiques" de gestion du SGBD en général.
Si quelqu'un possède du poids 
pour attirer l'intérêt de l'équipe de développement de PG sur ces gros sujets, je pense que "l'Histoire lui sera reconnaissante d'avoir défendu une BONNE CAUSE en faveur des utilisateurs et des développeurs sous PG."
looool
Dernière modification par zied (28/10/2009 13:59:50)
Hors ligne
