[Résolu] Mysql.service - LSB: Start and stop the mysql database server daemon

Salut,

Il y a déjà eu des posts sur ce type de problèmes, mais je ne retrouve pas vraiment mon cas, donc j’en recrée un. Ce matin j’ai fait un reboot du serveur en appuyant sur le bouton (donc extinction normale en principe), et des mises à jour, et mysql a planté. Voici les mises à jour réalisées :

Start-Date: 2017-03-17  11:22:20
Commandline: apt dist-upgrade
Upgrade: libmagickcore-6.q16-dev:amd64 (6.8.9.9-5+deb8u7, 6.8.9.9-5+deb8u8), libimage-magick-q16-perl:amd64 (6.8.9.9-5+deb8u7, 6.8.9.9-5+deb8u8), libmagickcore-6-arch-config:amd64 (6.8.9.9-5+deb8u7, 6.8.9.9-5+deb8u8), perlmagick:amd64 (6.8.9.9-5+deb8u7, 6.8.9.9-5+deb8u8), libmagickwand-6.q16-dev:amd64 (6.8.9.9-5+deb8u7, 6.8.9.9-5+deb8u8), libmagickcore-6-headers:amd64 (6.8.9.9-5+deb8u7, 6.8.9.9-5+deb8u8), libimage-magick-perl:amd64 (6.8.9.9-5+deb8u7, 6.8.9.9-5+deb8u8), imagemagick-6.q16:amd64 (6.8.9.9-5+deb8u7, 6.8.9.9-5+deb8u8), imagemagick:amd64 (6.8.9.9-5+deb8u7, 6.8.9.9-5+deb8u8), ssowat:amd64 (2.6.1, 2.6.4), libmagickwand-6.q16-2:amd64 (6.8.9.9-5+deb8u7, 6.8.9.9-5+deb8u8), libmagickwand-6-headers:amd64 (6.8.9.9-5+deb8u7, 6.8.9.9-5+deb8u8), tzdata:amd64 (2016j-0+deb8u1, 2017a-0+deb8u1), imagemagick-common:amd64 (6.8.9.9-5+deb8u7, 6.8.9.9-5+deb8u8), libmagickcore-6.q16-2-extra:amd64 (6.8.9.9-5+deb8u7, 6.8.9.9-5+deb8u8), libmagickwand-dev:amd64 (6.8.9.9-5+deb8u7, 6.8.9.9-5+deb8u8), libmagickcore-6.q16-2:amd64 (6.8.9.9-5+deb8u7, 6.8.9.9-5+deb8u8)
End-Date: 2017-03-17  11:23:04

Voici le résultat de systemctl status mysql :

● mysql.service - LSB: Start and stop the mysql database server daemon
   Loaded: loaded (/etc/init.d/mysql)
   Active: failed (Result: exit-code) since ven. 2017-03-17 15:31:06 CET; 1h 15min ago
  Process: 32020 ExecStart=/etc/init.d/mysql start (code=exited, status=1/FAILURE)

mars 17 15:30:34 lamo systemd[1]: Starting LSB: Start and stop the mysql.....
mars 17 15:31:06 lamo mysql[32020]: Starting MySQL database server: mysq...d!
mars 17 15:31:06 lamo systemd[1]: mysql.service: control process exited,...=1
mars 17 15:31:06 lamo systemd[1]: Failed to start LSB: Start and stop th...n.
mars 17 15:31:06 lamo systemd[1]: Unit mysql.service entered failed state.
Hint: Some lines were ellipsized, use -l to show in full.

J’ai trouvé des logs dans /var/lib/mysql/lamo.err :

170317 15:29:40 InnoDB: Completed initialization of buffer pool
170317 15:29:40 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 147663172316
170317 15:29:40  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 147663386036
InnoDB: Error: tried to read 16384 bytes at offset 7 537280512.
InnoDB: Was only able to read -1.
170317 15:29:43  InnoDB: Operating system error number 5 in a file operation.
InnoDB: Error number 5 means 'Input/output error'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/operating-system-error-codes.html
InnoDB: File operation call: 'read'.
InnoDB: Cannot continue operation.
170317 15:30:35 [Note] Plugin 'FEDERATED' is disabled.
170317 15:30:35 InnoDB: The InnoDB memory heap is disabled
170317 15:30:35 InnoDB: Mutexes and rw_locks use GCC atomic builtins
170317 15:30:35 InnoDB: Compressed tables use zlib 1.2.8
170317 15:30:35 InnoDB: Using Linux native AIO
170317 15:30:35 InnoDB: Initializing buffer pool, size = 128.0M
170317 15:30:35 InnoDB: Completed initialization of buffer pool
170317 15:30:35 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 147663172316
170317 15:30:35  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 147663386036
InnoDB: Error: tried to read 16384 bytes at offset 7 537280512.
InnoDB: Was only able to read -1.
170317 15:30:38  InnoDB: Operating system error number 5 in a file operation.
InnoDB: Error number 5 means 'Input/output error'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/operating-system-error-codes.html
InnoDB: File operation call: 'read'.
InnoDB: Cannot continue operation.

Il y a notamment “InnoDB: Database was not shut down normally!”, j’ai l’impression que j’ai des tables qui sont corrompues, mais j’y connais pas grand chose…
Si quelqu’un a une piste pour comprendre ce qui ne va pas et le réparer… Ma dernière sauvegarde date du 10 mars, donc je risque de perdre des données si je n’arrive pas à réparer (notamment calendrier et contacts).

Merci !

Alors, avec @ljf, on a fini par réussir à rattraper le coup. En gros on a supprimé toutes les tables de mysql et on les a recréées à partir d’un backup, j’ai donc perdu une semaine de données.
Voici comment on a fait :

Bien stopper tous les processus mysql :

ps aux | grep mysql
kill -8 numprocessencours

Supprimer les bases de donnée mysql :
rm -r /var/lib/mysql (ou pour plus de sécurité : mv /var/lib/mysql /var/lib/mysql.backup )

On les recrée :

mysql_install_db
chown -R mysql:mysql /var/lib/mysql
service mysql start
/usr/bin/mysqladmin -u root password 'password' #remplacer le password entre ' par celui qui est dans /etc/yunohost/mysql
/usr/bin/mysqladmin -u root -h lamo -p password 'password' #remplacer "lamo" par le nom de votre machine (cette commande est affichée normalement après "mysql_install_db), et 'password' comme précédemment

À ce stade, on a un mysql tout propre.

Récupérer les .sql dans un backup créé avec la commande “yunohost backup create” :
tar -zxf 20170310-003947.tar.gz --wildcards --no-anchored '*.sql'

Ajouter les helpers :
source /usr/share/yunohost/helpers

Pour chaque APP :

yunohost app setting app_id mysqlpwd #Récupérer le password d'une app
ynh_mysql_create_db app_id app_id passwordrécupéré
mysql -u app_id -p app_id < db.sql #le db.sql récupéré dans le backup. Pour moi, c'était dans dossierdubackup/apps/app_id/backup. Le password demandé est le password récupéré.

Par contre, j’avais mis l’option innodb_file_per_table=1 dans /etc/mysql/conf.d/innodb.cnf, suite à ce problème : /var/lib remplit la partition. Mais ça n’a pas l’air d’avoir marché, en fait je crois qu’il faut le mettre dans /etc/mysql/my.cnf.

Bref, c’est résolu pour cette fois…