> 1- la réplication via log shipping qui n'est pas intégré (nécessité de scripts externes). Ceci dit, elle est par contre beaucoup plus stable que la réplication MySQL par log shipping ;
(disclaimer, je parle en tant qu'admin, pas développeur).
AMHA la réplication est effectivement un gros point faible de PostgreSQL. Et il est clair que la roadmap de 8.4 montre que les développeurs prennent les choses en main et ne jouent pas à l'autruche (c'est toujours la différence avec les fanboys ;).
Qu'elle ne soit pas intégrée dans les sources standards de PostgreSQL n'est vraiment pas le problème cependant. Outre le cout (en ressources et en entretien) des outils de réplication basés sur des triggers (autant dire, du bricolage) à la Slony ou Londiste, l'aspect bizantin de la mise en œuvre, il faut bien dire que les fonctionnalités sur ce point sont vraiment à la traine, et c'est vraiment un show stopper pour certains utilisations. Quelques exemples de ce que MySQL fait, que j'adorerai voir dans PG rapidement (et explication des cas d'utilisation) :
* La réplication master-master (avec garantie d'autoincrements, pour les pk, uniques par noeud) : fort utile our une architecture HA qui permette un "scale out" (qui permet d'augmenter les performances et la disponibilité en ajoutant des serveurs "moyens" plutôt qu'en étant bloqué sur un seul serveur maitre très puissant). À mon avis ceci (avec les possibilité de sharding) est une des raisons de l'utilisation fréquente de MySQL pour des applications web à forte croissance. Dans le web, où l'argent arrive souvent au compte goutte au fur et à mesure du succès, et où l'utilisation peut grossir très soudainement, pouvoir augmenter les capacités au fur et à mesure des besoins avec des machines bon marché est critique (à l'opposé par ex. d'un système bancaire dimensionné selon les besoins dès le départ).
* La réplication délayée : où les slaves récupèrent bien les mises à jour sur le master, mais ne les appliquent aux bases qu'après un délai définis par l'utilisateur. Si une application bugguée, une erreur de manipulation de maintenance, un piratage, etc. venait à corrompre les données sur la base master, il suffit de switcher les applicatifs sur un slave et de demander à celui-ci d'appliquer illico les mises à jour en attende jusqu'à celle qui a causé des pertes. D'une certaine manière, c'est une assurance contre la perte des données à cause humaine. Pour certaines applications (en tout cas chez moi), perdre toutes les données modifiées depuis le dernier snapshot/backup (quotidien, dans mon cas, car mes bases sont très grosses) c'est mettre la clef sous la porte.
* Et toutes ces petites choses qui simplifient la vie, qui manquent à pg, et sont certainement dues au fait que la réplication est native de longue date : le support du SSL (y compris de l'auth des slaves par certificat X.509), la possibilité d'initialiser la réplic sur un slave à partir de l'import d'un dump (si dumpé avec l'option "--master-data"), la possiblité de faire du daisy-chaining (replication A -> B -> C -> A), la simplicité et rapidité de mise en place, le fait qu'on puisse demander de répliquer toutes les bases (ou bien une base complète) et que les ajouts/drops/changements de tables soient naturellement répliqués sans qu'on intervienne, ...
Je ne l'ai pas encore essayé, mais il y a désormais (5.1) un mode de réplication mixte (statements et row based) qui permet à MySQL de décider ce qui sera optimal niveau perfs et bp (la réplication par statements oblige parfois mysqld à joindre des infos complémentaires en commentaires dans les binlogs répliqués pour que les slaves puissent appliquer ces statements de façon identique (ie. résultats des fonctions comme NOW(), RAND(), etc.)).
Un autre choix pertinent de MySQL (important dans certains cas) est l'utilisation, pour les bases InnoDB d'un cache des rows en RAM. Le cache disque généraliste du noyau est *beaucoup* moins efficace (parce qu'il est aveugle et met en cache des choses qui ne nous intéresseront pas, parce qu'il n'est pas très déterministe et peu se vider d'un moment à l'autre, parce qu'y accéder oblige à construire et scheduler une requète block complète,...). Les performances en lecture s'en trouvent considérablement améliorées.
Il y a en revanche des choses que je deteste dans MySQL, *en tant qu'admin*, comme le fait que les alter sont appliqués immédiatement (transaction ou pas, le rollback ne rendra pas l'état initial). Les tablespaces assez peu pratiques par rapport à PostgreSQL, du moins lorsqu'on veux distribuer la charge sur plusieurs arrays (et MySQL ne permet pas de déplacer physiquement une table à chaud, c'est souvent handicapant pour moi), le fait que les performances de MySQL ne progressent plus au-delà de 8 cpus, ...
[^] # Re: haha
Posté par herodiade . En réponse à la dépêche La version 5.1 de MySQL est-elle bourrée de bugs ?. Évalué à 6.
(disclaimer, je parle en tant qu'admin, pas développeur).
AMHA la réplication est effectivement un gros point faible de PostgreSQL. Et il est clair que la roadmap de 8.4 montre que les développeurs prennent les choses en main et ne jouent pas à l'autruche (c'est toujours la différence avec les fanboys ;).
Qu'elle ne soit pas intégrée dans les sources standards de PostgreSQL n'est vraiment pas le problème cependant. Outre le cout (en ressources et en entretien) des outils de réplication basés sur des triggers (autant dire, du bricolage) à la Slony ou Londiste, l'aspect bizantin de la mise en œuvre, il faut bien dire que les fonctionnalités sur ce point sont vraiment à la traine, et c'est vraiment un show stopper pour certains utilisations. Quelques exemples de ce que MySQL fait, que j'adorerai voir dans PG rapidement (et explication des cas d'utilisation) :
* La réplication master-master (avec garantie d'autoincrements, pour les pk, uniques par noeud) : fort utile our une architecture HA qui permette un "scale out" (qui permet d'augmenter les performances et la disponibilité en ajoutant des serveurs "moyens" plutôt qu'en étant bloqué sur un seul serveur maitre très puissant). À mon avis ceci (avec les possibilité de sharding) est une des raisons de l'utilisation fréquente de MySQL pour des applications web à forte croissance. Dans le web, où l'argent arrive souvent au compte goutte au fur et à mesure du succès, et où l'utilisation peut grossir très soudainement, pouvoir augmenter les capacités au fur et à mesure des besoins avec des machines bon marché est critique (à l'opposé par ex. d'un système bancaire dimensionné selon les besoins dès le départ).
* La réplication délayée : où les slaves récupèrent bien les mises à jour sur le master, mais ne les appliquent aux bases qu'après un délai définis par l'utilisateur. Si une application bugguée, une erreur de manipulation de maintenance, un piratage, etc. venait à corrompre les données sur la base master, il suffit de switcher les applicatifs sur un slave et de demander à celui-ci d'appliquer illico les mises à jour en attende jusqu'à celle qui a causé des pertes. D'une certaine manière, c'est une assurance contre la perte des données à cause humaine. Pour certaines applications (en tout cas chez moi), perdre toutes les données modifiées depuis le dernier snapshot/backup (quotidien, dans mon cas, car mes bases sont très grosses) c'est mettre la clef sous la porte.
* Et toutes ces petites choses qui simplifient la vie, qui manquent à pg, et sont certainement dues au fait que la réplication est native de longue date : le support du SSL (y compris de l'auth des slaves par certificat X.509), la possibilité d'initialiser la réplic sur un slave à partir de l'import d'un dump (si dumpé avec l'option "--master-data"), la possiblité de faire du daisy-chaining (replication A -> B -> C -> A), la simplicité et rapidité de mise en place, le fait qu'on puisse demander de répliquer toutes les bases (ou bien une base complète) et que les ajouts/drops/changements de tables soient naturellement répliqués sans qu'on intervienne, ...
Je ne l'ai pas encore essayé, mais il y a désormais (5.1) un mode de réplication mixte (statements et row based) qui permet à MySQL de décider ce qui sera optimal niveau perfs et bp (la réplication par statements oblige parfois mysqld à joindre des infos complémentaires en commentaires dans les binlogs répliqués pour que les slaves puissent appliquer ces statements de façon identique (ie. résultats des fonctions comme NOW(), RAND(), etc.)).
Un autre choix pertinent de MySQL (important dans certains cas) est l'utilisation, pour les bases InnoDB d'un cache des rows en RAM. Le cache disque généraliste du noyau est *beaucoup* moins efficace (parce qu'il est aveugle et met en cache des choses qui ne nous intéresseront pas, parce qu'il n'est pas très déterministe et peu se vider d'un moment à l'autre, parce qu'y accéder oblige à construire et scheduler une requète block complète,...). Les performances en lecture s'en trouvent considérablement améliorées.
Il y a en revanche des choses que je deteste dans MySQL, *en tant qu'admin*, comme le fait que les alter sont appliqués immédiatement (transaction ou pas, le rollback ne rendra pas l'état initial). Les tablespaces assez peu pratiques par rapport à PostgreSQL, du moins lorsqu'on veux distribuer la charge sur plusieurs arrays (et MySQL ne permet pas de déplacer physiquement une table à chaud, c'est souvent handicapant pour moi), le fait que les performances de MySQL ne progressent plus au-delà de 8 cpus, ...