Vous n'êtes pas identifié(e).
Pages : 1
Hello,
Je voudrais savoir si l'on a des informations sur comment se présentera la réplication qui a la base été prévu pour la 8.4 mais retardé a la 8.5 ?
Sera t-elle aussi simple a utiliser que la réplication de Mysql par exemple ? (Qui est tout simplement génial je doit dire.... Un des seuls avantages de Mysql)
Ou sera t-on encore avec des réplications complexe, totalement détaché de postgresql et non accessible aux novice (Style l'actuelle via scp ou slony) ?
Merci 
Hors ligne
scp comme méthode de réplication ? c'est une blague ? ou alors tu parles du log shipping ? mais dans ce cas, j'ai du mal à voir en quoi c'est totalement détaché de PostgreSQL (vu que c'est intégré). Par contre, je suis d'accord que Slony n'est pas simple à mettre en place.
Concernant la réplication en 8.5, il faut bien voir qu'il y a deux patchs prévus.
Le premier, HotStandby, va permettre d'utiliser l'esclave. Cela se configure exactement comme le LogShipping (aussi appelé WarmStandby) aujourd'hui, vu que ce n'est qu'une amélioration de ce dernier.
Le second est SyncRep. Son but est de permettre une réplication beaucoup plus fine que le LogShipping. Au lieu d'attendre qu'un journal de transactions soit complètement rempli, un nouveau processus, walsender, va envoyer le résultat transaction par transaction sur le serveur en attente. Du coup, on a une réplication à la transaction prêt. La configuration demandera d'indiquer au serveur esclave qui est le maître pour que le dialogue entre les deux puisse se faire.
Tu trouveras plus de détails sur http://wiki.postgresql.org/wiki/Hot_Standby et http://wiki.postgresql.org/wiki/NTT%27s … t_Projects.
Tu as un lien expliquant la réplication façon MySQL ? que je puisse me faire une idée, vu que je ne connais pas.
Guillaume.
Hors ligne
oui je parle du log shipping, qui utilise scp pour copier les logs binaires, donc c'est quand meme externe a postgresql je trouve, postgresql n'a pas vraiment de controle la dessus, a aucun moment le master peut connaitre le status du slave par exemple comme l'on pourrait le faire dans mysql avec "SHOW PROCESSLIST" ( par exemple: Has sent all binlog to slave; waiting for binlog to be updated ), on a pas non plus autant d'informations sur le slave, par exemple le slave ne connais pas l'adresse du master ou d'autres informations utiles (SHOW SLAVE STATUS), et a la moindre coupure du master, il faut recopier toute la base de donnée il me semble... bref c'est vraiment bidouille bidouille je trouve par apport a Mysql
la réplication est expliqué ici :
http://dev.mysql.com/doc/refman/5.0/fr/replication.html (version plus vielle en français)
http://dev.mysql.com/doc/refman/5.1/en/ … tions.html (version plus récente en anglais)
bref j'ai l'impression qu'on verra jamais une réplication aussi bien foutu que sur mysql, et c'est vraiment dommage, car pour moi c'est LE truc qui me bloque sur Postgresql (même si pour le moment je n'ai pas encore besoin d'utiliser la réplication) 
Dernière modification par kedare (11/06/2009 23:11:51)
Hors ligne
oui je parle du log shipping, qui utilise scp pour copier les logs binaires, donc c'est quand meme externe a postgresql je trouve, postgresql n'a pas vraiment de controle la dessus,
Je comprend pas cette phrase. PostgreSQL n'a pas n'ont plus le controle sur la pile TCP/IP et sur le driver de la carte ethernet 
C'est pareil pour MySQL. La différence c'est que MySQL te cache cette complexité et ne te laisse pas le choix.
a aucun moment le master peut connaitre le status du slave par exemple comme l'on pourrait le faire dans mysql avec "SHOW PROCESSLIST" ( par exemple: Has sent all binlog to slave; waiting for binlog to be updated ),
C'est faux. Il est possible avec la Warm Standby de savoir précisément quel est le dernier journal de transcation envoyé et déduire si l'esclave est désynchronisé. C'est plus rustique que ce que tu décris mais ça sera amélioré avec le Hot Standby
on a pas non plus autant d'informations sur le slave, par exemple le slave ne connais pas l'adresse du master ou d'autres informations utiles (SHOW SLAVE STATUS),
Regarde du coté de walmanager, un projet développé par Skype.
et a la moindre coupure du master, il faut recopier toute la base de donnée il me semble...
Là encore c'est faux :-) Le seul cas ou tu dois reconstuire entièrement ta base c'est lorsque master a subit un crash et que tu demandes à l'esclave de prendre le relai. En gros une fois que tu as transformé l'esclave en maitre, tu ne peux plus le retransformer en esclave. ça s'appelle le FAIL BACK, je suis pas certain que MySQL soit capable de le faire non plus.
bref c'est vraiment bidouille bidouille je trouve par apport a Mysql
Je vois déjà le troll arriver. En terme de bidouillage, je suis pas sur que le projet MySQL ait des leçons à donner :-)
Pour donner juste deux exemples :
* Il y a des bugs connus depuis MySQL 5.0 qui n'ont pas été corrigés dans la 5.1. C'est le fondateur de MySQL qui le dit : http://monty-says.blogspot.com/2008/11/ … eased.html
* La doc de la 5.1 n'est pas traduite en français. Je trouve ça relativement décevant pour un projet qui a le prétention d'être le SGBD le plus populaire.
bref j'ai l'impression qu'on verra jamais une réplication aussi bien foutu que sur mysql, et c'est vraiment dommage, car pour moi c'est LE truc qui me bloque sur Postgresql (même si pour le moment je n'ai pas encore besoin d'utiliser la réplication)
Attention à ne pas tout mélanger. Derrière le mot "réplication" on peut mettre énormément de concepts différents : Haute-disponibité ou répartition de charge, réplication synchrone ou asynchrone, symétrique ou asymétrique.
En l'occurence, le Warm Standby est une technique simple pour mettre en place un serveur de secours et garantir une reprise rapide en cas de panne. Cela n'a pas d'autre prétention. Le Hot Standby apportera des avancées intéressantes ( synchronicité, esclave accessible en lecture) et dans ce cas là les noeuds auront "conscience" de la présence des autres noeuds mais cela restera une solution limitée sur certains aspects, le fail back et la granularité notamment.
Pour avoir, plus de finesse il faut se tourner vers des outils externes (Slony, bucardo) qui ajoutent de la complexité.
Il me parait également important de préciser quel moteur on utilise avec MySQL : les différences entre MyISAM et InnoDB ne sont pas anodines. Par exemple, je serais curieux de connaitre les perfs d'un cluster de réplication avec MYSQL/InnoDB
damien clochard
http://dalibo.org | http://dalibo.com
Hors ligne
Aux dernières nouvelles, la réplication Mysql, c'est de la réplication par ordres SQL :
- Statement based replication (on envoie les ordres SQL de l'autre côté). Cette solution a le défaut que des appels de fonctions dépendantes du contexte (comme l'heure) peuvent entrainer des différences sur la base esclave (c'est peut être corrigé depuis le temps mais je ne crois pas)
- row based replication (on envoie des ordres enreg par enreg pour exécuter l'équivalent des modifs de la base de prod sur la base de backup). elle a le défaut, à la place, d'être lente, si par exemple on veut répliquer un delete d'un million d'enreg
C'est pour cela que maintenant mysql a un mode mixte. Son défaut à lui ? il est plein de bugs. C'est d'ailleurs un des trucs pleins de bugs qui ont fait parler de lui à la sortie de la 5.1.
Le but n'est pas de troller. Le point fort de mysql, c'est que cette réplication est bien intégrée. Le défaut, c'est que la partie 'basse', c'est à dire ce qui génère la réplication, est assez fragile, et encore buggué malgré le temps qu'ils ont déjà passé à le développer.
De son côté, PostgreSQL a une réplication un peu plus manuelle (encore qu'avec les skytools, ca devient assez raisonnable), mais extrêmement fiable (elle utilise le mécanisme de journalisation de la base, qui existe depuis très longtemps et est la garantie, déjà en temps normal, de la fiabilité de la base). La surcouche 'réplication facile' va venir, on espère tous en 8.5. Mais sur des fondations solides, alors que mysql a choisi l'approche inverse : d'abord une interface facile, et ensuite essayer de rendre le mécanisme solide.
Marc.
Hors ligne
J'avais bien vu la réplication par envoi des instructions SQL mais je n'osais pas croire que c'était ce que kedare appelait génial. S'il n'y a que ça pour lui faire plaisir, pgpool sait le faire, mais avec les limitations qu'on connaît (à savoir que les fonctions style now() ou random() donneront pratiquement à coup sûr des valeurs différentes sur le maître et sur l'esclave).
Guillaume.
Hors ligne
C'est à cela que sert le mode mixte : quand tu as des now, random & co, il génère des ordres en mode 'row based replication', si j'ai bien compris. Donc on a le 'moins pire' des deux mondes. Quand ça marche...
Juste pour le plaisir :
http://dev.mysql.com/doc/refman/5.4/en/open-bugs.html
Quand la réplication ne marche pas, autant dire que c'est la faute du développeur qui fait des requêtes "ne respectant pas les bonnes pratiques".
Bon, d'un autre côté, je ne l'ai pas utilisé depuis longtemps, vu qu'une réplication qui 'pourrait ne pas marcher', c'est le genre de choses qui ne m'encourage pas à m'en servir, même si c'est dans des cas très particuliers. Les développeurs sont quelquefois suffisamment inventifs...
Dernière modification par Marc Cousin (12/06/2009 10:25:47)
Marc.
Hors ligne
Pages : 1
