Re: Crash MySQL

Page principale

Répondre à ce message
Auteur: Olivier Allard-Jacquin
Date:  
À: guilde
Sujet: Re: Crash MySQL
    Bonjour,

Le 05/02/2022 à 13:10, Marc BERLIOUX a écrit :
> Le 04/02/2022 à 17:15, Arnaud a écrit :
>> ..
>> Bonjour,
>>
>> 1 - ça peut très bien ne pas être grave du tout ;
>> 2 - si tu ne veux pas prendre de risques : sauvegarde ton
>> répertoire /var/lib/mysql/ au préalable à toute opération ;
>
> C'est ce que j'ai commencé par faire avant d'aller prendre l'air..
>
>> 3 - il y a une opération « REPAIR TABLE tatablecrashée; » dans MySQL, qui
>> devrait te remettre ta table en bon état ;
>> 4 - il y a d'autres opérations sur les tables : CHECK, ANALYZE, OPTIMIZE, elle
>> font des trucs aussi, le CHECK peut te réparer une table « marked as crashed »
>> aussi, pour les détails, je dirais RTFM...
>
> Après quelques bonnes bouffées d'oxygène et quelques recherches
> supplémentaires, j'ai aussi trouvé qu'il existait un drop-down menu pour
> faire ça depuis PhpMyAdmin.
>
> Cela dit, ça n'a pas fait réapparaître les entrées manquantes. Je ne
> sais toujours pas où elles sont passées, ni pourquoi elles n'ont pas été
> enregistrées immédiatement en dur. C'est d'autant plus bizarre que quand
> je crée ou modifie une tâche et que je l'enregistre, la base est
> immédiatement relue pour m'afficher les tâches du projet et je suis sûr
> que celles qui manquent se sont affichées. Si MySQL utilise un cache et
> n'enregistre pas immédiatement les données en dur dans les fichiers de
> la base,
>
> Merci en tous cas pour les conseils


    Il peut y avoir plusieurs raisons:
- le système de fichiers est corrompu, aussi un "fsck.ext4" doit 
corriger le problème, ou au moins t'indiquer qu'il y en a un.


Tes fichiers sont probablement sur la partition "/" qui est déjà montée,
donc tu dois jouer avec tune2fs, afin de forcer ta machine à faire une
vérification après le boot:

tune2fs -l /dev/sdaX|grep -i "mount count"
Mount count:              21
Maximum mount count:      40


La 2nd ligne indique après combien de montage la partition sera vérifiée
La 1ère ligne indique le nombre de montage depuis le dernier boot.

Ainsi, un "tune2fs -C 41 /dev/sdaX" va simuler le fait que la partition
ait été montée 41 fois, le fsck.ext4 sera lancé au prochain reboot.

Après modification, il faut rebooter la machine.


- le disque dur / SSD est physiquement corrompu.
Un "smartctrl -a /dev/sda" peut t'aider à y voir plus clair.


- Il y a eu un ou plusieurs arrêts brutaux de la machine, alors que des
données étaient dans la mémoire cache de la machine. Donc, les infos ont
étés définitivement perdues.

A noter que si ta machine est un laptop, que tu mets régulièrement en
suspend/standby (en fermant l'écran par exemple), ces mécanismes peuvent
échouer, et donc provoquer un "hard reboot" -> Corruption de la base de
données.


- en plus du cache software de Linux, tu as aussi des caches hardwares:
+ dans le disque dur lui-même
+ ou, si la machine en a une, dans une carte RAID hardware

Les trois caches sont supposées êtres vidées par la commande "sync".


> il va falloir que je trouve le moyen de faire un 'sync' d'une
> façon ou d'une autre pour ne plus rien perdre. RTFM donc..


while [ 1 ]; do sync; sleep 1m; done

    Cordialement,


                            Olivier
-- 
~~~~~~~  _____/\_____  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phoenix /   _ \/ _   \    Olivier Allard-Jacquin
        /   / \  / \   \   Web:  http://olivieraj.free.fr/
       /___/  /  \  \___\  Mail: olivieraj@???
~~~~ /////  ///\\\  \\\\\ ~~~~~~~~~~~~~~~~~~~~~~~ Linux Powered !!