guillaume78fr a écrit 7 commentaires

Très intéressant tout ça. Reste donc à savoir ce qu'Oracle à l'intention de faire...

Pour ce qui est de la reprise de flambeau par PostgreSQL, je suis d'accord avec toi, mais ce que je voulais dire, c'est que c'est l'alternative la plus proche en OpenSource... SQLite et BerkeleyDB sont certes très pratiques pour certaines utilisations très simples, mais sont quand même loin de MySQL. Du coup, même si PostgreSQL diffère pas mal de MySQL dans la philosophie, je pense que c'est la seule alternative viable.
Attention, je ne cherche pas à troller et je trouve chacun des SGBD très intéressants, mais ils ont chacun leurs domaines d'utilisation.

Quoiqu'il en soit, merci pour l'info sur MariaDB. Tout ceci laisse finalement augurer de bonne chose pour l'avenir...

C'est vrai que c'est tout bête, mais je n'y avais pas pensé... Je rejetterai un oeil sur le site dans quelques temps.

Je suis peut-être optimiste mais je crois assez peu en un 'MySQL n'avance pas à cause d'Oracle'.
À mon sens, ce serait une bêtise de la part d'Oracle de casser MySQL. En effet, le code source de MySQL est disponible et la communauté est grande. Si Oracle délaissait MySQL, il y a fort à parier qu'un fork OpenSource verrait le jour...

Personnellement, je pense qu'il serait plus malin de la part d'Oracle de proposer une offre plus large et de se charger du support plutôt que tuer MySQL. De surcroit, si MySQL mourrait, PostgreSQL reprendrait à coup sûr le flambeau. Or si PostgreSQL cumulait ses parts de marché avec celle de MySQL, ça pourrait faire encore plus d'ombre à Oracle... (PostgreSQL est plus proche d'un Oracle que MySQL...).

Bref, mes questions restent ouvertes.

Bien entendu ;)

En fait, il s'agit de "socket options" et "read size". Les meilleures valeurs que j'ai trouvées sont :
socket options = TCP_NODELAY SO_RCVBUF=16384 SO_SNDBUF=16384
read size = 16384

Malheureusement "write size" n'a que très peu d'influence...

Pour info, j'ai un switch gigabit et des cartes ad-hoc en full-duplex. Ca peut paraître idiot, mais avant j'étais en 100 Mbits/s et je n'avais aucun problème : env. 7.5 Mo/s dans les deux sens quelque soit l'OS client...

Etant donné que je viens de me rendre compte de ma bêtise, je me réponds à moi-même en me disant que ça servira probablement à d'autres...

LDAP est un serveur d'annuaires...

Il est donc bien évidemment possible de gérer plusieurs domaines sur plusieurs bases (ça se gère dans le /etc/slapd.conf)

Pour finir, voici un lien vers un excellent tutoriel sur LDAP (à mon goût) :
http://mparienti.developpez.com/cours/openldap/?page=sommair(...)

Désolé pour le dérangement...

Guillaume

Merci ! Merci ! Merci !

Tout mes fichiers de conf étaient bons, mais je n'avais effectivement pas vu ce lien et ces 3 commandes. Depuis tout va pour le mieux dans le meilleur des mondes!

Franchement merci, car je commençais à me dire qu'il allait falloir refaire entièrement la machine...

Encore Merci

Guillaume

> Je ne m'y connais pas bien en noyau debian.
> - as-tu un initrd ?

Oui et je pense qu'il est bon car les modules nécessaires sont chargés (md_mod, raid1 et reiserfs)

> - ne faudrait-il pas regénérer l'initrd ?

Il est vrai que c'est un nouvel outil qui crée le initrd (update-initramfs). Je vais tenter de refaire le initrd avec mkinitrd et je te tiendrais au courant.

> - tes disques sont-ils nommés de la même facon ?

Ben, c'est la tout le problème.
avec les noyau 2.6.8, j'ai 3 partitions sur chacun de mes deux disques (sda[123] et sdb[123])
Avec le nouveau noyau 2.6.18, j'ai sda et sdb sans les partitions. J'aurai bien fait un (c)fdisk pour vérifier ce qui était écrit mais la console de débuggage ne contient pas ces outils...

> - as-tu essayé de diagnostiquer avec un livecd en 2.6.18 ?

Je n'ai que du 2.6.19 (KLA - Knoppix 3.1.1), mais il trouve toutes les partitions... Ca vient donc bien du boot...