Désolé pour le raccourcis, j'aurais du dire : « Avocent fournis aussi les chipset des serveurs Sun (ALOM), des HP (pour les iLO), [...] qui ont donc eux aussi le même problème (du moins ceux qui essaient de fournir cette fonctionnalité, évidement) ».
> les ELOM et ILOM ont une interface web qui fonctionne parfaitement avec firefox.
Soit on n'a pas le même niveau d'exigence (mais à ce point, ça me semble peu probable), soit tu a la chance d'utiliser une des rares config/environnement firefox a avoir miraculeusement été testée par Avocent. Ou alors un firefox sous Windows ? là aussi j'aurais dû mieux préciser : « marchent super mal avec les firefox et/ou les java inclus dans les distros Linux modernes et orientées desktop ». En ce qui me concerne, je n'ai jamais réussi à installer un OS à distance sur un HP sans ressortir une machine virtuelle sous Windows (faute de quoi : media virtuel qui se déconnecte abruptement, freeze du navigateur, applet qui se met à ne plus rien afficher, keystroke doublés, ... sous firefox linux).
> Parce que TdR est le seul que je connaisse qui se plaint que ses utilisateurs respectent la licence?
Pas vraiment. Canonical est un utilisateur des contributions de Novel, Oracle est utilisateur des contributions de Red Hat, Xemacs un utilisateur des contributions faites sur Emacs, Tivo de Linux, tout fork hostile est un utilisateur du projet parent, Apple de KHTML, ... si tu vois ce que je veux dire.
J'oubliais :
- Watchdog : fournis à travers l'interface standard IPMI. Donc pas besoin de driver spécifique, ça marche out of the box avec un kernel BSD comme avec un kernel Linux.
- Petits matériel : visseries, ventilateurs, cables d'alim, etc. standards. Lecteur CD, RAM, CPUS, disques durs (SCSI avant, SAS désormais), etc. standards. Les rails et les tiroirs disques durs sont sur mesure, comme pour tout les serveurs.
- BIOS & ACPI : de bonne factures, qui ne choquent pas le noyau Linux ni même (et c'est plus difficile) celui d'OpenBSD, et qui ne masquent pas les instructions de virtualisation ou autres fonctionnalité importantes.
On peux difficilement faire beaucoup plus standard et F/OSS-friendly comme matériel serveur (je dis serveur, parce que sur un desktop ou laptop les choses qui comptent le plus sont différentes : carte graphique, carte wifi, suspend-to-ram et hibernation, etc.).
Oui j'ai vu que tu apportais cette précision après coup dans ce thread, mais pourquoi as-t-on droit à ce genre de considérations sélectivement à chaque fois qu'un projet BSD à des problèmes (et beaucoup plus rarement dans les autres dépêches où ça serait aussi applicable) ?
(nb: ce n'est peut-être pas toi les autres fois hein, je n'ai pas vérifié ;)
> Bah quand tu économises un paquet en utilisant un logiciel sous X11/BSD et que ton
> activité te rapporte un paquet, si tu réfléchis deux secondes, tu te rends bien compte
> que ça vaut le coût d'aider un peu le projet qui te sert tant. Parceque si chacun en profite
> sans verser en retour, le projet qui te sert tant risque de disparaître faute de moyens.
Je suis d'accord avec ça sur le plan théorique.
En pratique, j'ai bossé uniquement dans des boîtes qui dépendent vitalement de moultes logiciels libres, et qui ne filent absolument rien (sauf une) : ni argent, ni code, ni même de la doc en retour...
Et vous ? quelles sont vos expérience ?
Je suppose plusieurs raisons à ce comportement peu citoyen :
o L'avarice aveugle et court-termiste des dirigeants
o Se défausser sur les autres (« ils trouveront bien quelqu'un d'autre qui contribuera »)
o L'absence de conscience de la notion de « bien public », dans le secteur privé français
o La difficulté de justifier une dépense non imposée aux dirigeants ou actionnaires
o Une mentalité foncièrement consumériste (« on se pose pas de question, on trouve plein de bouffe sur la table, on mange tout ce qu'on peux, on rote et on se casse »)
Alors rappeler publiquement que ces projets libres sont fragiles, et dépendent vitalement des contributeurs (de code comme d'argent) ne peux pas faire de mal (bien que je doute que ça suffise à amener une prise de conscience générale).
> Mais pourquoi serais-tu désespéré? Tu dis au gens "servez-vous" et ils se servent, et tu n'es pas content?
> [...]
> si quelqu'un se fait du fric en respectant la licence
Pourquoi amener un troll licence chaque fois qu'une dépêche parle d'un projet BSD ? ce que tu dit là, tu pourrais l'appliquer à presque chaque rixe entre participants de la communauté linux (forks, mauvaises contribs, absences de contrib, ...), car on peux faire des choses plus ou moins correctes/éthiques/citoyennes en respectant la GPL, y compris v3, comme avec la BSD.
Comme pour tout les projets libres, la plupart des règles de bonnes conduites ne sont pas rédigées par des avocats, et il n'est pas forcément pertinent que ce qui serait "souhaitable" devienne "obligatoire" par le marbre d'une licence. Il n'est pas question de forcer les gens à donner des sous, encore moins de changer de licence : c'est juste un coup de gueule. TdR ne renie donc pas la licence BSD.
On a droit aux mêmes types de débats ou coups de gueules, qui sont donc indépendants des licences libres choisies, lorsqu'un développeur de Novell râle publiquement au sujet de la faible contribution d'Ubuntu/Canonical aux logiciels Linux bas niveau, ou lorsqu'un zélote de Red Hat ou de Debian dénonce sur dflp le faible engagement "upstream" d'Ubuntu : certes Canonical respecte la GPL à la lettre en faisant du blé, mais ils pourraient être de meilleurs citoyens. Ou encore : certes Oracle "fait du fric avec en respectant la licence" de RHEL, mais on comprends que ceux-ci se soient offusqué d'un certain manque de savoir vivre, à l'époque de "unfakable linux".
Même chose lorsque les développeurs noyaux se plaignent du faible effort de contribution upstream venant du monde des développeurs embarqué, mais personne ne souhaite changer la licence du kernel pour "forcer à contribuer du code suffisamment bon pour être mergé upstream". Gueuler contre une utilisation opportuniste et non durable d'une licence n'est pas renier cette licence.
Pour recadrer : il n'était pas du tout repproché de "faire du fric". Le coup de gueule de TdR, c'était à mes yeux une façon de faire remarquer que le projet OpenBSD avait besoin de sous, qu'il y avait un paquet de grosses entreprises (y compris Cisco, Juniper, Sun, etc.) qui utilisaient le code OpenSSH et pour qui quelques centaines de dollars de dons seraient peut-être une petite somme pour ne pas scier la branche sur laquelle elles sont assises, ou encore "la moindre des politesses".
Aussi, et ce n'est peut-être pas évident à percevoir pour ceux qui ne connaissent que le monde Linux parmi les OS libres, mais OpenBSD est essentiellement un projet de hobbyistes, fait avec les moyens du bord, et où par conséquent chaque sous compte, même pour les besoins d'infrastructure de base (cf. cette dépêche par exemple) ; c'est très différent de Linux qui bénéficie de contributions matérielles et humaines de nombreuses grosses sociétés (y compris Intel, AMD, Oracle, etc), où le problème de faire d'humiliantes quètes ne se pose donc pas. C'est pour ça qu'OpenBSD a un besoin vital de dons de sous, plus encore que de dons de code, même si ça peut paraitre vulgaire ou terre à terre.
> Ce n'est pas un constructeur réputé pour faire du materiel standart
Tout le contraire.
Et c'est ce qui importe pour des serveurs sous (et pour) OpenBSD : ils n'utilisent pas de softs proprios pour gérer le matériel serveur (quand bien même ils le voudraient, ils ne sont pas dans le radar des fabricants de chipsets, qui ne fournissent donc pas de vilains outils proprios). Même chose que pour le wifi en fait.
Sur tout les points possibles d'achoppement ou incompatibilité pouvant toucher un serveur :
- Controleur RAID : depuis deux ans, toutes les cartes RAID des Dell (PERC5 et PERC6) sont basées sur des chipsets LSI (et non plus Adaptec), dont les specs sont ouvertes. Ce qui permet d'avoir un bon driver, et de les gérer (monitoring, reconstruction, etc.) avec le brctl(8) natif d'OpenBSD.
- Sensors : les sensors sont tous accessibles par l'interface standard IPMI, donc bien supportés par les outils natifs (sensord, et les outils de supervision externes).
- Southbridge : Les chipsets des cartes mères sont du Intel (pas cette horrible merde de nvidia) (à l'exception des rares serveurs amd, mais je crois qu'il n'y a que du Intel sur la gamme PowerEdge 2950).
- Net : Les cartes réseau sont du Broadcom BCM5708 (bon, du intel serait mieux mais ça marche).
Le seul point perfectible à mes yeux sont les cartes d'accès/prise en main à distance (Dell DRAC), dont le chipset et le firmware sont fournis par Avocent, et merdent un peu sous firefox. Notez que cette plaie d'Avocent fournis aussi les chipset des serveurs Sun (ALOM), des HP (pour les iLO), de IBM (pour les RSA-II), etc., qui ont donc eux aussi le même problème. Faudrait que les utilisateurs de firefox ralent un peu pour que les constructeurs exigent un meilleur firmware de ce fournisseur, qui semble s'imaginer que les admins bossent tous avec un java 32 bits sous ie7.
De mémoire, les précédents appels aux dons pour du matos d'infrastructure (comme le précédent main cvs) annonçaient aussi être destinés à acheter du Dell, vraissemblablement pour les même raisons : OpenBSD est plus sensible que Linux au matériel "pas ouvert" ou "pas standard".
> il est possible d'avoir une image "template", et pour chaque machine virtuelle
> d'utilisateur, on ne stocke que le delta. La place gagnée est énorme,
En tout cas sur ce point, les solutions libres ne sont pas en reste :
# Créer son image de base
qemu-img create -f qcow2 desktop_base.qcow2 10G
# Y installer son OS et ses applications
kvm -hda desktop_base.qcow2 -cdrom ...
> 1- Avant ils devaient payer et supportaient donc le libre dans un sens en contribuant dirrectement au salaires des dévelopeurs.
Ah oui ce point 1 ouvre des questions intéressantes je trouve.
J'ai souvenir d'une interview récente (mais d'avant le rachat par Sun) du PDG de MySQL A.B., dans lequel ce dernier rappelait qu'un des points intéressant de sa compagnie, c'est qu'elle explorait successivement, et défrichait les possibilités et limites des divers modèles économiques du libre. Ou plutôt, que MySQL A.B. était pionnier dans le défrichage des modèles économie du libre pour les sociétés qui financent le développement coûteux d'un produit et ne peuvent pas forcément se financer entièrement avec le modèle intuitif « finançons notre produit phare et libre en vendant du support autour du produit ».
Peu d'autres grandes sociétés, à ma connaissance, étaient exposés à ces contraintes d'innovation et exploration des modèles, hors MySQL A.B. et Trolltech (pour les autres grosses sociétés contributrices : l'économie de Red Hat, c'est surtout le support, celle de Intel c'est le matériel, Novell c'est le support et les autres produits proprios, Canonical on ne sais pas trop, etc.).
Avec ce changement chez Nokia, nous perdons un pionnier / un des derniers grands exemples de recherche, mise en oeuvre, ajustements, ... d' un modèle économique viable pour une grande entreprise entièrement tournée vers le libre, et c'est un peu dommage de ce point de vue.
> C'est pouvoir faire du proprio avec Qt qui te rend joyeux ?
La remarque ci-dessus n'est pas très pertinente il me semble, sachant que :
1- Qt permettait déjà de faire du proprio, c'était leur modèle économique (double licence), modèle qu'ils viennent justement d'abandonner (ou presque) à l'instant.
2- Ce changement s'accompagne d'une série de mesures qui laissent supposer que ce que Nokia cherche, au moins en partie, c'est à favoriser et tirer partis des potentiels contributeurs de l'écosystème libre :
2-a- Ils viennent aussi de rendre leur dépot de code source principal public (ils sont passés à Git pour l'occasion)
2-b- Ils abandonnent l'exigence d'attribution du copyright (qui était nécessaire jusqu'à présent à code de leur modèle double licence). On pourra désormais contribuer comme on contribue au kernel (et pas comme on contribue OpenOffice.org ou MySQL).
Je perçois la simultanéité de ces trois changements (licence compatible avec un plus grand nombre, dépôt ouvert, allègement des contraintes pour contribuer) comme un signe clair à l'attention des développeurs du monde libre. C'est aussi ce qu'en conclus l'article d'Ars Technica en lien. Qu'en pensez-vous ?
Remarquez que pour une bibliothèque, faire le choix d'une licence copyleft plus souple (aka non "virale") est aussi le choix d'élargir la base des utilisateurs potentiels, dans l'écosystème libre, par exemple :
- Ne pas imposer la GPLv3 aux applications qui veulent utiliser la GPLv2 (ou inversement)
- Permettre aux applications utilisant la bibliothèque de choisir, pour elles même, un autre type de licence libre (MIT, BSD, MPL, LGPL aussi, Eclipse, etc.).
- Permettre aux applications utilisatrices de se lier à d'autres bibliothèques libres mais sous des licences plus ou moins incompatibles avec la GPL (par ex. OpenSSL, ou les composants sous licence apache1, ou CDDL, etc.).
Trolltech/Nokia maintenait de fait, depuis un bon moment, une liste d'exception à la GPL pour autoriser explicitement l'utilisation de Qt aux applications utilisant les principales licences libres. Mais ce n'est certainement pas une liste facile à maintenir, et elle était loin d'être exhaustive.
Donc, pour répondre à la question du message parent, ce qui me rends joyeux c'est cet ensemble de changement, c'est le fait que Qt adopte un modèle plus ouvert, moins contraignant, tout en restant fidèle au libre. Pas de quoi pleurer :)
Les snapshots par répertoires ne sont pas encore tout à fait là, mais sont au planning . Ils étaient prévus pour fin mars 2008[1], mais Mason à préféré travailler en priorité sur les éléments de bases permettant l'intégration mainline[2] (comme la capacité de gérer proprement les partitions saturées).
Cela étant, les snapshots (de tout le root fs) sont d'ors et déjà peu couteux (COW oblige).
Oui, et de loin franchement.
Ses fonctionnalités sont déjà largement en avance par rapport à celles de reiserfs (et reprennent comme tu le signale les bonnes propriétés de celui-ci).
Le plus important (à mes yeux, concernant un système de fichier, et en comparaison avec reiserfs) est qu'il promet d'être très activement maintenu, suscitant l'intérêt vif et la participation de développeurs critiques chez IBM, Red Hat, SUSE, Oracle, Intel. Cette diversité est prometteuse, car elle signifie que bientôt chacune de ces sociétés sera capable de gérer les bugs rencontrés par ses clients, donc en mesure de proposer et supporter officiellement ce système de fichiers, de l'affiner pour ses workloads spécifiques, etc. Par contraste, reiserfs est désormais en mode "maintenance faible" chez SUSE et Mandriva, son développeur principal ne participe plus, et il n'est tout simplement pas supporté par Red Hat (autrement dit : peu de chances d'améliorations fonctionelles, désormais, à la différence de ext4, XFS et btrfs).
Une fonctionnalité bluffante pas décrite dans la dépêche, et pas faisable avec les outils actuels (LVM) : btrfs permet de faire des snapshots d'un répertoire quelconque du système de fichier (par ex. juste le /etc). D'autre part, il n'est pas nécessaire de réserver de l'espace disque dès le départ pour pouvoir faire ses snapshots (comme avec LVM). Ce sont de petits détails, mais il y en a beaucoup comme ça, et ils chacun peu, je pense, changer la vie des sysadmins :).
Pour répondre à la question de Michel plus haut :
> Par contre comment se débrouille Btrfs par rapport à la "concurrence" sur SSD ?
Pour le moment btrfs ne fait pas grand chose de spécifique pour les SSD. En pratique : la routine de recherche permettant de trouver de l'espace libre et utilisable parmi les extents alloués dispose d'un raccourcis/court-circuit dans le cas du SSD.
Mais il est prévu d'essayer de tirer le meilleur partis, de façon spécifique, des SSD, c'est d'ailleurs pour ça qu'une option de montage spécifique "ssd" est déjà intégrée.
XFS (depuis peu, et de façon encore expérimentale) et btrfs intègrent des fonctionnalités de gestion des périphériques multiples (normalement dévolues aux couches MD et LVM du noyau) précisément pour se permettre ce genre d'optimisations : en connaissant précisément la couche physique (le matériel sous-jacent), ils pourront décider au mieux de l'agencement des données. Par exemple, dans un aggrégat de disques durs et de SSD : placer les métadonnées (nécessitant beaucoup d'accès aléatoires) sur le SSD et les données dont l'accès est plus séquentiel sur disque dur, ou encore (et parce que, pour des raisons de fiabilité, btrfs permet de dupliquer les métadonnées critiques) savoir comment répartir les diverses copies sur des disques effectivement physiquement différents est difficile lorsque cette information est masquée par l'agrégation LVM ou MD.
Et aussi : btrfs (comme ZFS en fait) peut (si monté en conséquence) s'assurer de l'intégrité des données à l'aide de checksums (pour le moment, uniquement des crc32). S'il a un accès direct aux disques physiques (direct = pas déjà agrégé / masqué par une couche raid sous-jacente), il peux décider de chercher une copie en bon état du bloc concerné, puis la dupliquer de nouveau sur le disque où la copie était mauvaise (mais dans un autre bloc), voir prendre des décisions pertinentes au sujet des blocs contigus ou du disque lui-même. Un gestionnaire RAID classique, lui, ne pouvant pas accéder aux informations du fs, se contentera de mettre le disque entier offline dès qu'il détectera le problème. C'est une problématique importante, justement, pour les SSD (dont certains blocs peuvent "vieillir" sans que l'ensemble du périphérique soit à jetter), et en fait, avec les gros disques modernes (le risque d'une panne globale du disque est aussi grand qu'auparavant, mais le risque d'avoir un ou deux blocs défectueux augmente au fur et à mesure que les disques grossissent en capacité).
Ou encore : sur un système RAID classique (logiciel avec mdadm ou lvm, ou matériel), la couche RAID permet d'avoir une seule taille de stripe, définie à la construction de l'agrégat. Ce choix n'est pas optimal pour tout les cas, même lorsque le système de fichier est proprement aligné sur les stripes (par ex. avec l'option "stride" d'ext3/ext4) : les lectures/écritures séquentielles de gros fichiers bénéficient de larges stripes, tandis que les petites écritures (métadonnées, par ex.) bénéficient de petites stripes (sans quoi, les écritures successives seront mal réparties sur les divers disques physiques de l'array). Or le système de fichier dispose de ses informations (taille probable des lectures/écritures) ; il est donc en mesure de prendre de très bonnes décisions en allouant des stripes de taille dynamique selon ses besoins spécifiques.
Je signale au passage que sur ce point (la fameuse "rampant layering violation") cette dépêche est fausse.
Je suppose qu'elle a été écrite à partir de l'article de patrick_g sur Wikipédia, qui se base sur des informations juste mais datées. En pratique, Chris Mason avait l'intention d'essayer de faire un fs qui communique et délègue aux couches pertinentes (d'où le texte dans l'article de WP), mais s'est aperçu ensuite qu'il devait gérer l'essentiel dans le système de fichiers lui-même pour pouvoir exploiter de façon optimale les périphériques multiples (cf. plus haut), les snapshots, etc.
En somme, l'intention de départ était bien, effectivement, de ne pas "violer" les divers "block layers" du noyau, mais ce qui s'est réellement passé c'est que la mentalité des développeurs Linux a globalement évolué sur ce point, et que ce type de "violations" est désormais considéré comme légitime (dans une certaine mesure). Le paradigme a simplement changé, les développeurs Linux ne sont pas obtus.
Le GPT (GUID Partition Table) est un format de table de partitions qui permet, notamment, de s'affranchir d'une pénible limitation des partitions MSDOS (actuellement couramment utilisées) : celle de pouvoir adresser des partitions sur des périphériques de plus de 2 TB (la limite actuelle des partitions DOS, qui pointent vers des blocs de 512 B adressés en 32 bits).
Autant dire que tout le monde utilisera ça bientôt. Mais pour l'heure, l'utilisation de disques (ou agrégats LVM ou RAID, etc) de plus de 2 TB est toujours une source de surprises rafraichissantes (par exemple : saviez vous que le bon vieux fdisk Linux ne permet tout simplement pas de les partitionner ? que le nombre maximum de blocs sur un ext3fs est 2^31-1 ? qu'il faut passer l'option "--metadata=1.2" à mdadm pour pouvoir l'utiliser sur des agrégats de plus de 2 TB ? etc.).
Oh et pendant que j'y suis (et que je parle de mesure) :
Connaissez-vous seekwatcher ? C'est un outil basé sur blktrace permettant de mesurer et visualiser finement les accès disques coûteux sur une période de temps (en mettant en vis à vis le débit, les déplacements de têtes par seconde, les offsets sur le disque). Développé par Chris Mason (de btrfs) à Oracle :
> Sinon, cela semble être la continuité de la chose, le nombre de processeurs/cœurs
> augmente, il faut donc adapter les programmes pour les utiliser correctement...
Si le principal point de contention est la CPU...
J'ai l'impression (mais sans avoir fait de mesures, hein;) que le goulot d'étranglement, lors du chargement de l'espace utilisateur (et plus particulièrement des gros DE), sont plutôt les I/O, pour le moment.
Entendez-vous vos disques crépiter, au lancement de gnome ? Voyez-vous votre page cache si dodu, lorsque vous pouvez enfin lancer un "cat /proc/meminfo" au démarrage ?
Le lancement de ces services nécessite l'ouverture et la lecture d'une myriade de petits fichiers répartis un peu partout sur le système de fichier. Dans l'état, la parallélisation fera gagner en temps CPU, mais la contention des accès disques n'en sera pas améliorée ; elle sera plutôt empirée (en rendant les accès encore plus aléatoires / moins séquentiels).
Pour rappel, un bon disque SCSI ou SAS est capable d'environ 200 IOPS : c'est peu. C'est encore une ressource précieuse, partagée entre les tout les logiciels qui doivent se lancer, et pour laquelle il nous reste une belle marge d'amélioration. A moins qu'on ne saute cette phase, en misant sur la généralisation du SSD ?
> Par contre, des changements comme le bête print me semble injustifié. Certes, c'est plus logique mais garder un simple statement print n'aurait rien coûté et le coût de la migration me semble disproportionné par rapport au gain.
Le changement sur print() semble assez arbitraire, mais le coût de la migration est assez faible en fait : ils fournissent un script appelé 2to3 qui sait convertir ton code automatiquement (et les changements sont backward compatibles, la syntaxe print() est supportée dans les versions précédentes de python). Pour le reste je n'ai pas d'opinion.
> 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 ;)
> 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).
> Sinon cette archi LAMP n'est pas à considérer comme le fin du fin en matière
> de représentabilité des capacités des sgbdr.
Tout à fait, loin s'en faut.
C'est juste un des cas d'utilisation possible, celui où MySQL a du succès (alors qu' il me semble, à vue de nez, que PostgreSQL a pour sa part plus de succès dans les applications métier, plus complexe et « relationnelles » si on veux).
> Tous les cites dont tu parles doivent supporter une charge essentiellement
> en lecture qui est surtout du ressort d'un cache de données et non du sgbd.
Les sites que je cite les savent déjà, et utilisent des serveurs de cache. J'ai cité par exemple LiveJournal : ce sont les inventeurs et mainteneurs de memcached. Il n'empêche que leurs serveurs bases sont nombreux et en (des écritures, plutôt que des lectures, donc) prennent plein les dents (ils ont communiqué sur leur achi). Idem pour les Digg et consorts.
> La grosse différence est que la 8.3 est sortie sans bug grave connu
Très marrant d'affirmer ça pour un projet qui n'a pas de bug tracker (ce qui est précisément le seul point concernant l'organisation/le communautaire/l'ouverture où pg est moins bon que my). Belle ironie.
> 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, ...
> Une infrastructure basée sur MySql n'est pas franchement ce qu'il y a de plus stable.
> C'est peut-être un outil convenable pour un site comme dlfp où personne n'ira se
> plaindre en cas de crash,
C'est ça.
Sauf que tout les gros LAMP à forte progression / populaires utilisent MySQL lorsqu'ils n'utilisent pas une techno proprio : Youtube, Slashdot, Wikipedia, Flickr, Linkedin, Livejournal, Twitter, Facebook, Digg, Mixi, Yahoo Finance, ...
C'est sans doute parce que les admins de ces sites sont des dilettantes mal informés et ne lisent pas assez les trolls velus des pg afficionados sur dflp.
PostgresSQL a ses (gros) avantages, comparé à MySQL, mais il a aussi des défauts critiques pour certains besoins.
[^] # Re: Pourquoi du Dell
Posté par herodiade . En réponse à la dépêche Appel aux dons pour OpenBSD. Évalué à 2.
Désolé pour le raccourcis, j'aurais du dire : « Avocent fournis aussi les chipset des serveurs Sun (ALOM), des HP (pour les iLO), [...] qui ont donc eux aussi le même problème (du moins ceux qui essaient de fournir cette fonctionnalité, évidement) ».
> les ELOM et ILOM ont une interface web qui fonctionne parfaitement avec firefox.
Soit on n'a pas le même niveau d'exigence (mais à ce point, ça me semble peu probable), soit tu a la chance d'utiliser une des rares config/environnement firefox a avoir miraculeusement été testée par Avocent. Ou alors un firefox sous Windows ? là aussi j'aurais dû mieux préciser : « marchent super mal avec les firefox et/ou les java inclus dans les distros Linux modernes et orientées desktop ». En ce qui me concerne, je n'ai jamais réussi à installer un OS à distance sur un HP sans ressortir une machine virtuelle sous Windows (faute de quoi : media virtuel qui se déconnecte abruptement, freeze du navigateur, applet qui se met à ne plus rien afficher, keystroke doublés, ... sous firefox linux).
[^] # Re: Les entreprises payent ?
Posté par herodiade . En réponse à la dépêche Appel aux dons pour OpenBSD. Évalué à 3.
Pas vraiment. Canonical est un utilisateur des contributions de Novel, Oracle est utilisateur des contributions de Red Hat, Xemacs un utilisateur des contributions faites sur Emacs, Tivo de Linux, tout fork hostile est un utilisateur du projet parent, Apple de KHTML, ... si tu vois ce que je veux dire.
[^] # Re: Pourquoi du Dell
Posté par herodiade . En réponse à la dépêche Appel aux dons pour OpenBSD. Évalué à 7.
- Watchdog : fournis à travers l'interface standard IPMI. Donc pas besoin de driver spécifique, ça marche out of the box avec un kernel BSD comme avec un kernel Linux.
- Petits matériel : visseries, ventilateurs, cables d'alim, etc. standards. Lecteur CD, RAM, CPUS, disques durs (SCSI avant, SAS désormais), etc. standards. Les rails et les tiroirs disques durs sont sur mesure, comme pour tout les serveurs.
- BIOS & ACPI : de bonne factures, qui ne choquent pas le noyau Linux ni même (et c'est plus difficile) celui d'OpenBSD, et qui ne masquent pas les instructions de virtualisation ou autres fonctionnalité importantes.
On peux difficilement faire beaucoup plus standard et F/OSS-friendly comme matériel serveur (je dis serveur, parce que sur un desktop ou laptop les choses qui comptent le plus sont différentes : carte graphique, carte wifi, suspend-to-ram et hibernation, etc.).
[^] # Re: Les entreprises payent ?
Posté par herodiade . En réponse à la dépêche Appel aux dons pour OpenBSD. Évalué à 1.
(nb: ce n'est peut-être pas toi les autres fois hein, je n'ai pas vérifié ;)
[^] # Re: Les entreprises payent ?
Posté par herodiade . En réponse à la dépêche Appel aux dons pour OpenBSD. Évalué à 5.
> activité te rapporte un paquet, si tu réfléchis deux secondes, tu te rends bien compte
> que ça vaut le coût d'aider un peu le projet qui te sert tant. Parceque si chacun en profite
> sans verser en retour, le projet qui te sert tant risque de disparaître faute de moyens.
Je suis d'accord avec ça sur le plan théorique.
En pratique, j'ai bossé uniquement dans des boîtes qui dépendent vitalement de moultes logiciels libres, et qui ne filent absolument rien (sauf une) : ni argent, ni code, ni même de la doc en retour...
Et vous ? quelles sont vos expérience ?
Je suppose plusieurs raisons à ce comportement peu citoyen :
o L'avarice aveugle et court-termiste des dirigeants
o Se défausser sur les autres (« ils trouveront bien quelqu'un d'autre qui contribuera »)
o L'absence de conscience de la notion de « bien public », dans le secteur privé français
o La difficulté de justifier une dépense non imposée aux dirigeants ou actionnaires
o Une mentalité foncièrement consumériste (« on se pose pas de question, on trouve plein de bouffe sur la table, on mange tout ce qu'on peux, on rote et on se casse »)
Alors rappeler publiquement que ces projets libres sont fragiles, et dépendent vitalement des contributeurs (de code comme d'argent) ne peux pas faire de mal (bien que je doute que ça suffise à amener une prise de conscience générale).
[^] # Re: Les entreprises payent ?
Posté par herodiade . En réponse à la dépêche Appel aux dons pour OpenBSD. Évalué à 10.
> [...]
> si quelqu'un se fait du fric en respectant la licence
Pourquoi amener un troll licence chaque fois qu'une dépêche parle d'un projet BSD ? ce que tu dit là, tu pourrais l'appliquer à presque chaque rixe entre participants de la communauté linux (forks, mauvaises contribs, absences de contrib, ...), car on peux faire des choses plus ou moins correctes/éthiques/citoyennes en respectant la GPL, y compris v3, comme avec la BSD.
Comme pour tout les projets libres, la plupart des règles de bonnes conduites ne sont pas rédigées par des avocats, et il n'est pas forcément pertinent que ce qui serait "souhaitable" devienne "obligatoire" par le marbre d'une licence. Il n'est pas question de forcer les gens à donner des sous, encore moins de changer de licence : c'est juste un coup de gueule. TdR ne renie donc pas la licence BSD.
On a droit aux mêmes types de débats ou coups de gueules, qui sont donc indépendants des licences libres choisies, lorsqu'un développeur de Novell râle publiquement au sujet de la faible contribution d'Ubuntu/Canonical aux logiciels Linux bas niveau, ou lorsqu'un zélote de Red Hat ou de Debian dénonce sur dflp le faible engagement "upstream" d'Ubuntu : certes Canonical respecte la GPL à la lettre en faisant du blé, mais ils pourraient être de meilleurs citoyens. Ou encore : certes Oracle "fait du fric avec en respectant la licence" de RHEL, mais on comprends que ceux-ci se soient offusqué d'un certain manque de savoir vivre, à l'époque de "unfakable linux".
Même chose lorsque les développeurs noyaux se plaignent du faible effort de contribution upstream venant du monde des développeurs embarqué, mais personne ne souhaite changer la licence du kernel pour "forcer à contribuer du code suffisamment bon pour être mergé upstream". Gueuler contre une utilisation opportuniste et non durable d'une licence n'est pas renier cette licence.
Pour recadrer : il n'était pas du tout repproché de "faire du fric". Le coup de gueule de TdR, c'était à mes yeux une façon de faire remarquer que le projet OpenBSD avait besoin de sous, qu'il y avait un paquet de grosses entreprises (y compris Cisco, Juniper, Sun, etc.) qui utilisaient le code OpenSSH et pour qui quelques centaines de dollars de dons seraient peut-être une petite somme pour ne pas scier la branche sur laquelle elles sont assises, ou encore "la moindre des politesses".
Aussi, et ce n'est peut-être pas évident à percevoir pour ceux qui ne connaissent que le monde Linux parmi les OS libres, mais OpenBSD est essentiellement un projet de hobbyistes, fait avec les moyens du bord, et où par conséquent chaque sous compte, même pour les besoins d'infrastructure de base (cf. cette dépêche par exemple) ; c'est très différent de Linux qui bénéficie de contributions matérielles et humaines de nombreuses grosses sociétés (y compris Intel, AMD, Oracle, etc), où le problème de faire d'humiliantes quètes ne se pose donc pas. C'est pour ça qu'OpenBSD a un besoin vital de dons de sous, plus encore que de dons de code, même si ça peut paraitre vulgaire ou terre à terre.
[^] # Re: Pourquoi du Dell
Posté par herodiade . En réponse à la dépêche Appel aux dons pour OpenBSD. Évalué à 10.
Tout le contraire.
Et c'est ce qui importe pour des serveurs sous (et pour) OpenBSD : ils n'utilisent pas de softs proprios pour gérer le matériel serveur (quand bien même ils le voudraient, ils ne sont pas dans le radar des fabricants de chipsets, qui ne fournissent donc pas de vilains outils proprios). Même chose que pour le wifi en fait.
Sur tout les points possibles d'achoppement ou incompatibilité pouvant toucher un serveur :
- Controleur RAID : depuis deux ans, toutes les cartes RAID des Dell (PERC5 et PERC6) sont basées sur des chipsets LSI (et non plus Adaptec), dont les specs sont ouvertes. Ce qui permet d'avoir un bon driver, et de les gérer (monitoring, reconstruction, etc.) avec le brctl(8) natif d'OpenBSD.
- Sensors : les sensors sont tous accessibles par l'interface standard IPMI, donc bien supportés par les outils natifs (sensord, et les outils de supervision externes).
- Southbridge : Les chipsets des cartes mères sont du Intel (pas cette horrible merde de nvidia) (à l'exception des rares serveurs amd, mais je crois qu'il n'y a que du Intel sur la gamme PowerEdge 2950).
- Net : Les cartes réseau sont du Broadcom BCM5708 (bon, du intel serait mieux mais ça marche).
Le seul point perfectible à mes yeux sont les cartes d'accès/prise en main à distance (Dell DRAC), dont le chipset et le firmware sont fournis par Avocent, et merdent un peu sous firefox. Notez que cette plaie d'Avocent fournis aussi les chipset des serveurs Sun (ALOM), des HP (pour les iLO), de IBM (pour les RSA-II), etc., qui ont donc eux aussi le même problème. Faudrait que les utilisateurs de firefox ralent un peu pour que les constructeurs exigent un meilleur firmware de ce fournisseur, qui semble s'imaginer que les admins bossent tous avec un java 32 bits sous ie7.
De mémoire, les précédents appels aux dons pour du matos d'infrastructure (comme le précédent main cvs) annonçaient aussi être destinés à acheter du Dell, vraissemblablement pour les même raisons : OpenBSD est plus sensible que Linux au matériel "pas ouvert" ou "pas standard".
[^] # Re: Pas trop saisi
Posté par herodiade . En réponse à la dépêche VMware View Open Client passe sous LGPL. Évalué à 1.
> d'utilisateur, on ne stocke que le delta. La place gagnée est énorme,
En tout cas sur ce point, les solutions libres ne sont pas en reste :
# Créer son image de base
qemu-img create -f qcow2 desktop_base.qcow2 10G
# Y installer son OS et ses applications
kvm -hda desktop_base.qcow2 -cdrom ...
# En dériver quelques clones/images delta légères
qemu-img create -b desktop_base.qcow2 -f qcow2 clone1.qcow2
qemu-img create -b desktop_base.qcow2 -f qcow2 clone2.qcow2
...
[^] # Re: Au contraire, il commence !
Posté par herodiade . En réponse au journal Qt LGPL!. Évalué à 2.
Ah oui ce point 1 ouvre des questions intéressantes je trouve.
J'ai souvenir d'une interview récente (mais d'avant le rachat par Sun) du PDG de MySQL A.B., dans lequel ce dernier rappelait qu'un des points intéressant de sa compagnie, c'est qu'elle explorait successivement, et défrichait les possibilités et limites des divers modèles économiques du libre. Ou plutôt, que MySQL A.B. était pionnier dans le défrichage des modèles économie du libre pour les sociétés qui financent le développement coûteux d'un produit et ne peuvent pas forcément se financer entièrement avec le modèle intuitif « finançons notre produit phare et libre en vendant du support autour du produit ».
Peu d'autres grandes sociétés, à ma connaissance, étaient exposés à ces contraintes d'innovation et exploration des modèles, hors MySQL A.B. et Trolltech (pour les autres grosses sociétés contributrices : l'économie de Red Hat, c'est surtout le support, celle de Intel c'est le matériel, Novell c'est le support et les autres produits proprios, Canonical on ne sais pas trop, etc.).
Avec ce changement chez Nokia, nous perdons un pionnier / un des derniers grands exemples de recherche, mise en oeuvre, ajustements, ... d' un modèle économique viable pour une grande entreprise entièrement tournée vers le libre, et c'est un peu dommage de ce point de vue.
[^] # Re: Au contraire, il commence !
Posté par herodiade . En réponse au journal Qt LGPL!. Évalué à 10.
La remarque ci-dessus n'est pas très pertinente il me semble, sachant que :
1- Qt permettait déjà de faire du proprio, c'était leur modèle économique (double licence), modèle qu'ils viennent justement d'abandonner (ou presque) à l'instant.
2- Ce changement s'accompagne d'une série de mesures qui laissent supposer que ce que Nokia cherche, au moins en partie, c'est à favoriser et tirer partis des potentiels contributeurs de l'écosystème libre :
2-a- Ils viennent aussi de rendre leur dépot de code source principal public (ils sont passés à Git pour l'occasion)
2-b- Ils abandonnent l'exigence d'attribution du copyright (qui était nécessaire jusqu'à présent à code de leur modèle double licence). On pourra désormais contribuer comme on contribue au kernel (et pas comme on contribue OpenOffice.org ou MySQL).
Je perçois la simultanéité de ces trois changements (licence compatible avec un plus grand nombre, dépôt ouvert, allègement des contraintes pour contribuer) comme un signe clair à l'attention des développeurs du monde libre. C'est aussi ce qu'en conclus l'article d'Ars Technica en lien. Qu'en pensez-vous ?
Remarquez que pour une bibliothèque, faire le choix d'une licence copyleft plus souple (aka non "virale") est aussi le choix d'élargir la base des utilisateurs potentiels, dans l'écosystème libre, par exemple :
- Ne pas imposer la GPLv3 aux applications qui veulent utiliser la GPLv2 (ou inversement)
- Permettre aux applications utilisant la bibliothèque de choisir, pour elles même, un autre type de licence libre (MIT, BSD, MPL, LGPL aussi, Eclipse, etc.).
- Permettre aux applications utilisatrices de se lier à d'autres bibliothèques libres mais sous des licences plus ou moins incompatibles avec la GPL (par ex. OpenSSL, ou les composants sous licence apache1, ou CDDL, etc.).
Trolltech/Nokia maintenait de fait, depuis un bon moment, une liste d'exception à la GPL pour autoriser explicitement l'utilisation de Qt aux applications utilisant les principales licences libres. Mais ce n'est certainement pas une liste facile à maintenir, et elle était loin d'être exhaustive.
Donc, pour répondre à la question du message parent, ce qui me rends joyeux c'est cet ensemble de changement, c'est le fait que Qt adopte un modèle plus ouvert, moins contraignant, tout en restant fidèle au libre. Pas de quoi pleurer :)
[^] # Re: LVM Obsolète ?
Posté par herodiade . En réponse à la dépêche Btrfs intègre le noyau Linux dès la prochaine version 2.6.29. Évalué à 1.
Pour ce qui est de l'agrégation de disques et du stripping, voyez (pas tout à fait à jour d'ailleurs) :
http://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Mult(...)
ça me semble déjà pas mal, pour un début :)
[^] # Re: Snapshot ...
Posté par herodiade . En réponse à la dépêche Btrfs intègre le noyau Linux dès la prochaine version 2.6.29. Évalué à 3.
Cela étant, les snapshots (de tout le root fs) sont d'ors et déjà peu couteux (COW oblige).
[1] C'est indiqué, par exemple, dans la timeline de btrfs, ici: http://oss.oracle.com/projects/btrfs/dist/documentation/todo(...)
Le site oss.oracle.com est entièrement down pour le moment, désolé, voici une version en cache :
http://209.85.129.132/search?q=cache:j0rkDJXeAQMJ:oss.oracle(...)
Ou si tu préfère, voici un article qui cite cette timeline (dernier paragraphe) : http://lwn.net/Articles/265257/
[2] Ce qu'en dit Chris Mason directement (là aussi, l'archive de la m-l est sur oss.oracle.com ...) :
http://209.85.129.132/search?q=cache:GBzfRbsdgtAJ:oss.oracle(...)
[^] # Re: LVM Obsolète ?
Posté par herodiade . En réponse à la dépêche Btrfs intègre le noyau Linux dès la prochaine version 2.6.29. Évalué à 5.
Suppose your Mountpoint is /mnt:
add 2GB to the FS
btrfsctl -r +2g /mnt
shrink the FS by 4GB
btrfsctl -r -4g /mnt
Explicitly set the FS size
btrfsctl -r 20g /mnt
Use 'max' to grow the FS to the limit of the device
btrfsctl -r max /mnt
Citation de http://btrfs.wiki.kernel.org/index.php/Btrfsctl
[^] # Re: Reiserfs
Posté par herodiade . En réponse à la dépêche Btrfs intègre le noyau Linux dès la prochaine version 2.6.29. Évalué à 10.
Oui, et de loin franchement.
Ses fonctionnalités sont déjà largement en avance par rapport à celles de reiserfs (et reprennent comme tu le signale les bonnes propriétés de celui-ci).
Le plus important (à mes yeux, concernant un système de fichier, et en comparaison avec reiserfs) est qu'il promet d'être très activement maintenu, suscitant l'intérêt vif et la participation de développeurs critiques chez IBM, Red Hat, SUSE, Oracle, Intel. Cette diversité est prometteuse, car elle signifie que bientôt chacune de ces sociétés sera capable de gérer les bugs rencontrés par ses clients, donc en mesure de proposer et supporter officiellement ce système de fichiers, de l'affiner pour ses workloads spécifiques, etc. Par contraste, reiserfs est désormais en mode "maintenance faible" chez SUSE et Mandriva, son développeur principal ne participe plus, et il n'est tout simplement pas supporté par Red Hat (autrement dit : peu de chances d'améliorations fonctionelles, désormais, à la différence de ext4, XFS et btrfs).
Une fonctionnalité bluffante pas décrite dans la dépêche, et pas faisable avec les outils actuels (LVM) : btrfs permet de faire des snapshots d'un répertoire quelconque du système de fichier (par ex. juste le /etc). D'autre part, il n'est pas nécessaire de réserver de l'espace disque dès le départ pour pouvoir faire ses snapshots (comme avec LVM). Ce sont de petits détails, mais il y en a beaucoup comme ça, et ils chacun peu, je pense, changer la vie des sysadmins :).
Pour répondre à la question de Michel plus haut :
> Par contre comment se débrouille Btrfs par rapport à la "concurrence" sur SSD ?
Pour le moment btrfs ne fait pas grand chose de spécifique pour les SSD. En pratique : la routine de recherche permettant de trouver de l'espace libre et utilisable parmi les extents alloués dispose d'un raccourcis/court-circuit dans le cas du SSD.
Mais il est prévu d'essayer de tirer le meilleur partis, de façon spécifique, des SSD, c'est d'ailleurs pour ça qu'une option de montage spécifique "ssd" est déjà intégrée.
XFS (depuis peu, et de façon encore expérimentale) et btrfs intègrent des fonctionnalités de gestion des périphériques multiples (normalement dévolues aux couches MD et LVM du noyau) précisément pour se permettre ce genre d'optimisations : en connaissant précisément la couche physique (le matériel sous-jacent), ils pourront décider au mieux de l'agencement des données. Par exemple, dans un aggrégat de disques durs et de SSD : placer les métadonnées (nécessitant beaucoup d'accès aléatoires) sur le SSD et les données dont l'accès est plus séquentiel sur disque dur, ou encore (et parce que, pour des raisons de fiabilité, btrfs permet de dupliquer les métadonnées critiques) savoir comment répartir les diverses copies sur des disques effectivement physiquement différents est difficile lorsque cette information est masquée par l'agrégation LVM ou MD.
Et aussi : btrfs (comme ZFS en fait) peut (si monté en conséquence) s'assurer de l'intégrité des données à l'aide de checksums (pour le moment, uniquement des crc32). S'il a un accès direct aux disques physiques (direct = pas déjà agrégé / masqué par une couche raid sous-jacente), il peux décider de chercher une copie en bon état du bloc concerné, puis la dupliquer de nouveau sur le disque où la copie était mauvaise (mais dans un autre bloc), voir prendre des décisions pertinentes au sujet des blocs contigus ou du disque lui-même. Un gestionnaire RAID classique, lui, ne pouvant pas accéder aux informations du fs, se contentera de mettre le disque entier offline dès qu'il détectera le problème. C'est une problématique importante, justement, pour les SSD (dont certains blocs peuvent "vieillir" sans que l'ensemble du périphérique soit à jetter), et en fait, avec les gros disques modernes (le risque d'une panne globale du disque est aussi grand qu'auparavant, mais le risque d'avoir un ou deux blocs défectueux augmente au fur et à mesure que les disques grossissent en capacité).
Ou encore : sur un système RAID classique (logiciel avec mdadm ou lvm, ou matériel), la couche RAID permet d'avoir une seule taille de stripe, définie à la construction de l'agrégat. Ce choix n'est pas optimal pour tout les cas, même lorsque le système de fichier est proprement aligné sur les stripes (par ex. avec l'option "stride" d'ext3/ext4) : les lectures/écritures séquentielles de gros fichiers bénéficient de larges stripes, tandis que les petites écritures (métadonnées, par ex.) bénéficient de petites stripes (sans quoi, les écritures successives seront mal réparties sur les divers disques physiques de l'array). Or le système de fichier dispose de ses informations (taille probable des lectures/écritures) ; il est donc en mesure de prendre de très bonnes décisions en allouant des stripes de taille dynamique selon ses besoins spécifiques.
Je signale au passage que sur ce point (la fameuse "rampant layering violation") cette dépêche est fausse.
Je suppose qu'elle a été écrite à partir de l'article de patrick_g sur Wikipédia, qui se base sur des informations juste mais datées. En pratique, Chris Mason avait l'intention d'essayer de faire un fs qui communique et délègue aux couches pertinentes (d'où le texte dans l'article de WP), mais s'est aperçu ensuite qu'il devait gérer l'essentiel dans le système de fichiers lui-même pour pouvoir exploiter de façon optimale les périphériques multiples (cf. plus haut), les snapshots, etc.
En somme, l'intention de départ était bien, effectivement, de ne pas "violer" les divers "block layers" du noyau, mais ce qui s'est réellement passé c'est que la mentalité des développeurs Linux a globalement évolué sur ce point, et que ce type de "violations" est désormais considéré comme légitime (dans une certaine mesure). Le paradigme a simplement changé, les développeurs Linux ne sont pas obtus.
Voyez cette paire de réponse de Christophe Hellwig (développeur de XFS) et Chris Mason (développeur de btrfs) à Andrew Morton qui s'interrogeait récemment sur cette question de "layering violation" :
http://thread.gmane.org/gmane.comp.file-systems.btrfs/1601/f(...)
http://article.gmane.org/gmane.comp.file-systems.btrfs/1764
[^] # Re: désolé
Posté par herodiade . En réponse à la dépêche Sortie de FreeBSD 7.1. Évalué à 10.
Autant dire que tout le monde utilisera ça bientôt. Mais pour l'heure, l'utilisation de disques (ou agrégats LVM ou RAID, etc) de plus de 2 TB est toujours une source de surprises rafraichissantes (par exemple : saviez vous que le bon vieux fdisk Linux ne permet tout simplement pas de les partitionner ? que le nombre maximum de blocs sur un ext3fs est 2^31-1 ? qu'il faut passer l'option "--metadata=1.2" à mdadm pour pouvoir l'utiliser sur des agrégats de plus de 2 TB ? etc.).
[^] # Re: Il ne reste plus qu'à...
Posté par herodiade . En réponse à la dépêche L'évolution de Fastboot. Évalué à 5.
Connaissez-vous seekwatcher ? C'est un outil basé sur blktrace permettant de mesurer et visualiser finement les accès disques coûteux sur une période de temps (en mettant en vis à vis le débit, les déplacements de têtes par seconde, les offsets sur le disque). Développé par Chris Mason (de btrfs) à Oracle :
http://oss.oracle.com/~mason/seekwatcher/
Ca donne des choses comme ça, beaucoup plus lisibles que la sortie brute de blktrace ! :
http://oss.oracle.com/~mason/seekwatcher/ext3_vs_btrfs_vs_xf(...)
http://oss.oracle.com/~mason/seekwatcher/ext3-compilebench.m(...)
[^] # Re: Il ne reste plus qu'à...
Posté par herodiade . En réponse à la dépêche L'évolution de Fastboot. Évalué à 2.
> augmente, il faut donc adapter les programmes pour les utiliser correctement...
Si le principal point de contention est la CPU...
J'ai l'impression (mais sans avoir fait de mesures, hein;) que le goulot d'étranglement, lors du chargement de l'espace utilisateur (et plus particulièrement des gros DE), sont plutôt les I/O, pour le moment.
Entendez-vous vos disques crépiter, au lancement de gnome ? Voyez-vous votre page cache si dodu, lorsque vous pouvez enfin lancer un "cat /proc/meminfo" au démarrage ?
Le lancement de ces services nécessite l'ouverture et la lecture d'une myriade de petits fichiers répartis un peu partout sur le système de fichier. Dans l'état, la parallélisation fera gagner en temps CPU, mais la contention des accès disques n'en sera pas améliorée ; elle sera plutôt empirée (en rendant les accès encore plus aléatoires / moins séquentiels).
Pour rappel, un bon disque SCSI ou SAS est capable d'environ 200 IOPS : c'est peu. C'est encore une ressource précieuse, partagée entre les tout les logiciels qui doivent se lancer, et pour laquelle il nous reste une belle marge d'amélioration. A moins qu'on ne saute cette phase, en misant sur la généralisation du SSD ?
[^] # Re: GEM précisions
Posté par herodiade . En réponse à la dépêche Le noyau Linux 2.6.28 est disponible. Évalué à 4.
[^] # Re: Raisons?
Posté par herodiade . En réponse au journal Python 3000 est sorti. Évalué à 8.
Les justifications sont dans les PEP :
http://www.python.org/dev/peps/pep-3105/
http://www.python.org/dev/peps/pep-3108/
etc.
> Par contre, des changements comme le bête print me semble injustifié. Certes, c'est plus logique mais garder un simple statement print n'aurait rien coûté et le coût de la migration me semble disproportionné par rapport au gain.
Le changement sur print() semble assez arbitraire, mais le coût de la migration est assez faible en fait : ils fournissent un script appelé 2to3 qui sait convertir ton code automatiquement (et les changements sont backward compatibles, la syntaxe print() est supportée dans les versions précédentes de python). Pour le reste je n'ai pas d'opinion.
[^] # 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 ;)
[^] # 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).
[^] # 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é à 2.
> de représentabilité des capacités des sgbdr.
Tout à fait, loin s'en faut.
C'est juste un des cas d'utilisation possible, celui où MySQL a du succès (alors qu' il me semble, à vue de nez, que PostgreSQL a pour sa part plus de succès dans les applications métier, plus complexe et « relationnelles » si on veux).
> Tous les cites dont tu parles doivent supporter une charge essentiellement
> en lecture qui est surtout du ressort d'un cache de données et non du sgbd.
Les sites que je cite les savent déjà, et utilisent des serveurs de cache. J'ai cité par exemple LiveJournal : ce sont les inventeurs et mainteneurs de memcached. Il n'empêche que leurs serveurs bases sont nombreux et en (des écritures, plutôt que des lectures, donc) prennent plein les dents (ils ont communiqué sur leur achi). Idem pour les Digg et consorts.
[^] # 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é à 4.
Très marrant d'affirmer ça pour un projet qui n'a pas de bug tracker (ce qui est précisément le seul point concernant l'organisation/le communautaire/l'ouverture où pg est moins bon que my). Belle ironie.
[^] # 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, ...
[^] # 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é à 10.
> C'est peut-être un outil convenable pour un site comme dlfp où personne n'ira se
> plaindre en cas de crash,
C'est ça.
Sauf que tout les gros LAMP à forte progression / populaires utilisent MySQL lorsqu'ils n'utilisent pas une techno proprio : Youtube, Slashdot, Wikipedia, Flickr, Linkedin, Livejournal, Twitter, Facebook, Digg, Mixi, Yahoo Finance, ...
C'est sans doute parce que les admins de ces sites sont des dilettantes mal informés et ne lisent pas assez les trolls velus des pg afficionados sur dflp.
PostgresSQL a ses (gros) avantages, comparé à MySQL, mais il a aussi des défauts critiques pour certains besoins.