Bonjour à tous,
 
Je me tourne vers vous car là je suis un peu à cours d'idées pour résoudre mon problème.
 
Voilà la situation:
J'ai 2 machines Debian Sarge avec Noyau 2.6.8-2-386 sur lesquelles sont installées notamment MySQL 4.1 et un LDAP
J'utilise DRBD pour faire de la haute dispo et synchroniser la partition DRBD /opt sur laquelle sont installées les données MySQL et LDAP.
 
Pour rappel à un instant T, la machine maître a sa partition DRBD montée et la machine esclave reçoit juste les données écrites sur la machine maître (mais sa partition n'est pas montée). Ce n'est qu'au moment où la machine maître tombe que la machine esclave prend le relai et monte sa propre partition DRBD qui est une copie conforme de celle de la machine maître.
 
Mon problème est le suivant:
Je veux mettre à jour mes Debian: passage en Etch et upgrade du noyau.
Je lance donc les commandes suivantes:
 
=> apt-get update      : OK sur les 2 machines
=> apt-get upgrade     : OK sur les 2 machines
=> apt-get dist-upgrade: plantage!
 
Lors du dist-upgrade, il upgrade DRBD et me demande si je veux mettre à jour le fichier de conf. Je mets NON et il continue son Upgrade.
Mais j'ai remarqué qu'à ce stade, la partition DRBD n'est plus montée!
Lorsqu'il arrive sur l'upgrade de MySQL pour le passer en version 5, il me sature la partition / car ne trouvant plus de partition /opt spécifique (celle qui est sur DRBD et qui fait 30Go), il me met l'upgrade dans /opt qui est du coup sur la partition / qui elle n'a que 1.6Go de dispo.
Et à ce stade, la partition / est à 100%!
 
Je ne comprends pas pourquoi d'une part DRBD ne fonctionne plus lors de cet upgrade et d'autre part, pourquoi il écrit autant d'info dans /opt/mysql
 
Le plantage s'effectue lorsque MySQL s'arrête puis redémarre.
 
D'où ma question: savez-vous comment faire pour que lors de l'upgrade, DRBD reste monté

tu es sur que le fait de ne pas mettre à jour la conf permet à drbd de redémarrer correctement ?
 
as tu recompilé le module apres upgrade du kernel ?

Non mais j'ai aussi testé en mettant à jour la conf de DRBD et en ajoutant dans le fichier de conf ce que j'avais ajouté dans le fichier de conf de la version précédente. Et ça n'a rien changé.
 
Par contre, je vais essayer autre chose: mettre à jour DRBD avant l'upgrade et le dist-upgrade. Avec un peu de chance, ça fonctionnera...

C'est une solution a tenter mais avec le risque de ne pas satisfaire certaines dépendances pour la nouvelle version de DRDB avec la version actuelle de la distribution (là je n'en sais rien par contre, il faut essayer).
 
Sinon la possibilité inverse est aussi a tenter, en forçant le maintien de la version actuelle de DRBD et de faire le dist-upgrade de tout le reste ; ça peut passer, il faut essayer, bien qu'un conflit de versions ou des dépendances non satisfaites puissent interrompre le dist-upgrade.
 
Autrement, pendant le dist-upgrade, juste après la tentative de mise à jour de DRBD, essayes de remonter manuellement la partition de DRBD.

 
Merci pour ces idées
Effectivement je peux essayer de faire dans le sens inverse.
 
J'ai essayé de monter manuellement la partition drbd avant la fin du dist-upgrade mais rien n'y a fait. J'ai eu le message d'erreur suivant :"version tags of drbdsetup and drbd kernel module are not matching".
 
Par contre vu que la partition DRBD ne contient que mysql et ldap et que c'est mysql qui pose problème, je peux peut être forcer le dist-upgrade à ne pas upgrader mysql et ldap.
 
Mais du coup il me vient une autre question: comment va se comporter l'esclave face à cet update? va-t-il prendre le relais? va-t-il est dans les choux

il va prendre le relais si heartbeat est coupé sur le noeud primaire.
 
Il faut recompiler le module drbd ....

 
Qu'entends-tu par là
Tu veux dire qu'avec le dist-upgrade ça ne fonctionnera pas et qu'il faut directement recompiler ce module

la partie userland de drbd (drbdadm, drbdsetup...) n'a pas la meme version  (api:79/proto:74) que le module.

et lors du dist-upgrade, il upgrade bien la partie userland + module ou seulement le module