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 !!
