> 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).
Enfin, ceux qui n'ont pas l'envie ou le temps de s'occuper d'installer Slony peuvent toujours utiliser les paquets de leur distribution. Je préfère une implémentation native (plutôt parce que c'est l'assurance que ce composant suit le même processus de rewieving/qualité/release que le reste), mais c'est quand même un détail secondaire.
A moins que tu ne parle des scripts qu'on doit se bricoler pour ajouter les sets et les séquences au fur et à mesure que la structure de la / des base change ? (mais dans ce cas il s'agit plutôt d'un problème de configuration et d'"interface utilisateur" que d'intégration dans pg non ?).
> Mouaif. La réplication master-master pose énormément de problèmes
> [...] Au delà de la fiabilité, le moteur NDB induit tout un tas de limitations que je trouve inacceptable.
Je crois que tu confonds. La réplication master-master c'est une réplication traditionnelle (mais configurée dans les deux sens), utilisant le moteur de son choix (enfin, InnoDB quoi), et une ou deux petites fonctionnalités aidant les applications à éviter les conflits, et ça marche bien.
NDB c'est le moteur imposé pour "MySQL Cluster", tout autre chose. MySQL Cluster est un truc très limité, avec un nom designé pour le marketing, et exploitable pour des cas d'utilisation à mon avis franchement peut courants (et inadéquat pour le reste).
> PostgreSQL répond à ce problème avec le Point In Time Recovery
C'est une bonne fonctionnalité, mais ce n'est pas la réponse au problème.
Si tu n'a pas les WAL depuis les tout débuts de ta base (bonjour le volume), tu dois tomber un backup puis repérer jusqu'où tu applique tes logs, ce qui prendra un temps infernal (s'il s'agit d'un pg_dump, c'est très long, s'il s'agit d'un snapshot filesystem, il faut attendre que les DLT te tombent tes 400 Go de bases ...) (on parle de reprise de prod là). En outre, la méthode dont je parle permet de réellement voir les statements SQL en queue, et en quelques secondes repérer le fautif et demander au sgbd d'avancer jusqu'au précédent (ou de tout appliquer, y compris les suivants, sauf le fautif).
> Personnellement, je vois pas mal d'admins MySQL se plaindre de l'instabilité de la réplication via log shipping.
Sérieux, c'est une blague ? Je veux bien reconnaître les mérites et avantages de PostgreSQL, et ils sont nombreux, mais il ne faut pas déconner non plus : la réplication chez MySQL est native depuis au moins la version 4.0 (il y a très longtemps quoi), et c'est bien une des choses que MySQL a fini par gérer de façon correcte, simple et pratique (et qui évolue, la nouvelle replic mixte étant censée permettre d'avoir des slaves sur des machines bien moins puissantes en théorie (j'ai pas essayé cela dit)).
>> "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
Pas seulement le failover, ça limite diablement l'utilité qu'on peut tirer du slave, en toute franchise ;). J'ai cru comprendre que problème serait réglé *après* que le support pour la réplication "row based" serait intégrée, soit peut être dans 8.4, plus probablement post-8.4, quelqu'un à des nouvelles ?
> 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.
Il n'y a rien de spécial à « voir ». C'est juste que les selects sont beaucoup plus lents qu'ils pourraient l'être parce que les ressources disponibles ne sont pas exploitées de façon optimale.
Cela dit c'est vrai que dans beaucoup de cas, c'est l'appli en amont qui devrait maintenir son propre cache (ie. via memcached), pour bien faire.
> et je vois encore souvent des bases en production en 5.0 qui n'utilisent qu'un core sur 4 malgré une configuration correcte.
hmm, ça c'est pas normal. Avec innodb_thread_concurrency et thread_concurrency > 1 ?
(nb attention à ps, il faut passer des options adéquates pour qu'il liste les threads et pas seulement les processus).
[^] # 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é à 5.
> si plusieurs scripts existent mais c'est déjà un problème en soi : lequel choisir).
Enfin, ceux qui n'ont pas l'envie ou le temps de s'occuper d'installer Slony peuvent toujours utiliser les paquets de leur distribution. Je préfère une implémentation native (plutôt parce que c'est l'assurance que ce composant suit le même processus de rewieving/qualité/release que le reste), mais c'est quand même un détail secondaire.
A moins que tu ne parle des scripts qu'on doit se bricoler pour ajouter les sets et les séquences au fur et à mesure que la structure de la / des base change ? (mais dans ce cas il s'agit plutôt d'un problème de configuration et d'"interface utilisateur" que d'intégration dans pg non ?).
> Mouaif. La réplication master-master pose énormément de problèmes
> [...] Au delà de la fiabilité, le moteur NDB induit tout un tas de limitations que je trouve inacceptable.
Je crois que tu confonds. La réplication master-master c'est une réplication traditionnelle (mais configurée dans les deux sens), utilisant le moteur de son choix (enfin, InnoDB quoi), et une ou deux petites fonctionnalités aidant les applications à éviter les conflits, et ça marche bien.
NDB c'est le moteur imposé pour "MySQL Cluster", tout autre chose. MySQL Cluster est un truc très limité, avec un nom designé pour le marketing, et exploitable pour des cas d'utilisation à mon avis franchement peut courants (et inadéquat pour le reste).
> PostgreSQL répond à ce problème avec le Point In Time Recovery
C'est une bonne fonctionnalité, mais ce n'est pas la réponse au problème.
Si tu n'a pas les WAL depuis les tout débuts de ta base (bonjour le volume), tu dois tomber un backup puis repérer jusqu'où tu applique tes logs, ce qui prendra un temps infernal (s'il s'agit d'un pg_dump, c'est très long, s'il s'agit d'un snapshot filesystem, il faut attendre que les DLT te tombent tes 400 Go de bases ...) (on parle de reprise de prod là). En outre, la méthode dont je parle permet de réellement voir les statements SQL en queue, et en quelques secondes repérer le fautif et demander au sgbd d'avancer jusqu'au précédent (ou de tout appliquer, y compris les suivants, sauf le fautif).
> Personnellement, je vois pas mal d'admins MySQL se plaindre de l'instabilité de la réplication via log shipping.
Sérieux, c'est une blague ? Je veux bien reconnaître les mérites et avantages de PostgreSQL, et ils sont nombreux, mais il ne faut pas déconner non plus : la réplication chez MySQL est native depuis au moins la version 4.0 (il y a très longtemps quoi), et c'est bien une des choses que MySQL a fini par gérer de façon correcte, simple et pratique (et qui évolue, la nouvelle replic mixte étant censée permettre d'avoir des slaves sur des machines bien moins puissantes en théorie (j'ai pas essayé cela dit)).
>> "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
Pas seulement le failover, ça limite diablement l'utilité qu'on peut tirer du slave, en toute franchise ;). J'ai cru comprendre que problème serait réglé *après* que le support pour la réplication "row based" serait intégrée, soit peut être dans 8.4, plus probablement post-8.4, quelqu'un à des nouvelles ?
> 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.
Il n'y a rien de spécial à « voir ». C'est juste que les selects sont beaucoup plus lents qu'ils pourraient l'être parce que les ressources disponibles ne sont pas exploitées de façon optimale.
Cela dit c'est vrai que dans beaucoup de cas, c'est l'appli en amont qui devrait maintenir son propre cache (ie. via memcached), pour bien faire.
> et je vois encore souvent des bases en production en 5.0 qui n'utilisent qu'un core sur 4 malgré une configuration correcte.
hmm, ça c'est pas normal. Avec innodb_thread_concurrency et thread_concurrency > 1 ?
(nb attention à ps, il faut passer des options adéquates pour qu'il liste les threads et pas seulement les processus).