Version française plus bas.
My YunoHost configuration
Hardware: rpi 3
Internet access: ethernet at home
installed apps: nextcloud
YunoHost version:
yunohost: 2.7.9 (stable)
yunohost-admin: 2.7.7 (stable)
moulinette: 2.7.7 (stable)
ssowat: 2.7.7 (stable)
Have you personalized your yunohost with some specifics configurations or do you use only the yunohost cli/webadmin tool ? basic
Description of my problem
This week-end, I’ve launched a occ scan with this command: sudo -u nextcloud php occ files:scan --all because nextcloud didn’t update external storage changes. After a long long time (several hours), mariadb crashed and was unable to start again.
After investigations, I was able to start mariadb with the option “innodb_force_recovery = 5” into “my.cnf” as decribed here
(All other lower values were not enough to start mariadb).
So first of all I made mysqldump of my databases and then I launched a mysqlcheck to find the corrupted tables.
It found that the table called “oc_filecache” in the nexcloud database was corrupted.
Some infos on the web say that it would be possible to solve this by truncate or dropping the table and re-create it before pushing the mysqldump backup.
The problem is that the database is in “read-only” mode (which is normal with the option “innodb_force_recovery = 5”).
So I cannot truncate the table, but I cannot drop it too (which is not normal, according to the mariadb documentation).
I’m not very familiar with mysql/mariadb and I don’t know what to do without making a terrible mistake to solve my problem…
Thanks a lot for your help.
Configuration de mon YunoHost
Matériel: rpi 3
Accès Internet: ethernet à la maison
Applications installées: nextcloud
YunoHost version:
yunohost: 2.7.9 (stable)
yunohost-admin: 2.7.7 (stable)
moulinette: 2.7.7 (stable)
ssowat: 2.7.7 (stable)
As tu modifié ton yunohost avec des configuration spécifiques ou bien utilise tu uniquement la web administration et/ou la ligne de commande yunohost ? basique
Description de mon problème
Ce week-end, j’ai lancé un scan nextcloud avec la commande sudo -u nextcloud php occ files:scan --all car nextcloud ne parvenait pas à actualiser le contenu d’un stockage externe. Après plusieurs heures, mariadb a violemment planté et ne pouvait plus démarrer.
Après plusieurs recherches, j’ai pu redémarrer mariadb avec la directive “innodb_force_recovery = 5” dans le fichier “my.cnf” comme décrit ici
(J’ai d’abord testé progressivement avec des valeurs inférieures à 5 mais mariadb refusait toujours de démarrer).
Donc, une fois mariadb redémarré, j’ai immédiatement fais un dump mysql de mes bases. Puis j’ai lancé un check mysql pour trouver la/les table(s) corrompues.
La table “oc_filecache” de la base de données nextcloud était la seule corrompue.
Des infos sur le web indiquent que l’on peut résoudre le problème en faisant un truncate ou un drop table puis un create table avant de réinjecter le dump mysql.
Le problème, c’est que la base de données est en lecture seule (étant donné que mariadb tourne avec l’option "innodb_force_recovery = 5)
Je ne peux donc pas faire un truncate (ça c’est normal) mais pas non plus un drop table (ça ça semble moins normal, puisque la doc officielle de mariadb indique que ça devrait être possible).
Je ne suis pas très à l’aise avec mysql/mariadb et je ne voudrai pas commettre l’irréparable. Si vous avec une idée pour remettre en service mon nextcloud, je suis preneur.
Merci d’avance pour votre aide.
Version française plus bas.
So finnaly, after long long seaches, I solved my problem with mariadb corrupted table with this method (not very clean but it has worked):
-
stop mariadb service: systemctl stop mysql.service
-
move mysql data dir to a safe place: mv /var/lib/mysql /var/lib/mysql-backup
-
edit /etc/mysql/my.cnf and comment the line innodb_force_recovery = 5
-
start mariadb service: systemctl start mysql.service
mariadb should start normally
-
connect to mysql: mysql -u root -pYOUR_MYSQL_ROOT_PASSWORD (stored in /etc/yunohost/mysql)
-
create nextcloud database: create database nextcloud; (don’t forget the ; at the end of the line)
-
quit mysql: exit
-
restore the nextcloud database dump: mysql -u root -pYOUR_MYSQL_ROOT_PASSWORD nextcloud < /path_to_your_nextcloud_dump.sql
-
connect to mysql: mysql -u root -pYOUR_MYSQL_ROOT_PASSWORD
-
empty the faulty table: truncate nextcloud.oc_filecache;
-
quit mysql: exit
-
check all the tables in all the databases: mysqlcheck -u root -pYOUR_MYSQL_ROOT_PASSWORD --all-databases
all of the tables should be ok!
- connect to your nextcloud web interface: ok
Bon finalement, j’ai réussi à m’en sortir avec la table corrompue dans la base nextcloud, en utilisant la méthode suivante (un peu bourrine, mais ça marche):
-
arrêt du service mariadb: systemctl stop mysql.service
-
déplacement du répertoire de stockage de mysql: mv /var/lib/mysql /var/lib/mysql-backup
-
editer /etc/mysql/my.cnf et commenter la ligne innodb_force_recovery = 5
-
démarrage de mariadb: systemctl start mysql.service
mariadb devrait démarrer correctement
-
se connecter à mysql: mysql -u root -pVOTRE_MOT_DE_PASSE_ROOT_MYSQL (stocké dans /etc/yunohost/mysql)
-
Créer la base de données nextcloud: create database nextcloud; (ne pas oublier le ; en fin de ligne)
-
quitter mysql: exit
-
restaurer le dump de la base nextcloud: mysql -u root -pVOTRE_MOT_DE_PASSE_ROOT_MYSQL nextcloud < /path_to_your_nextcloud_dump.sql
-
se connecter à mysql: mysql -u root -pVOTRE_MOT_DE_PASSE_ROOT_MYSQL (stocké dans /etc/yunohost/mysql)
-
vider la table corrompue: truncate nextcloud.oc_filecache;
-
quitter mysql: exit
-
vérification de toutes les tables dans toutes les bases présentes: mysqlcheck -u root -pVOTRE_MOT_DE_PASSE_ROOT_MYSQL --all-databases
Normalement, toutes les tables doivent avoir le statut “ok”
-
connexion à l’interface web de nextcloud: ok
2 Likes
Update
I’ve found two small issues since my nextcloud resurection:
-
creation/edition/deletion of txt files became very, very slow
-
deleted files for the admin user (and only this user) don’t go to the trashbin.
For the moment, I don’t know how to solve this (nothing useful found in logs).
If you have ideas…
To be continued…
Mise à jour
J’ai trouvé deux petits bugs depuis la résurrection de mon nextcloud:
-
La création/édition/suppression de fichiers .txt est devenue très très lente
-
les fichiers supprimés par l’utilisateur administrateur (et seulement pour celui-ci) ne vont pas dans les fichiers supprimés (et sont donc du coup totalement supprimés)
Pour le moment, je n’ai pas trouvé de solution pour résoudre ce problème (rien de spécial au niveau des logs)
Si vous avez des idées, je suis preneur.
Affaire à suivre…
update 2
I’ve found the solution for the txt files problem: I’ve lauched an update of the mimetypes
Now the creation/edition of txt files are as fast as before
But no solution yet for the trashbin problem…
Mise à jour 2
J’ai trouvé la solution au problème de lenteur à la création/édition de fichiers .txt: j’ai lancé une mise à jour des types mimes
Par contre, je n’ai toujours pas trouvé de solution pour les fichiers supprimés…
update 3
Obviously, it seems that running occ files:scan --all can sometimes corrupt the nextcloud oc_filecache mysql table: https://help.nextcloud.com/t/what-does-occ-file-scan-all-actually-do-with-oc-filecache/1909
That’s exactly what it does on my nextcloud instance. So be careful with this command!
Mise à jour 3
Apparemment, il semblerait que parfois la commande occ files:scan --all aie pour effet une corruption de la table oc_filecache de la base nextcloud: https://help.nextcloud.com/t/what-does-occ-file-scan-all-actually-do-with-oc-filecache/1909
C’est exactement ce qui m’est arrivé, donc attention avec cette commande!
Question:
I recently set a nextcloud instance on my new raspberry pi. I chose to use the mariadb for database. And i started transfering all my existing fliles from my dropbox to nextcloud via the nextcloud desktop client. i was working fine for few days (transfers was quite long though) but i woke up this morning and db crashed completly. Impossible to restart. I went quick into the logs and i saw oc_filecache corrupted too.
But i didnt ran any occ command. It just crashed on its own after high volume of files upload.
Do you think it is the same issue and is there any known issue arround nextcloud?
Question:
J’ai récemment installé instance nextcloud sur mon nouveau raspberry pi. J’ai choisi d’utiliser mariadb pour la base de données. Et j’ai commencé à transférer tous mes fichiers existants de ma dropbox t à nextcloud via le client de bureau nextcloud. Tout a parfaitement fonctionné pour quelques jours (le transfert étaient assez longs cependant vu qu’il y avait énormément de fichier a copier) mais je me suis réveillé ce matin et mariadb était complètement planté. Impossible de redémarrer. Je suis allé rapidement dans les lgos et j’ai vu oc_filecache corrompu aussi.
Mais je n’ai pas exécuté de commande occ. La Db a craché toute seul après un important volume de fichiers téléchargés.
Pensez-vous que c’est le même problème et y a-t-il des problèmes connus avec nextcloud sur ce sujet?
Salut à toi.
Oui je pense que c’est le même problème: lorsque tout à coup Nextcloud a beaucoup de fichiers à indexer en base, le raspberry ne supporte pas la charge et crashe avant la fin de l’indexation.
Il en résulte une corruption de la table oc_filecache et l’impossibilité de redémarrer mariadb.
La commande occ que j’avais lancé sert à effectuer la réindexation en base de tous les fichiers de ton instance. Si les fichiers sont nombreux (dans mon cas, plus de 500 Go de données sur un stockage externe déclaré dans nextcloud), on sature la RAM au bout d’un moment et on corrompt la table oc_filecache de la base de données nextcloud.
Je ne sais pas si c’est un problème connu, mais en tout cas, c’est un problème réel puisque tu as pu le reproduire!
En tout cas, n’hésite pas à revenir vers moi si tu as besoin d’aide.
Bon courage, ce sont des moments assez stressant…
1 Like
Un gros merci pour la rapidité de ta réponse.
Effectivement c’était la douche froide ce matin en découvrant cela avant de partir au travail.
Par soucis de “data privacy” j’ai décider de me débarrasser de services type dropdox et d’héberger mon propre data mais je commence a mesuré l’impact du “DIY” 
Comme toi j’ai transférer a peut prêt 450GB de données.
Je n’ai pas accès au PI tout de suite mais ce soir je prévois d’essayer ton fix. (je crois les doigts pour que le innodb_force_recovory = 5 fonctionne)
quoi qu’il arrive je reposterais ici pour annoncer la couleur
Merci
Bon voici le resultat de mes premières investigations.
Avec le innob_force_recovery = 5 j’ai pu finalement redemarré mariadb.
Premier problème auquel je fais fasse est que je ne peux pas utiliser le dump sur la base.
"Get error 1932:“Table ‘owncloud.oc_activity’ doesn’t exist in engine when using LOCK TABLES”
Deuxieme chose quand je lance un status sur les tables je peux voir qu’il y a deux tables qui posent problèmes:
activity et filecache.
Je ne suis pas certain des prochaines étapes a essayer et si il y a une des commande occ qui pourrait m’aider au moins pour faire le dump et essayer ta méthode.
Merci pour ton aide.
Edit:
J’ai trouver du mon qui dit que je pourrais peut être dropper les deux table directement et utiliser le occ maintenance:repair.
Seulement sur la doc officiel ils parlent de clean up database. Je sais pas si ça vraiment recréer les tables manquantes.
Bon.
J’ai tenté le dump en skippant les deux table.
Je peux confirmer aujourd’hui que maintenance:repair ne recréer pas les tables manquantes.
Mon seul dernier espoir est de pouvoir peut être recréer c’est deux tables manuellement mais même en regardant le code source je n’ai pas encore trouvé le schéma des deux tables.
Je ne sais plus quoi essayer d’autre.
Salut à toi,
As-tu des backup yunohost de côté?
Si c’est le cas, Il y a normalement un dump de la base nextcloud (contenant toutes les tables valides) que tu pourras restaurer.
C’est ça qui est drôle c’est que je post sur ce forum mais je n’utilise pas du tout yunohost.
Seulement nextcloud.
Comment avait tu réussi a faire un dump avec ta table corrompu?
Tu n’as pas eu a passer d’option particulière?
Merci.
Ok, bon si je comprends bien, tu n’as donc pour le moment aucun dump complet stocké quelque part, et tu ne peux pas en réaliser un une fois mariadb redémarré (si ce n’est en excluant les tables corrompues). C’est bien ça?
De mémoire, même avec ma table oc_filecache corrompue, j’avais pu effectuer un dump de la base nextcloud sans option particulière.
Une solution envisageable (mais pas sûr que ça marche), serait que je t’envoie un dump de mes tables oc_filecache et oc_activity que tu réinjecterai après avoir restauré ton dump incomplet.
Voici, étape par étape, la méthode que je te propose:
-
tu démarres mariadb avec innodb_force_recovery = 5
-
tu fais un dump de ta base nextcloud en excluant les tables oc_activity et oc_filecache
-
tu suis ma procédure rédigée plus haut ( le 21 mars) jusqu’à “restaurer le dump de la baser nextcloud” inclus
-
tu réinjecte les deux dumps que je t’aurai transmis
-
tu vides les deux tables oc_filecache et oc_activity en faisant un truncate
-
tu lances un mysqlcheck pour vérifier que tout est ok
Encore une fois, je ne suis pas sûr que ça fonctionne, mais au point où tu en es, ça vaudrait le coup d’essayer.
Qu’en penses-tu?
PS: si un expert mysql/mariadb passe par là, qu’il n’hésite pas à infirmer ou confirmer ma solution…
Oui jsuis ultra partant pour ta solution.
J’ai même posté sur le forum officiel de nextcloud sans success pour avoir le schema original des deux tables.
J’ai trouvé dans le code source du code php qui semble creer la table mais sans donne vraiment pas envie…
https://imgur.com/QsNbePF
Dans les étapes que tu as listé je suis bloqué l’étape 6 depuis le week end dernier.
J’ai réussi a faire un dump mais un skipant les deux tables. J’ai effacer et réinitialiser et répertoire data de mariadb et j’ai tenté la commande occ maintenance :repair mais ça n’a pas eu pour effet de recréer les tables manquante.
PS: Je te remercie pour tes réponses c’est vraiment apprécié
ok, je vais faire un dump des deux tables et je te transmets ça ensuite
1 Like
c’est bon, je viens de t’envoyer des liens par message privé pour que tu récupère les dumps.
Gros merci je te tiens au courant.
Cool de voir que tes liens proviennent de nextcloud 
Bonne nouvelle ça a fonctionné!
J’ai récupéré tes fichiers et j’ai édité le sql pour que ça crée seulement la table sans données. (pas de truncate a faire)
J’ai une question cependant. As tu fait quelques chose de particulier à la table pour éviter que ça arrive de nouveaux.
Car je peux voir que mon nextcloud mouline pour récupérer la taille des répertoires et j’ai peur que ça arrive de nouveaux (j’vais me mettre une routine pour faire un backup de la db tous les jours)
Dans tous les cas je vais condenser tout ça demain et poster la solution complète dans les deux langues. Pour que ça profite à d’autres qui j’en suis sure feront fasse au problème.
Un gros merci à toi
Content d’avoir pu t’aider!
Pour répondre à ta question, la seule chose particulière que j’ai fais pour que ça n’arrive plus, c’est de déconnecter mon stockage externe 
Je dois reconnaître que j’ai un peu peur de le reconnecter…
Sinon, oui, c’est une bonne idée que de planifier une tache cron pour faire un mysqldump quotidien.
Je ne peux que t’inciter à mettre ça en place, ça facilite grandement la réparation d’une base corrompue.
Et enfin, très bonne idée également de poster ta solution: ça ne peut que profiter à la communauté.
A bientôt.
Bon,
La database n’a pas tenu une journée et a crasher encore mais cette fois le recovery 5 ni fait rien.
J’ai des backup mais cette fois mais j’abandonne le coté nextcloud qui me parait trop fragile pour un gros volume de données (ce qui est un peu paradoxale pour un système de cloud). Je veux pas avoir cette épée de Damoclès au dessus de la tête.
Je te conseille vivement de faire un cron pour faire des dump mais également une back de ton /lin/mysql car cette deuxième fois c’est ça qui est corrompus de mon coté.
Jvais poster toute mon aventure sur le forum nextcloud et espérant que le problème soit régler. Meme si en effet le raspberry peut être un peu limite en terme de hardware ce genre de chose ne devrait pas arriver au point de complètement corrompre la base de données.
A bientôt.