Au tout début, lorsque j’ai commencé à laisser Linux créer des Volumes Group par défaut à l’installation, je trouvais ça compliqué. Mais en fait, après quelques années, LVM n’arrête pas de me surprendre. Ce système est génial!

Dernièrement, le disque de 2TB contenant l’intégralité des données (/home) commençait à montrer de sérieux signes de faiblesses. Il était temps de le remplacer avant de tout perdre. Ceux qui ont déjà remplacé un disque sans LVM dont une partition abritai le /home seront certainement d’accord avec moi: c’est chiant. Avec LVM2, c’est presque trop facile.

Continuer la lecture de LINUX – Remplacement d’un disque dans un volume Groupe LVM2 →

Supervision du Raid

La supervision des volumes Raid est gérée par mdadm et nécessite la présence du fichier de configuration /etc/mdadm.conf. Si ce fichier est absent, il est possible de le générer après la création des volumes Raid de la façon suivante:

mdadm --verbose --detail --scan > /etc/mdadm.conf

le fichier devrait ressembler à ceci:

ARRAY /dev/md/localhost.localdomain:0 level=raid5 num-devices=3 metadata=1.2 name=localhost.localdomain:0 UUID=d74aa481:760d8a60:0ada2cc8:51a1f439
   devices=/dev/sda1,/dev/sdb1,/dev/sdc1

Afin de configurer les alertes mails, ajouter les informations suivantes à la fin du fichier:

MAILFROM raid@coradi.fr
MAILADDR leseb@coradi.fr

Démarrer ensuite le service de supervision du Raid:

systemctl start mdmonitor.service

Pour activer le service au démarrage du serveur, lancer la commande:

systemctl enable mdmonitor.service

Pour vérifier que le service est bien démarré, lancer la commande suivante et observer le retour de la commande:

systemctl status mdmonitor.service -l

Gestion de l’erreur mismatch_cnt is not 0 on /dev/md0

Si vous recevez les messages cron, ou que vous relevez la boite root, vous avez pouvez avoir des messages du type:
/etc/cron.weekly/99-raid-check:
WARNING: mismatch_cnt is not 0 on /dev/md0

Ce message indique une désynchronisation des données sur les disques du volume Raid md0 (le chiffre peut varier en fonction de la configuration et/ou du nombre de volumes Raid). Cela peut être dû à une erreur logiciel (facilement réparable) ou matériel (là, c’est la merde!).

Commencez par vérifier l’état du Raid en exécutant:

cat /proc/mdstat

Vérifier que le compteur de désynchronisation des données est toujours différent de 0:

cat /sys/block/md0/md/mismatch_cnt

Voici comment remettre les compteurs à 0.

Pour réparer le volume, lancer:

echo repair >/sys/block/md0/md/sync_action

Vous pouvez suivre l’évolution de l’action avec la commande:

watch cat /proc/mdstat

Une fois la réparation terminée, lancer une vérification du volume:

echo check >/sys/block/md0/md/sync_action

Une fois la réparation terminée, le compteur doit être de nouveau à 0:

cat /sys/block/md0/md/mismatch_cnt

Affiche la taille des bases de données:

SELECT table_schema , sum( data_length + index_length ) / 1024 / 1024 /1024 "Data Base Size in GB" FROM information_schema.TABLES GROUP BY table_schema;

Affiche la taille de chaque table d’une BDD:

SELECT table_name AS "Tables", round(((data_length + index_length) / 1024 / 1024), 2) "Size in MB" FROM information_schema.TABLES WHERE table_schema = "zabbix" ORDER BY (data_length + index_length) DESC;

Afficher la liste de tous les utilisateurs MySQL

SELECT User,Host FROM mysql.user;

Créez une nouvelle base de donnée:

CREATE DATABASE database_name;

Créez un nouvel utilisateur avec mot de passe:

CREATE USER 'user_name'@'localhost' IDENTIFIED BY 'mot_de_passe';

Donnez les permissions à l’utilsateur sur la base de données:

GRANT ALL ON database_name.* TO 'user_name'@'localhost';

Appliquez les privilèges:

FLUSH PRIVILEGES;

La beta 4 de XBMC 13 (Gotham) étant sortie, j’ai voulu la tester, mais j’ai eu une petite surprise lors de l’upgrade d’XBMC depuis la version 12 (Frodo) vers la version 13 beta 4. Impossible de mettre à jour la base de données des vidéos depuis la version 12 (MyVideos 75) vers la version 13 (MyVideos78). Je précise que toutes les instances d’XBMC installées chez moi communiquent avec une base de données MySQL centralisée.

Avant toute chose, il me parait important d’expliquer brièvement le fonctionnement des bases de données MySQL d’XBMC.
Chaque version XBMC utilise un schéma de base de données différent, ce qui fait que chaque version d’XBMC installée va créer une base de données différente. La base de données portera un nom du type: MyVideos<numéro de version> ou MyMusic<numéro de version>.

Pour XBMC 12.3, la base de données vidéos se nomme MyVideos75
Pour XBMC 13, MyVideos78.

Les différentes instances d’XBMC portant la même version utiliseront bien sûr la même base de données. Lorsque l’on installe une nouvelle version d’XBMC ou que l’on met à jour une version existante, la nouvelle version d’XBMC va vérifier les bases de données présentes dans MySQL, puis créer une nouvelle base de données estampillée du nouveau numéro de version, et intégrer les données présentes dans la BDD déjà existante.

Ceci étant dit, passons au diagnostique et à la résolution du problème.

Après une petite exploration des logs XBMC, voici ce qu’ils m’affichent :

20:28:29 T:5516   ERROR: Unable to open database: MyVideos78 [1049](Unknown database 'MyVideos78')
20:28:29 T:5516   ERROR: Unable to open database: MyVideos77 [1049](Unknown database 'MyVideos77')
20:28:29 T:5516   ERROR: Unable to open database: MyVideos76 [1049](Unknown database 'MyVideos76')
20:28:29 T:5516 NOTICE: Old database found - updating from version 75 to 78
20:28:31 T:5516   ERROR: Unable to copy old database MyVideos75 to new version MyVideos78

Il s’agirait donc bien d’un problème MySQL. Je fais un petit tour dans les logs de MySQL :

cat /var/log/mysqld.log

La base de données des vidéos est corrompue.

Solution :

Lancer la réparation des tables posant problèmes. Se connecter à MySQL puis à la base de données :

mysql -u xbmc -p

USE MyVideos75 ;

Pour chaque table endommagée, lancer la commande :

REPAIR TABLE <table name>;

Dans mon cas, n’ayant pas envie de passer en revue toutes les tables, j’ai lancé une réparation de l’ensemble des tables de la base de données :

mysqlcheck--repair --database MyVideos75

Il est également possible de lancer une vérification et une réparation de toutes les tables pour l’ensemble des bases de données avec la commande :

mysqlcheck--repair --all-databases

Ça ne peut pas faire de mal. Choisissez donc la méthode qui vous convient. Suite à la réparation de la base de données, XBMC 13 beta4 a bien récupéré les informations de la base de données MyVideos75, et a créé la base de données MyVideos78.