"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 ?)."
Non, je ne parle même pas de Slony mais de la réplication par log shipping qui demande des scripts pour gérer tout ça correctement.
"et une ou deux petites fonctionnalités aidant les applications à éviter les conflits, et ça marche bien"
Hmmm, un doute sur le "ça marche bien". Ca doit bien marcher dans certains cas, oui, mais la résolution de conflit dans le cas du multi master est très loin d'être trivial.
C'est là où MySQL a une approche beaucoup plus pragmatique que les autres bases. Le fait que ça marche dans la majorité des cas suffit en général.
"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"
Euh, personnellement, je fais régulièrement des snapshots de la base. Donc, ce n'est pas depuis le tout début mais depuis le dernier snapshot. C'est déjà beaucoup moins long, même si ça peut effectivement déjà l'être.
"Sérieux, c'est une blague ?"
Non non. La réplication via log shipping qui saute a l'air d'être assez classique (je ne fais que répéter ce que les gens m'en ont dit - des gens en contact direct avec le problème et des gens assez variés et assez compétents pour que ça ne me paraisse pas une erreur triviale).
"Pas seulement le failover, ça limite diablement l'utilité qu'on peut tirer du slave, en toute franchise ;)"
Tu as mal compris ma phrase. Je disais justement que ça le limitait au failover donc que ça n'avait pas d'utilité en dehors de ça. On est bien d'accord là-dessus.
"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 ?"
Il y a deux patches en attente d'intégration pour la 8.4 :
- un patch pour gérer la réplication standard en interne au lieu de recourir à des scripts, réplication toujours basée sur l'envoi des fichiers de WAL ;
- un patch pour permettre d'accéder au standby en lecture seule.
Après, nul ne peut parier qu'ils seront intégrés dans la 8.4.
"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."
Tu prends un peu trop les mots au pied de la lettre :). L'OS est loin de faire un mauvais boulot au niveau du cache disque dans beaucoup de cas. Comme je le disais, ça a un coût, tout le monde en convient, mais c'est un choix.
Le cache de requêtes est un autre sujet et PostgreSQL n'a aucune intention d'en implémenter un.
"hmm, ça c'est pas normal. Avec innodb_thread_concurrency et thread_concurrency > 1 ?"
Sur du MyISAM en l'occurrence (pas moi qui ai fait le choix). Et j'ai vu plusieurs personnes avec ce même problème.
[^] # 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é à 4.
Non, je ne parle même pas de Slony mais de la réplication par log shipping qui demande des scripts pour gérer tout ça correctement.
"et une ou deux petites fonctionnalités aidant les applications à éviter les conflits, et ça marche bien"
Hmmm, un doute sur le "ça marche bien". Ca doit bien marcher dans certains cas, oui, mais la résolution de conflit dans le cas du multi master est très loin d'être trivial.
C'est là où MySQL a une approche beaucoup plus pragmatique que les autres bases. Le fait que ça marche dans la majorité des cas suffit en général.
"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"
Euh, personnellement, je fais régulièrement des snapshots de la base. Donc, ce n'est pas depuis le tout début mais depuis le dernier snapshot. C'est déjà beaucoup moins long, même si ça peut effectivement déjà l'être.
"Sérieux, c'est une blague ?"
Non non. La réplication via log shipping qui saute a l'air d'être assez classique (je ne fais que répéter ce que les gens m'en ont dit - des gens en contact direct avec le problème et des gens assez variés et assez compétents pour que ça ne me paraisse pas une erreur triviale).
"Pas seulement le failover, ça limite diablement l'utilité qu'on peut tirer du slave, en toute franchise ;)"
Tu as mal compris ma phrase. Je disais justement que ça le limitait au failover donc que ça n'avait pas d'utilité en dehors de ça. On est bien d'accord là-dessus.
"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 ?"
Il y a deux patches en attente d'intégration pour la 8.4 :
- un patch pour gérer la réplication standard en interne au lieu de recourir à des scripts, réplication toujours basée sur l'envoi des fichiers de WAL ;
- un patch pour permettre d'accéder au standby en lecture seule.
Après, nul ne peut parier qu'ils seront intégrés dans la 8.4.
"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."
Tu prends un peu trop les mots au pied de la lettre :). L'OS est loin de faire un mauvais boulot au niveau du cache disque dans beaucoup de cas. Comme je le disais, ça a un coût, tout le monde en convient, mais c'est un choix.
Le cache de requêtes est un autre sujet et PostgreSQL n'a aucune intention d'en implémenter un.
"hmm, ça c'est pas normal. Avec innodb_thread_concurrency et thread_concurrency > 1 ?"
Sur du MyISAM en l'occurrence (pas moi qui ai fait le choix). Et j'ai vu plusieurs personnes avec ce même problème.