> 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
Ah okok, ma confusion, je pensais que tu parlais de Slony effectivement.
> 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.
Pour clarifier, je parlais de l'aspect réplication, au sein sgbd : le stockage et les tuyaux marchent bien, c'est robuste.
Pour l'application cliente, en effet, la question se pose en d'autres termes. Ce type de solution n'est pas adaptée à tout les types d'applications (ie. les verrous ne sont pas partagés entre serveurs, c'est asynchrone, etc.). C'est plutôt pour les applications qui ont de gros besoins en écriture, et qui peuvent se contenter d'une logique type "le dernier qui update a raison" (en cas d'update d'une même chose simultanément sur plusieurs machines). Il faut aussi éviter les appli qui génèrent elles-même les pk qu'elles vont utiliser. C'est donc un truc spécifique mais qui s'avère souvent pratique. Ces limites/contraintes sont parfois plus simples à mettre en oeuvre coté applicatif que celles imposées par l'utilisation du sharding/partitionnement.
La solution supportée officiellement par MySQL pour les application généralistes désirant de la haute disponibilité avec reprise très rapide (mais sans répartition de charge), est différente, c'est DRBD (+ keepalived ou heartbeat) (à mon avis on doit pouvoir utiliser ces mêmes outils pour obtenir de la HA rapide avec pg d'ailleurs), mais, comme indiqué, c'est de la ha sans répartition de charge.
Dans tout les cas, le "scaling horizontal" (ha + lb) (par sharding/partitionnement, ou solutions type master-master, ou mysql-cluster/ndb, ...) avec les sgbd libres demande un peu de coopération de la part des applis clientes. Si j'en crois les brochures commerciales d'Oracle RAC (que je n'ai jamais essayé), eux n'imposeraient pas de telles contraintes. Bon, j'espère que le libre (PG et My) pourra un jour fournir ce niveau de service, le reste du stack applicatif libre en est généralement déjà capable (dns, lvs, proxys, serveurs applicatifs web, etc.), le sgbd est la pièce manquante (mais la plus délicate bien entendu).
> 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.
Cool ! Je ne savais pas que le patch permettant l'accès en lecture existait déjà ; c'est une super bonne nouvelle, ça veux dire qu'il ne s'agit pas seulement d'un souhait, de type "on aimerai bien avoir ça, on verra plus tard ce qu'il est possible de faire". Savoir ça, un peu d'espoir, me rendra le Slony moins amer d'ici là :).
> L'OS est loin de faire un mauvais boulot au niveau du cache disque dans beaucoup de cas.
hmm, j'aurais bien aimé causer de ça un peu, mais il va falloir que j'aille travailler, dommage ;)
> Le cache de requêtes est un autre sujet et PostgreSQL n'a aucune intention d'en implémenter un.
Note bien que le "cache des requètes" est aussi autre chose chez MySQL (ça existe (option query_cache_size), mais c'est généralement mois bénéfique, et en tout cas je parlais du cache des données (option innodb_buffer_pool_size)).
> Sur du MyISAM en l'occurrence (pas moi qui ai fait le choix).
Ah ok. C'est pas très étonnant alors : la granularité la plus fine des verrous utilisés par ce gros balot de MyISAM c'est ... le verrous par table (!). Ceci expliquant probablement cela ;)
[^] # 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.
Ah okok, ma confusion, je pensais que tu parlais de Slony effectivement.
> 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.
Pour clarifier, je parlais de l'aspect réplication, au sein sgbd : le stockage et les tuyaux marchent bien, c'est robuste.
Pour l'application cliente, en effet, la question se pose en d'autres termes. Ce type de solution n'est pas adaptée à tout les types d'applications (ie. les verrous ne sont pas partagés entre serveurs, c'est asynchrone, etc.). C'est plutôt pour les applications qui ont de gros besoins en écriture, et qui peuvent se contenter d'une logique type "le dernier qui update a raison" (en cas d'update d'une même chose simultanément sur plusieurs machines). Il faut aussi éviter les appli qui génèrent elles-même les pk qu'elles vont utiliser. C'est donc un truc spécifique mais qui s'avère souvent pratique. Ces limites/contraintes sont parfois plus simples à mettre en oeuvre coté applicatif que celles imposées par l'utilisation du sharding/partitionnement.
La solution supportée officiellement par MySQL pour les application généralistes désirant de la haute disponibilité avec reprise très rapide (mais sans répartition de charge), est différente, c'est DRBD (+ keepalived ou heartbeat) (à mon avis on doit pouvoir utiliser ces mêmes outils pour obtenir de la HA rapide avec pg d'ailleurs), mais, comme indiqué, c'est de la ha sans répartition de charge.
Dans tout les cas, le "scaling horizontal" (ha + lb) (par sharding/partitionnement, ou solutions type master-master, ou mysql-cluster/ndb, ...) avec les sgbd libres demande un peu de coopération de la part des applis clientes. Si j'en crois les brochures commerciales d'Oracle RAC (que je n'ai jamais essayé), eux n'imposeraient pas de telles contraintes. Bon, j'espère que le libre (PG et My) pourra un jour fournir ce niveau de service, le reste du stack applicatif libre en est généralement déjà capable (dns, lvs, proxys, serveurs applicatifs web, etc.), le sgbd est la pièce manquante (mais la plus délicate bien entendu).
> 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.
Cool ! Je ne savais pas que le patch permettant l'accès en lecture existait déjà ; c'est une super bonne nouvelle, ça veux dire qu'il ne s'agit pas seulement d'un souhait, de type "on aimerai bien avoir ça, on verra plus tard ce qu'il est possible de faire". Savoir ça, un peu d'espoir, me rendra le Slony moins amer d'ici là :).
> L'OS est loin de faire un mauvais boulot au niveau du cache disque dans beaucoup de cas.
hmm, j'aurais bien aimé causer de ça un peu, mais il va falloir que j'aille travailler, dommage ;)
> Le cache de requêtes est un autre sujet et PostgreSQL n'a aucune intention d'en implémenter un.
Note bien que le "cache des requètes" est aussi autre chose chez MySQL (ça existe (option query_cache_size), mais c'est généralement mois bénéfique, et en tout cas je parlais du cache des données (option innodb_buffer_pool_size)).
> Sur du MyISAM en l'occurrence (pas moi qui ai fait le choix).
Ah ok. C'est pas très étonnant alors : la granularité la plus fine des verrous utilisés par ce gros balot de MyISAM c'est ... le verrous par table (!). Ceci expliquant probablement cela ;)