Matériel: Raspberry Pi Version de YunoHost: 3.7.0.12 J’ai accès à mon serveur : En SSH Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : ne sais pas
Description du problème
Depuis ce dimanche matin, mon serveur est inaccessible via le web.
Je me suis rendu compte que le service Mysql/Mariadb ne tournait plus. Avec un message d’erreur lié à une table de FreshRSS. Les détails sont ici: https://github.com/YunoHost-Apps/freshrss_ynh/issues/94
Après suppression de cette table pour tester, on me dit que ça ressemble à un problème avec le stockage.
Hors la base de données est sur la carte SD (j’ai un disque dur en plus, pour certaines données). Et la fiabilité des cartes SD étant ce qu’elle est…
Il semble donc qu’il me faille la changer.
Problème: je ne peux pas faire de sauvegarde de FreshRSS, Wallabag et Nextcloud (ce dernier étant le plus embêtant), vu que la base de données est inaccessible.
De plus, le plantage semble avoir eu lieu pendant ma sauvegarde hebdomadaire, dans la nuit de dimanche…
—> Je cherche donc une technique pour sauvegarder la base de donnée sans devoir démarrer le serveur mysql.
Sachant que je vais devoir copier le contenu de la carte SD (si elle tiens le coup jusque là…) sur une autre, pour ganier du temps pour remonter le serveur. Je ne suis pas sûr que ça permette aussi de migrer les données dans mysql… si ?
Question subsidiaire: je me demande à quel point il est possible de “juste” restaurer les sauvegardes précédentes sur ce serveur là, alors que la base Mysql semble cassée, et que le service ne tourne pas.
Dans quelle mesure il serait possible de restaurer des applications, y compris utilisant la base mysql ? En supprimant l’actuelle, pour restaurer tout par dessus ?
Comment c’est géré sur Yunohost ? Tout est dans la même base, ou je peux supprimer celle de FreshRSS sans toucher au reste ?
Si MariaDb est vraiment cassé, c’est à dire qu’un systemctl restart mysql ne fonctionne pas, il faudra réparer mysql avant de restaurer les sauvegardes (sauf réinstallation complète du serveur évidement).
Il existe un script de réparation de mysql. Je sais qu’il a été amélioré récemment, peut être peut il réparer ta base de donnée. Ping @Aleks ?
Par contre je ne sais pas si supprimer /var/lib/mysql/freshrss était une bonne idée…
Quels messages de log as-tu quand tu essaies de redémarrer mariadb ?
Par contre je ne sais pas si supprimer /var/lib/mysql/freshrss était une bonne idée…
Je ne l’ai pas encore fait, j’attends plus d’info avant
Par contre j’ai supprimé pour le test le fichier qui correspond à la table problématique (en gardant une copie). Le message d’erreur a changé (cf. le ticket sur github).
Après restauration de la sauvegarde, l’erreur ne revient pas à ce quelle était avant
[ERROR] InnoDB: Space id and page n:o stored in the page read in are 2182:14168, should be 0:469!
InnoDB: Assertion failure in thread 1995792176 in file fut0lst.ic line 83
Miam les messages d’erreur de mysql/mariadb, c’est toujours un plaisir … J’pige pas trop ce qu’il se passe mais naivement ca ressemble a une corruption (au moins partielle). Mais je comprends pas assez mysql pour savoir si c’est juste une base ou si c’est un bidule “central” qui est cassé ou quoi …
edit: à l’origine la première erreur venait d’une base de FreshRSS (en plus pas importante, la table pourrait être supprimée sans conséquence… enfin, avec un serveur mysql qui tourne)
Je l’ai déjà fait, mais ça ne marche pas à tous les coups.
Idéalement quand on fait ça il faut éteindre le mysql avant, à chaud ça n’a jamais marché pour moi.
Mais vu que là ton service est en rade peut être que ce serait bon…
Ah ben là il ne peut plus démarrer, du coup je suis tranquille
Je voudrais tenter de faire une copie complète du système ailleurs (via dd), pour voir si ça peut me garder quelques trucs sans avoir à tout réinstaller/reconfigurer, quitte à devoir péter la base Mysql après pour restaurer mes sauvegardes d’applications.
J’ai essayé, mais je ne sais pas si ça n’a rien fait ou si elle n’était pas active: en modifiant /etc/mysql/my.cnf pour y ajouter ce paramètre, jusqu’à une valeur de 3, aucun effet apparent.
J’ai deux fichiers qui posent des problèmes: pseudo_entrytmp.ibd (celui de ma première erreur affichée quand j’ai eu le problème était liée à ce fichier) avec ça:
Du nouveau: j’ai réussi à restaurer partiellement mon système.
En suivant cette méthode (partie 1): https://support.plesk.com/hc/en-us/articles/213939865-How-to-fix-InnoDB-corruption-cases-for-the-MySQL-databases-on-Plesk-for-Linux-
J’ai dû monter innodb_force_recovery à 4, et là j’ai pu démarrer MySQL et faire des dump de la base de donnée (en suivant les commandes de l’article, adaptées à Yunohost,en regardant les fichiers de backup des applications pour savoir quelle commande utiliser).
J’ai ensuite réimporté ces bases comme proposé. Mysql fonctionnait, mais ni FreshRSS, ni Wallabag, ni Nextcloud. Ensuite j’ai pu supprimer FreshRSS et Wallabag, puis restaurer des sauvegardes, ça refonctionne
Par contre, pas Nextcloud (pas si étonnant, il est plus complexe ).
J’ai pu le supprimer.
Mais je n’avais qu’une sauvegarde de la version 15, avant mise à jour en 18. Je n’ai pas eu la présence d’esprit d’en faire une après.
Peut-être que c’est ça qui pose problème, quoiqu’il ne fonctionnait pas plus avant suppression (de la version 18 plantée à cause de Mysql).
En regardant les logs, j’ai une erreur:
An exception occurred while executing ‘SELECT * FROM oc_appconfig’:
Base table or view not found: 1146 Table ‘nextcloud.oc_appconfig’ doesn’t exist
Renversement de situation…
Une personne a eu la bonne idée de me proposer d’utiliser occ maintenance:repair pour réparer la base de donnée…
Et en l’utilisant (sudo -u nextcloud php7.0 occ maintenance:repair), je me suis aperçu de plusieurs erreurs.
D’abord je me suis trompé et j’ai utilisé php7.3 (alors que j’étais retourné en version 15 de Nextcloud, qui utilise php7.0). Il m’a affiché une erreur par rapport à un fichier log de Nextcloud, problème de droits, corrigé.
Le paquet php-7.0-zip n’était plus installé (la faute au passage de 15 à 18 je suppose), il a fallut le faire. Par chance la page d’accueil de Nextcloud l’indiquait.
Et ensuite, il m’indiquait que le dossier de données était invalide, qu’il manquait le fichier .ocdata. Et effectivement, il n’était pas dans le dossier /nextcloud/data mais dans /nextcloud… pourquoi, aucune idée.
Maintenant le client remarche, la connexion via l’interface web non.
On progresse
edit: eeeeeetttt… une opération de maintenance:repair plus tard, hop j’ai accès à tout, ça refonctionne !
Merci pour votre aide , en espérant que ça serve à d’autres
).
