MySQL probablement corrompu/ Impossible de dump

Mon serveur YunoHost

Matériel: Raspberry Pi 4 à la maison
Version de YunoHost: 4.0.8
J’ai accès à mon serveur : En SSH | Par la webadmin |…
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : oui
Si oui, expliquer:
Le problème est survenu juste après l’installation de Dolibarr (depuis désinstallé, et base mysql supprimée (fallait peut-être pas…)

Description du problème

Bonjour, et tout d’abord merci à ceux qui apportent du soutient aux utilisateurs de ce super outils qu’est Yunohost ! J’ai voulu installer Dolibarr hier, et ça a causé l’arrêt et l’impossibilité de redémarrer le service mysql, sur lequel repose entre autres Nextcloud, Gitea… J’ai pensé à une base corrompue, mais impossible de dump les données : quand je réussie d’une manière ou d’une autre à lancer le serveur SQL en mode safe, j’ai une erreur 2013 lors du dump. Y-a-t-il une issue à mon problème ? Je joins les logs :
https://paste.yunohost.org/esokobitok
Merci beaucoup,
Marin

Hmmokay visiblement la longueur du log de mysql n’est pas assez longue … Est-ce que tu peux faire manuellement un

journalctl -u mysql -n 200 --no-hostname --no-pager

?

(Si il râle que mysql n’existe pas, il faut peut-être mettre “mariadb” à la place)

Merci beaucoup pour la réponse !
J’ai mis là le log pour journalctl -u mariadb -n 200 --no-hostname --no-pager:
https://paste.yunohost.org/bapakusuca.sql

et là le log pour journalctl -u mysql -n 200 --no-hostname --no-pager
https://paste.yunohost.org/owifutobov.sql
A vrai dire, je ne comprends pas bien la différence entre les deux, j’ai tenté l’un et l’autre en alternant depuis que le problème est apparu

Mouaip, bizarre que le journalctl sur mysql retourne quelque chose … Tu peux faire un

dpkg --list | grep "mysql\|mariadb"

?

Aussi je vois dans le log de mariadb :

[Note] InnoDB: !!! innodb_force_recovery is set to 2 !!!

est-ce que ça te parle ? (par exemple est-ce que tu aurais bricolé la conf mariadb/mysql à la main ?)

Voilà ce que ça donne : https://paste.yunohost.org/alufagacoy.vbs

Et effectivement, j’ai suivi les manipulations en cas de base de donnée mysql corrompue, qui indiquent de modifier /etc/mysql/my.cnf et de rajouter innodb_force_recovery= 1, 2, ou 3 jusqu’à ce que le serveur démarre. Si je commente cette ligne là, journalctl -u mysql -n 200 --no-hostname --no-pagerdonne https://paste.yunohost.org/ifesozonic.erl
Merci beaucoup pour l’aide et bonne soirée,
Marin

Marf ben pas sur de savoir quoi faire … Je pige pas trop comment installer dolibarr a pu déclencher ça à moins que le système de fichier était déjà dans un mauvais état, ou bien un arrêt brutal en plein milieux de bricolage de base de donnée (et encore, c’est censé être un minimum robuste, transaction etc)

Du coup je sais pas trop quoi faire, ptete naivement essayer avec innodb_force_recovery avec des chiffres plus grand mais bon :[

Tu as l’ensemble du dump de toutes les apps ?

Parce qu’il serait peut être possible de repartir de zero pour mariadb

Bonjour et merci pour votre aide !
Effectivement je comprends pas non plus, c’est vraiment bizarre…
J’ai pas de dump SQL, j’y avais pas pensé je pensais que les sauvegardes Yunohost suffiraient. Bon et si on parle damage control, si je désinstalle les apps qui utilisent SQL, reinstalle mariadb puis les reinstalle, est-ce que je pourrais garder mes données (nextcloud) par exemple ?
Bonne journée,
Marin

Bon je pense que j’ai une nouvelle théorie pour l’explication : en essayant de supprimer quelque chose, j’ai eu une [Errno 117] Structure needs cleaning ce qui d’après internet est synonyme de données corrompues sur le disque… ça pourrait être le résultat d’une sous-alimentation du DD (sans alim externe) par le RPI. Je vais m’orienter vers l’achat d’un boitier permettant d’alimenter les DD, et certainement faire une clean install en récupérant utilisateurs et mails depuis une sauvegarde. Concernant les données Nextcloud, j’ai des sauvegardes de tout donc c’est pas d’une criticité extrême.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.