Bonjour,
Il faut regarder les logs dans /var/log/mysql/error.log
Je viens de tenter de relancer mysql comme cela je repère facilement tous les logs liés au redémarrage. Voici le résultat
2022-02-09 16:30:34 0 [Note] InnoDB: Uses event mutexes
2022-02-09 16:30:34 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2022-02-09 16:30:34 0 [Note] InnoDB: Number of pools: 1
2022-02-09 16:30:34 0 [Note] InnoDB: Using generic crc32 instructions
2022-02-09 16:30:34 0 [Note] mariadbd: O_TMPFILE is not supported on /tmp (disabling future attempts)
2022-02-09 16:30:34 0 [Note] InnoDB: Using Linux native AIO
2022-02-09 16:30:34 0 [Note] InnoDB: Initializing buffer pool, total size = 134217728, chunk size = 134217728
2022-02-09 16:30:34 0 [Note] InnoDB: Completed initialization of buffer pool
2022-02-09 16:30:34 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=2491278908,2491278908
2022-02-09 16:30:34 0 [ERROR] InnoDB: Malformed log record; set innodb_force_recovery=1 to ignore.
2022-02-09 16:30:34 0 [Note] InnoDB: Dump from the start of the mini-transaction (LSN=2491278912) to 100 bytes after the record: len 100; hex 6b6f1cb508000101d6c3000c00b3000056c3000c00a04b031c002f000000004c56e03e000001f9023704726f6f740203045a5eed4704397b226c616e67223a226672222c22636f6c6c6174696f6e5f636f6e6e656374696f6e223a22757466386d62345f; asc ko V K / LV > 7 root Z^ G 9{"lang":"fr","collation_connection":"utf8mb4_;
2022-02-09 16:30:34 0 [Warning] InnoDB: Log scan aborted at LSN 2491343872
2022-02-09 16:30:34 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
2022-02-09 16:30:34 0 [Note] InnoDB: Starting shutdown...
2022-02-09 16:30:34 0 [ERROR] Plugin 'InnoDB' init function returned error.
2022-02-09 16:30:34 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2022-02-09 16:30:34 0 [Note] Plugin 'FEEDBACK' is disabled.
2022-02-09 16:30:34 0 [ERROR] Unknown/unsupported storage engine: InnoDB
2022-02-09 16:30:34 0 [ERROR] Aborting
Je suppose, d’après cette partie qu’il y a un problème de log
[ERROR] InnoDB: Malformed log record; set innodb_force_recovery=1 to ignore.
Donc si j’arrive à vider le log pour repartir sur un fichier vierge ça devrait être bon. En même temps, c’est surprenant que le ignore ne suffise pas.
Une question du coup. Y a t il d’autres logs que ceux dans /var/log/mysql/ , Ou suffirait-il de les effacer? Avez-vous une opinion? Je vais renomer le dossier mysql en mysql-back pour essayer, mais je ne voudrais pas qu’il y ait des conséquences à long terme…
Mon test de renomer le fichier des logs pour forcer le départ sur un fichier vierge ne marche pas…
Il y a aussi le message suivant qui me surprend.
mariadbd: O_TMPFILE is not supported on /tmp (disabling future attempts)Cette erreur ne concerne pas le fichier de log au sens où tu l’entends mais indique une corruption des données.
Il faut ajouter innodb_force_recovery = 1 sous la section [mysqld] de ton fichier /etc/mysql/mariadb.conf.d/50-server.cnf
Redémarrer le service, et suivre la procédure indiquée en bas du document en lien « Fixing things »
C’est juste une information pas une erreur. Probablement parce que tu as monté /tmp en tmpfs Cela n’empêche pas mariadb de fonctionner.
Merci, J’essaye ça… En espérant que le niveau 2 suffira.
Clairement c’est insufisant, ou c’est que j’ai mal fait.
Voici ce que j’ai mis:
# this is only for the mysqld standalone daemon
[mysqld]
innodb_force_recovery = 1
#
# * Basic Settings
#
Peux-tu me confirmer que je ne fais pas de bêtise?
Oui, mais Discourse gère les fuseau horaire et c’est lui qui indique l’heure à laquelle le message est publié, du coup, ta troisième solution n’est pas possible. Vérifie quand même que ta machine est bien à l’heure (ou que tu n’utilises pas une connexion IPoT).
Je suis en chine, donc j’utilise en VPN pour pouvoir me connecter au site, Je pense que ça perturbe Discourse qui se trompe sur mon lieu réel…
C’est correct. Est-ce que tu as toujours les mes erreurs dans les logs (error.log) avec les valeurs 1 et 2 ?
Est-ce que tu as une sauvegarde logique (dump) de tes bases de données ?
Oui, même chose jusqu’au niveau 4. Je pense que c’est bien cassé.
Je n’avais pas de sauvergarde car juste pour jouer un peu. Je dois bien avoir quelque vielles sauvegardes, mais rien de bien fondamental. Je vais juste perdre le setting de quelques vieux projets.
Je suppose que le plus simple est de purger Mariadb et de reinstaller complètement…
As tu une autre proposition?
Je te propose de supprimer les fichiers suivants (en root ou avec sudo):
rm -i /var/lib/mysql/ib*"
puis de tenter un démarrage de mariadb.
EDIT : Dans ce message, je persistais dans mon erreur de conversion de fuseaux horaires, donc, ne pas tenir compte de ce message.
J’en conclu que ton message d’erreur a été créé sur ta machine dans le futur.
timedatectl
Je n’ai pas suivi cette histoire de problème de date, mais c’est une piste pour expliquer la corruption de la base de données. Donc à éclaircir.
Il y a une confusion dans l’horaire et les timezones.
CST Chine Standard Time est effectivement UTC+8
Donc UTC est 8 heures de moins que CST
Donc Mercredi 11:17 CST est Mercredi 03:17 UTC
Je vous assure qu’en ce moment il est bien 20:40 à Shanghai alors que c’est l’après midi en France…
Merci, je ne sais pas ce qu’étaient ces fichiers, mais ça m’a régler le problème.
J’ai perdu quelques infos, mais pas tant que çà. Juste la base de données de mon dernier projet que j’avais fait cette semaine. En gros, les changement de la dernière semaine.
Par contre ça m’a bloqué la possibilité de sauvegardes de phpmyadmin. Il faudra que je regarde ça demain.
En tout cas, un grand merci!
Effectivement , désolé pour la confusion des fuseaux horaires 
Mon message corrigé :
Dans un des messages d’erreur que tu nous as copié/collé,
on peut lire une date/heure basée sur le fuseau horaire (CST <=> UTC+8)
Wed 2022-02-09 11:17:53 CST
dont la date/heure équivalente en heure UTC est :
Mercredi 9 février 2022 03:17:53 UTC
et la date/heure équivalente en France est :
Mercredi 9 février 2022 04:17:53 CET
ton message a été reçu sur ce forum le :
Mercredi 9 février 2022 à 04:41 CET
Cela peut sans doute se régler en purgeant et réinstallant phpmyadmin ou simplement avec :
dpkg-reconfigure phpmyadmin
en acceptant la re-création de la base phpmyadmin.
Sinon, les sauvegardes cela se fait avec mysqldump. Phpmyadmin c’est juste bon à faire des bricolages à distance quand on a pas d’autre moyen d’accéder à MySQL.
Bonjour,
La base était plus cassée que je ne le pensais. J’ai du tout réinstaller…
Pas grave, mais je ne sais toujours pas ce qui c’est passé pour que Maria se casse…
J’ai fait de la perceuse pas loin du serveur ? une surtension?
Aucune idée, mais tout est de nouveau opérationel
La corruption des fichiers de la base de données cela peut arriver : coupure brusque de l’alimentation, erreur disque, etc.
C’est pour cela qu’il faut avoir une tâche planifiée (cron ou tilmer systemd) qui fait régulièrement des sauvegardes logiques avec mysqldump. Pour les flemmards il y a automysqlbackup.
1 J'aime