Descriptif d’une journée Loose avec OVH.
Pensez à bien vérifier votre boite à spams, car si vous recevez un mail comme celui-ci ca peut vite devenir le mode panique.
A DegradedArray event had been detected on md device /dev/md2.
DegradedArray signifie que vous avez surement un problème de disque dur, et qu’il faut rapidement vérifier tout cela. Lancez putty, et une connexion ssh au serveur dédié kimsufi.
Tout d’abord, faites une sauvegarde de vos données (fichiers + bases de données).
Vérifier l’état de vos 2 disques:
smartctl -a -data /dev/sda
smartctl -a -data /dev/sdb
Si l’un d’eux vous affiche des erreurs, vous avez trouvé le problème, et vous pouvez commencer à remplir le formulaire d’incident en spécifiant le disque à remplacer sda ou sdb. Si les 2 affichent des erreurs, c’est que vous avez trop tardé à vous occuper du problème ou que vous manquez cruellement de chance et que votre sauvegarde raid est morte.
Partons du principe que vous devez remplacer un seul disque (dans l’exemple le sda). Si vous devez changer le 2e, il vous faudra refaire l’opération en sens inverse.
1er étape – refaire les partitions du disque B à l’identique sur A:
sfdisk -d /dev/sdb | sfdisk /dev/sda
2e étape: ajouter le disque A au RAID pour la partition 1
mdadm /dev/md1 –manage –add /dev/sda1
On verifie que tout se passe correctement avec la commande:
mdadm –misc –detail /dev/md1
Normalement, on voit quelque chose comme ca:
Rebuild Status : 5% complete
Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
2 8 17 1 spare rebuilding /dev/sdb1
Puis, on ajouter le disque A au RAID pour la partition 2
mdadm /dev/md2 –manage –add /dev/sda2
Pour suivre l’avancement de la reconstruction du RAID, vous avez la commande
cat /proc/mdstat
Comptez plusieurs heures (une demi-journée) pour un disque de 1 To.
Note: Vous pouvez redémarrer le serveur, la reconstruction du RAID reprendra où elle est rendue.
La reconstruction est finie, mais vous avez encore des problèmes. Votre site ne marche toujours pas, et votre plesk ne permet plus l’accès au serveur. Des erreurs disques se profilent à l’horizon. Et bien, bienvenue dans la partie méga Loose de ce tuto.
En ce qui me concerne, les problèmes étaient les suivants. mysql se lancait correctement, mais dès que je lancais la moindre requête : un « show databases », ou un « show tables », le serveur m’éjectait et redémarrait « MySQL server has gone away ».
Pour Plesk, j’obtenais ERROR: PleskFatalException
Unable to connect to database: mysql_connect()
Avant toute chose, pensez à vérifier que les process mysql tournent
ps -ef | grep mysql
service mysql status
Analysez ensuite les logs avec
cat /var/log/mysql.log
cat /var/log/mysql/error.log
cat /var/log/mysql.err
Et la, vous aurez surement l’origine du problème.
Pour mon cas, le problème était sur innodb, le 2e disque étant aussi mort. Il fallait procéder au remplacement complet de mysql.
J’ai donc demandé un nouveau changement de disque. Là plus rien ne fonctionnait du tout (mais ouf j’avais une sauvegarde de tout ça).
Je pense que le secteur d’amorçage devait indiqué le mauvais disque et comme le RAID n’était pas remonté sur celui-ci, seul le mode RESCUE permettait de relancer la machine.
Bref, j’ai demandé une restuaration via l’interface Manager d’OVH. Si le PLESK vous redemande une licence, faites un renouvellement via l’interfaçe d’OVH, et vous devriez retrouver vos petits dans l’heure.
Je vous joint ici un petit script à placer dans le serveur pour faire une sauvegarde automatique de la base de données chaque semaine. A vous après d’aller la récupérer via FTP.
Créér d’abord un répertoire db-backup dans root.
#!/bin/sh cd /root/db-backup mysqldump -hlocalhost -uUSERNAME -pPASSWORD BASENAME > $(date +%Y-%m-%d)-BASENAME-db.sql gzip *.sql
Ajouter ceci dans etc/crontab et relancer le service cron.
0 0 * * 7 root /root/db-backup/save-db.sh
Avez-vous eu ce type de sueurs froides vous aussi ?
