"Qu'elle ne soit pas intégrée dans les sources standards de PostgreSQL n'est vraiment pas le problème cependant."
C'en est un, en fait. Il faut vraiment que ça marche out of the box sans avoir à scripter des trucs (même si plusieurs scripts existent mais c'est déjà un problème en soi : lequel choisir).
Ca ne pose pas de souci aux gens qui ont l'habitude mais ça rend cette fonctionnalité peu accessible alors qu'elle est simplissime et très robuste.
"La réplication master-master"
Mouaif. La réplication master-master pose énormément de problèmes en soi et MySQL n'est vraiment vraiment pas un modèle du genre... Clairement, il ne faut pas espérer voir arriver ça dans PostgreSQL avant très très longtemps (si ça arrive un jour).
Au delà de la fiabilité, le moteur NDB induit tout un tas de limitations que je trouve inacceptable.
"La réplication délayée"
Mauvaise réponse au problème. Tu tomberas toujours dans le cas où, pas de bol, ton délai n'était pas suffisant. PostgreSQL répond à ce problème avec le Point In Time Recovery : tu indiques simplement le moment où tu veux t'arrêter dans le "rejouage" des logs. C'est *beaucoup* plus fiable.
"les ajouts/drops/changements de tables soient naturellement répliqués sans qu'on intervienne"
C'est déjà le cas dans la réplication via log shipping. Evidemment le fait que le slave ne soit pas accessible en lecture pour l'instant le limite au failover. J'espère que cette limitation sera levée en 8.4.
Slony n'est clairement pas un modèle du genre de simplicité et il est, à mon sens, assez difficile à imposer en dehors du cadre de sa propre boîte (typiquement, je ne le propose pas au client dont on exploite les plates-formes).
Personnellement, je vois pas mal d'admins MySQL se plaindre de l'instabilité de la réplication via log shipping.
Clairement, un hot standby est suffisant pour 99% des besoins et je préfère très largement avoir un failover très fiable qu'un truc bancal qui me permet de faire du readonly sur un autre noeud. Note bien que je suis d'accord que c'est limitant pour certains besoins, juste que je préfère des fondations solides, ça se casse moins souvent la gueule :).
Pour l'histoire du cache disque, c'est l'argument qu'on entend souvent. Je dois avouer qu'on voit assez peu de cas où ça pose réellement un problème. Clairement, PostgreSQL se focalise sur faire du SGBDR, pas sur faire un OS au dessus de l'OS. Ca a parfois un coût, tout le monde en convient, mais c'est finalement assez sain.
Sinon, tu es gentil sur le "les performances de MySQL ne progressent plus au-delà de 8 cpus", j'ai vu plus de benchs où ça s'écroulait dès que le nombre de CPU et le nombre de connexions augmentaient et je vois encore souvent des bases en production en 5.0 qui n'utilisent qu'un core sur 4 malgré une configuration correcte. Le fait de ne pas avoir sorti de version en 3 ans (et donc de ne pas avoir pu s'adapter à la nouvelle mode des multi-cores) joue sans doute un peu là-dessus.
[^] # Re: haha
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche La version 5.1 de MySQL est-elle bourrée de bugs ?. Évalué à 7.
C'en est un, en fait. Il faut vraiment que ça marche out of the box sans avoir à scripter des trucs (même si plusieurs scripts existent mais c'est déjà un problème en soi : lequel choisir).
Ca ne pose pas de souci aux gens qui ont l'habitude mais ça rend cette fonctionnalité peu accessible alors qu'elle est simplissime et très robuste.
"La réplication master-master"
Mouaif. La réplication master-master pose énormément de problèmes en soi et MySQL n'est vraiment vraiment pas un modèle du genre... Clairement, il ne faut pas espérer voir arriver ça dans PostgreSQL avant très très longtemps (si ça arrive un jour).
Au delà de la fiabilité, le moteur NDB induit tout un tas de limitations que je trouve inacceptable.
"La réplication délayée"
Mauvaise réponse au problème. Tu tomberas toujours dans le cas où, pas de bol, ton délai n'était pas suffisant. PostgreSQL répond à ce problème avec le Point In Time Recovery : tu indiques simplement le moment où tu veux t'arrêter dans le "rejouage" des logs. C'est *beaucoup* plus fiable.
"les ajouts/drops/changements de tables soient naturellement répliqués sans qu'on intervienne"
C'est déjà le cas dans la réplication via log shipping. Evidemment le fait que le slave ne soit pas accessible en lecture pour l'instant le limite au failover. J'espère que cette limitation sera levée en 8.4.
Slony n'est clairement pas un modèle du genre de simplicité et il est, à mon sens, assez difficile à imposer en dehors du cadre de sa propre boîte (typiquement, je ne le propose pas au client dont on exploite les plates-formes).
Personnellement, je vois pas mal d'admins MySQL se plaindre de l'instabilité de la réplication via log shipping.
Clairement, un hot standby est suffisant pour 99% des besoins et je préfère très largement avoir un failover très fiable qu'un truc bancal qui me permet de faire du readonly sur un autre noeud. Note bien que je suis d'accord que c'est limitant pour certains besoins, juste que je préfère des fondations solides, ça se casse moins souvent la gueule :).
Pour l'histoire du cache disque, c'est l'argument qu'on entend souvent. Je dois avouer qu'on voit assez peu de cas où ça pose réellement un problème. Clairement, PostgreSQL se focalise sur faire du SGBDR, pas sur faire un OS au dessus de l'OS. Ca a parfois un coût, tout le monde en convient, mais c'est finalement assez sain.
Sinon, tu es gentil sur le "les performances de MySQL ne progressent plus au-delà de 8 cpus", j'ai vu plus de benchs où ça s'écroulait dès que le nombre de CPU et le nombre de connexions augmentaient et je vois encore souvent des bases en production en 5.0 qui n'utilisent qu'un core sur 4 malgré une configuration correcte. Le fait de ne pas avoir sorti de version en 3 ans (et donc de ne pas avoir pu s'adapter à la nouvelle mode des multi-cores) joue sans doute un peu là-dessus.