Le service mysql ne demarre plus

Salut,

c’est probablement un problème de corruption mysql oui :confused:

Tu peux confirmer ça en regardant ce que renvoie : tail /var/lib/mysql/*.err

Ensuite, si tu es à l’aise avec l’anglais, quelqu’un vient justement de pondre un fil de documentation sur ce type de problème : How to recover from corrupted mysql

Salut,
Effectivement j’ai eu un problème similaire ce week-end.
Je peux t’aider si besoin pour le dépannage.
Ce lien aussi pourrait intéresser : https://wiki.labriqueinter.net/doku.php?id=howto:fix_self_corrupt_mysql

Merci beaucoup pour vos réponses, voila ce que me renvoie la commande:
root@YunoHost:~# tail /var//lib/mysql/*.err
180212 16:55:34 [Note] InnoDB: The log sequence numbers 334108936 and 334108936 in ibdata files do not match the log sequence number 344433263 in the ib_logfiles!
180212 16:55:34 [Note] InnoDB: Restoring possible half-written data pages from the doublewrite buffer…
180212 16:55:35 [Note] InnoDB: 128 rollback segment(s) are active.
180212 16:55:35 [Note] InnoDB: Waiting for purge to start
180212 16:55:35 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.36-82.1 started; log sequence number 344433263
180212 16:55:35 [Note] Plugin ‘FEEDBACK’ is disabled.
180212 16:55:35 [ERROR] Can’t open the mysql.plugin table. Please run mysql_upgrade to create it.
180212 16:55:35 [Note] Server socket created on IP: ‘::’.
180212 16:55:35 [ERROR] Fatal error: Can’t open and lock privilege tables: Incorrect file format 'host’
180212 16:55:35 mysqld_safe mysqld from pid file /var/lib/mysql/YunoHost.pid ended

J’espère vraiment ne pas avoir perdu mes bases mysql

Ca serais super sympa si tu peu m’aider a remettre tout ca en ordre, je suis preneur.

Hello @Doudou170,

Je t’ai envoyé un message privé pour t’aider à remettre tout ça en route.

1 Like

Pour moi c’est l’emmerde de trop avec yunohost. Je l’utiliser depuis 4 ans environ mais la y’en a marre.
Je souhaiterais récupérer mes données Dolibarr et ensuite je change de système. Vu qu’il y a plusieurs personne qui on le même souci que moi, je ne pense pas que l’erreur viens de chez moi.

Hey, vas y molo! Yunohost est un projet bénévole mené par des développeurs passionnés, soucieux de proposer une solution auto-hébergée la plus “clés en mains” possible. C’est un projet ambitieux et semé d’embuches (l’auto hébergement en général est lui même un projet semé d’embuches), mais pour moi, il vaut vraiment le coup.
J’ai eu hier soir exactement le même souci que toi avec mysql.
J’ai passé toute ma soirée à remettre le service d’aplomb grâce aux deux liens proposés en premières réponses à ton post.
ça demande un peu de connaissances linux/mysql (mais rien d’insurmontable), et c’est comme ça qu’on apprend :face_with_raised_eyebrow:
De plus, tes problèmes auraient pu être rapidement réglés si tu avais mis en place une solution de sauvegarde de TOUT ton système: tu n’aurais eu qu’à effectuer une restauration.
Bon courage et n’hésite pas à faire appel au forum si tu as besoin d’aide.

PS: je ne suis qu’un simple utilisateur de yunohost.

2 Likes

@Doudou170 : Salut !
Ne critique pas tant Yunohost. Ton problème aurait et pourrait arriver dans n’importe quel système. Ce n’est pas rattaché à Yunohost.

De plus, réparer une corruption dans mysql est faisable. J’ai eu moi aussi un problème avec mysql, et d’ailleurs tout était corrompu, même phpmyadmin. J’ai dû passé une après midi à tout réparer. Mais je l’ai fait et comme le dit @Benance, j’ai beaucoup appris. Les deux liens présent dans les 1er et 2e post aident beaucoup par ailleurs.

Ensuite, normalement, les sauvegardes sont très importantes quand tu as un serveur de production. Encore une fois, c’est pareil sur tous les systèmes… il est juste plus facile de faire une sauvegarde dans Yunohost que de faire une suite de 200 commandes pour sauvegarder chaque fichier du système quand tu fais tout à la main.

Pour redire ce que @Benance a déjà dit :wink: :
Yunohost est en effet un projet bénévole, mais je dirais même communautaire. C’est à dire que c’est la communauté présente ici qui fait vivre Yunohost. Chaque personne peut contribuer à Yunohost. Si tu penses qu’on peut améliorer quelque chose, tu peux le demander et peut-être que plusieurs personnes essaieront d’améliorer le projet dans ce sens. Rien n’est perdu, et je ne pense pas que c’est passer de projet en projet, de solution en solution, de système en système que les utilisateurs vont pouvoir faire progresser Yunohost.

frju365

1 Like

Je comprend votre position, et je m’excuse d’avoir critiqué sous le coup de la colère.
Mais au final, ça ne change pas le problème pour moi. Je ne compte pas me taper 2 plombe de ligne de commande pour une histoire de base sql. Je ne peut pas en vouloir a la communauté Yunohost, vous m’avez aidé plusieurs fois quand j’en est eu besoin. J’aurais en effet du mettre en place une sauvegarde complète de mon Yuno mais je ne savais pas comment faire. En effet, ce n’est pas une solution de passer de projet en projet mais yunohost a perdu ma confiance et je vous souhaite a tous bonne continuation.

Le plus important pour moi est de récupérer Dolibarr. Comment récupérer mes données svp?

Bonjour @Doudou170 ,

Je ne connais pas Dolibarr et, n’étant qu’un simple utilisateur “avancé”, je ne connaîs pas grand chose sur le fonctionnement d’une base de données.
Bref, ceci dit, et en fonction de l’accès que tu peux encore avoir, peut-être que ces liens pourraient t’aider afin de récupérer tes données :
https://wiki.dolibarr.org/index.php/Module_Exports
https://wiki.dolibarr.org/index.php/Sauvegardes

ppr

Bonjour
J’ai je pense le même souci que présenté ici, le service mysql ne démarre plus.

J’ai bien trouvé un topic qui explique comment faire, mais je ne m’y connais pas assez et j’ai peur d’altérer quelque chose sans faire exprès…

Quelqu’un pourrait me donner une marche à suivre ?

Merci d’avance.

Je précise que la commande systemctl status mysql.service
me donne

/etc/init.d/mysql[9489]: 0 processes alive and '/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping' resulted in
/etc/init.d/mysql[9489]: [61B blob data]
/etc/init.d/mysql[9489]: error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)'
/etc/init.d/mysql[9489]: Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!
/etc/init.d/mysql[9489]: 
mysql[8630]: Starting MySQL database server: mysqld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . failed!
systemd[1]: mysql.service: control process exited, code=exited status=1
systemd[1]: Failed to start LSB: Start and stop the mysql database server daemon.
systemd[1]: Unit mysql.service entered failed state.

Je te propose d’essayer le programme auto-fix-mysql qui a été conçu pour résoudre ce genre de situations.
Rapidement voici à quoi devrait ressembler la procédure :

Installation du programme auto-fix-mysql

sudo apt-get update
sudo apt-get install python-virtualenv python-dev rsync git
mkdir git
cd git
git clone https://github.com/labriqueinternet/auto-fix-mysql
cd auto-fix-mysql
virtualenv ve
source ve/bin/activate
pip install -U pip setuptools wheel
pip install -r requirements.txt

Utilisation de auto-fix-mysql

cd git/auto-fix-mysql
source ve/bin/activate
python auto-fix-mysql backup-mysql-db # pour tenter de sauvegarder ce qui peut encore l'être
rsync -av /etc/yunohost/auto-fix-mysql/mysql-db-backup/ /root/backup-mysql-db-$(date +%Y-%m-%d) # pour sauvegarder la sauvegarde si on aime avoir les ceintures et les bretelles
python auto-fix-mysql # pour tenter une réparation automatisée
python auto-fix-mysql --help # pour voir les options restantes si ça n'a pas fonctionné
1 Like

Merci pour ta réponse !
J’ai effectué la démarche ci-dessus, et voilà ce que m’a donné le programme :

(ve) root@smidge:~/git/auto-fix-mysql# python auto-fix-mysql
Job for mysql.service failed because the control process exited with error code.
See "systemctl status mysql.service" and "journalctl -xe" for details.
2018-11-06 07:06:20,134 [WARNING] Damn, mysql is broken, attempting restore!
2018-11-06 07:06:20,348 [INFO] []
2018-11-06 07:06:20,349 [INFO] Trying to restart mysqld in safe mode...
181106 07:06:20 mysqld_safe Logging to '/var/lib/mysql/smidge.noho.st.err'.
181106 07:06:21 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
2018-11-06 07:06:23,490 [WARNING] Can't connect to mysql in safe mode (error: 2003: Can't connect to MySQL server on '127.0.0.1:3306' (111 Connection refused)), wait 1min and retry (this somethime fix it because mysql ™)
2018-11-06 07:06:23,491 [WARNING] Attemp number 1 (will try this a maximum number of 3 times)
2018-11-06 07:07:23,510 [WARNING] Can't connect to mysql in safe mode (error: 2003: Can't connect to MySQL server on '127.0.0.1:3306' (111 Connection refused)), wait 1min and retry (this somethime fix it because mysql ™)
2018-11-06 07:07:23,517 [WARNING] Attemp number 2 (will try this a maximum number of 3 times)
181106 07:07:23 mysqld_safe Logging to '/var/lib/mysql/smidge.noho.st.err'.
181106 07:07:24 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
2018-11-06 07:08:23,571 [WARNING] Can't connect to mysql in safe mode (error: 2003: Can't connect to MySQL server on '127.0.0.1:3306' (111 Connection refused)), wait 1min and retry (this somethime fix it because mysql ™)
2018-11-06 07:08:23,573 [WARNING] Attemp number 3 (will try this a maximum number of 3 times)
181106 07:08:24 mysqld_safe Logging to '/var/lib/mysql/smidge.noho.st.err'.
181106 07:08:24 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
2018-11-06 07:09:23,613 [ERROR] I'm not able to relaunch mysql in safe mode so I can't fix it, aborting :(
sed: couldn't flush stdout: Relais brisé (pipe)

Maintenant je t’encourage a essayer recreate-broken-system-tables et/ou recreate-apps-users.

avec l’option recreate-broken-system-tables :

2018-11-06 16:14:58,491 [INFO] []
2018-11-06 16:14:58,493 [INFO] Trying to restart mysqld in safe mode...
181106 16:14:59 mysqld_safe Logging to '/var/lib/mysql/smidge.noho.st.err'.
181106 16:14:59 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
2018-11-06 16:15:01,630 [WARNING] Can't connect to mysql in safe mode (error: 2003: Can't connect to MySQL server on '127.0.0.1:3306' (111 Connection refused)), wait 1min and retry (this somethime fix it because mysql ™)
2018-11-06 16:15:01,633 [WARNING] Attemp number 1 (will try this a maximum number of 3 times)
2018-11-06 16:16:01,706 [WARNING] Can't connect to mysql in safe mode (error: 2003: Can't connect to MySQL server on '127.0.0.1:3306' (111 Connection refused)), wait 1min and retry (this somethime fix it because mysql ™)
2018-11-06 16:16:01,719 [WARNING] Attemp number 2 (will try this a maximum number of 3 times)
181106 16:16:02 mysqld_safe Logging to '/var/lib/mysql/smidge.noho.st.err'.
181106 16:16:02 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
2018-11-06 16:17:01,769 [WARNING] Can't connect to mysql in safe mode (error: 2003: Can't connect to MySQL server on '127.0.0.1:3306' (111 Connection refused)), wait 1min and retry (this somethime fix it because mysql ™)
2018-11-06 16:17:01,771 [WARNING] Attemp number 3 (will try this a maximum number of 3 times)
181106 16:17:02 mysqld_safe Logging to '/var/lib/mysql/smidge.noho.st.err'.
181106 16:17:02 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
2018-11-06 16:18:01,834 [ERROR] I'm not able to relaunch mysql in safe mode so I can't fix it, aborting :(
(ve) root@smidge:~/git/auto-fix-mysql# 181106 16:18:02 mysqld_safe Logging to '/var/lib/mysql/smidge.noho.st.err'.
181106 16:18:02 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql

(et je ne récupère pas le prompt à la fin)

avec l’option recreate-apps-users :

Job for mysql.service failed because the control process exited with error code.
See "systemctl status mysql.service" and "journalctl -xe" for details.
Traceback (most recent call last):
  File "auto-fix-mysql", line 502, in <module>
    parser.dispatch()
  File "/root/git/auto-fix-mysql/ve/local/lib/python2.7/site-packages/argh/helpers.py", line 55, in dispatch
    return dispatch(self, *args, **kwargs)
  File "/root/git/auto-fix-mysql/ve/local/lib/python2.7/site-packages/argh/dispatching.py", line 174, in dispatch
    for line in lines:
  File "/root/git/auto-fix-mysql/ve/local/lib/python2.7/site-packages/argh/dispatching.py", line 277, in _execute_command
    for line in result:
  File "/root/git/auto-fix-mysql/ve/local/lib/python2.7/site-packages/argh/dispatching.py", line 260, in _call
    result = function(*positional, **keywords)
  File "auto-fix-mysql", line 368, in recreate_apps_users
    subprocess.check_output(["systemctl", "restart", "mysql"])
  File "/usr/lib/python2.7/subprocess.py", line 573, in check_output
    raise CalledProcessError(retcode, cmd, output=output)
subprocess.CalledProcessError: Command '['systemctl', 'restart', 'mysql']' returned non-zero exit status 1

Dans les deux cas, je n’ai pas pu redémarrer le service mysql ensuite.

J’ai désinstallé nextcloud (qui utilise ce service, et actuellement ne fonctionne donc pas) au cas où son installation perturbe le programme.
J’ai recommencé les mêmes manipulations, mais rien n’y fait…

Je suis preneur de toute autre suggestion…

Je me suis connecté sur ta brique (je me suis rappelé que tu m’y avais déjà donné accès).

Bon les informations vraiment utiles sont dans /var/lib/mysql/xxxx.xxxx.xx.err et il y a plusieurs messages flippants :

181107 11:21:52 [Note] InnoDB: Waiting for purge to start
181107 11:21:52 [Note] InnoDB: Starting in background the rollback of recovered transactions
2018-11-07 11:21:52 a67ff420  InnoDB: Assertion failure in thread 2793403424 in file fut0lst.ic line 83
InnoDB: Failing assertion: addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
181107 11:21:52 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Server version: 10.0.36-MariaDB-0+deb8u1
key_buffer_size=16384
read_buffer_size=262144
max_used_connections=0
max_threads=153
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 50914 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x20000
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
181107 11:21:52 mysqld_safe mysqld from pid file /var/lib/mysql/smidge.noho.st.pid ended

Je ne sais pas interpréter ces messages d’erreurs mais j’ai suivi les URLs qui sont donnés dans le log et j’ai suivi certains des conseils mais rien n’y fit.
J’ai donc fait une sauvegarde complète du dossier /var/lib/mysql puis je l’ai vidé presque entièrement et là mysql et je l’ai relancé avec succès.
On dirait qu’il est de nouveau utilisable.

En tout cas c’est cool que tu aies désinstallé nextcloud ça me fait moins de choses à chercher à résoudre. J’espère que tu n’as pas perdu de données (je ne pense pas que nextcloud stocke les vraies données dans mysql).

tout remarche, merci !!

je ne sais pas pourquoi tout ça s’est produit par contre… j’espère que ça ne va pas recommencer tout de suite…