Mysql s'est écrasé et ne démarre pas

Question

Notre serveur de production mysql vient de planter et ne reviendra pas. Cela donne une erreur de segmentation. J'ai essayé un redémarrage et je ne sais simplement pas quoi essayer d'autre. Voici le stacktrace:

 140502 14:13:05 [Note] Le plugin 'FEDERATED' est désactivé. InnoDB: Le scan du journal a progressé après le point de contrôle lsn 108 1057948207 140502 14:13:06 InnoDB: La base de données n'a pas été fermée normalement! InnoDB: démarrage de la récupération après incident. InnoDB: lecture des informations sur l'espace disque logique à partir des fichiers .ibd ... InnoDB: restauration des éventuelles pages de données à moitié écrites à partir de la double écriture InnoDB: tampon ... InnoDB: Faire la récupération: numérisé jusqu'au journal numéro de séquence 108 1058059648 InnoDB: 1 transaction (s) qui doit être annulée ou nettoyé InnoDB: au total 15 opérations de ligne pour annuler InnoDB: le compteur d'ID Trx est 0 562485504 140502 14:13:06 InnoDB: Démarrage d'un lot d'application d'enregistrements de journal à la base de données ... InnoDB: Progression en pourcentages: 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: appliquer le lot terminé InnoDB: commencer en arrière-plan le retour en arrière des transactions non engagées 140502 14:13:06 InnoDB: annulation de trx avec l'ID 0 562485192, 15 lignes à annuler 140502 14:13:06 InnoDB: démarré; numéro de séquence du journal 108 1058059648 140502 14:13:06 InnoDB: Échec d'assertion dans le thread 1873206128 dans le fichier ../../../storage/innobase/fsp/fsp0fsp.c ligne 1593 InnoDB: Échec de l'assertion: frag_n_used> 0 InnoDB: Nous générons intentionnellement un piège mémoire. InnoDB: Soumettez un rapport détaillé de bogue à http://bugs.mysql.com. InnoDB: Si vous obtenez des échecs ou des plantages d'assertion répétés, même InnoDB: immédiatement après le démarrage de mysqld, il peut y avoir InnoDB: corruption dans le tablespace InnoDB. Veuillez vous référer à InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html[.____.[InnoDB: à propos du forçage de la récupération. 140502 14:13:06 - mysqld a reçu le signal 6; Cela peut être dû au fait que vous avez rencontré un bug. Il est également possible que ce fichier binaire Ou l'une des bibliothèques avec lesquelles il était lié soit corrompu, mal construit, Ou mal configuré. Cette erreur peut également être causée par un dysfonctionnement du matériel. Nous ferons de notre mieux pour récupérer des informations qui, espérons-le, aideront à diagnostiquer Le problème, mais comme nous avons déjà planté, quelque chose ne va vraiment pas et cela peut échouer. key_buffer_size = 16777216 read_buffer_size = 131072 max_used_connections = 0 max_threads = 151 threads_connected = 0 Il est possible que mysqld utilise jusqu'à key_buffer_size + (read_buffer_size + sort_buffer_size) * max_threads = 345919 Ko octets de mémoire J'espère que c'est D'accord; sinon, diminuez certaines variables de l'équation. thd: 0x0 Tentative de retour en arrière. Vous pouvez utiliser les informations suivantes pour découvrir Où mysqld est mort. Si vous ne voyez aucun message après cela, quelque chose s'est mal passé. Terriblement mal ... Stack_bottom = (nil) thread_stack 0x30000 140502 14:13:06 [Remarque] Planificateur d'événements: chargé 0 événements 140502 14:13:06 [Note]/usr/sbin/mysqld: prêt pour les connexions. Version: '5.1.41-3ubuntu12.10' socket: '/ var/run /mysqld/mysqld.sock ': 3306 (Ubuntu) /usr/sbin/mysqld (my_print_stacktrace + 0x2d) [0xb7579cbd] /usr/sbin/mysqld (handle_segfault + 0x494) [0xb7245854 ] [0xb6fc0400] /Lib/tls/i686/cmov/libc.so.6 (abandon + 0x182) [0xb6cc5a82] /Usr/sbin/mysqld (+ 0x4867e9 ) [0xb74647e9] /Usr/sbin/mysqld (btr_page_free_low + 0x122) [0xb74f1622] /Usr/sbin/mysqld (btr_compress + 0x684) [0xb74f4ca4] /Usr/sbin/mysqld (btr_cur_compress_if_useful + 0xe7) [0xb74284e7] /usr/sbin/mysqld (btr_cur_pessimistic_delete + 0x332) [0xb7429e72] /usr/sbin/mysqld_btr (b82) .____.]/usr/sbin/mysqld (btr_discard_page + 0x175) [0xb74f41e5] /usr/sbin/mysqld (btr_cur_pessimistic_delete + 0x3e8) [0xb7429f28] /usr/sbin/mysqld (+ 0x526197) [0xb7504197] /usr/sbin/mysqld (row_undo_ins + 0x1 0xb7504771] /Usr/sbin/mysqld (row_undo_step + 0x25f) [0xb74c210f] /Usr/sbin/mysqld (que_run_threads + 0x58a) [0xb74a31da] /Usr/sbin/mysqld (trx_rollback_or_clean_all_without_sess + 0x3e3) [0xb74ded43] /lib/tls/i686/cmov/libpthread.so.0 (+ 0x596e) [0xb6f9f96e] /lib/tls/i686/cmov/libov/lib .so.6 (clone + 0x5e) [0xb6d65a4e] La page de manuel sur http://dev.mysql.com/doc/mysql/en/crashing.html contient des informations qui devraient aider vous découvrez la cause de l'accident.

Des recommandations?

Jonathan · Accepted Answer

Aie.

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.1/en/forcing-recovery.html InnoDB: about forcing recovery.

Consultez la page Web suggérée: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html .

Fondamentalement, essayez de démarrer le serveur MySQL en mode de récupération et faire une sauvegarde de vos tables en panne .

Modifiez votre /etc/my.cnf et ajouter:

 innodb_force_recovery = 1

... pour voir si vous pouvez accéder à votre base de données et obtenir vos données/trouver la table corrompue.

Habituellement, lorsque cela se produit, c'est une reconstruction (au moins une ou deux tables corrompues).

De http://chepri.com/mysql-innodb-corruption-and-recovery/ :

Arrêtez mysqld (service mysql stop).
Sauvegarde /var/lib/mysql/ib*
Ajoutez la ligne suivante dans /etc/my.cnf:
```
innodb_force_recovery = 1 
```
(ils suggèrent 4, mais il vaut mieux commencer par 1 et incrémenter s'il ne démarre pas)
Redémarrez mysqld (service mysql start).
Vider toutes les tables: mysqldump -A > dump.sql
Supprimez toutes les bases de données qui nécessitent une récupération.
Arrêtez mysqld (service mysql stop).
Retirer /var/lib/mysql/ib*
Commenter innodb_force_recovery dans /etc/my.cnf
Redémarrez mysqld. Regardez le journal des erreurs mysql. Par défaut, il doit être /var/lib/mysql/server/hostname.com.err pour voir comment il crée de nouveaux ib* des dossiers.
Restaurer les bases de données à partir du vidage: mysql < dump.sql

rahuljain1311 · Answer

J'étais confronté à cette même erreur lors de l'utilisation de l'image docker mysql: 5.7. L'erreur principale a été de créer un utilisateur root qui existe par défaut. Plus d'informations: https://github.com/docker-library/mysql/issues/129

Comme indiqué dans le lien ci-dessus, la solution consistait à NE PAS définir MYSQL_USER et MYSQL_PASSWORD dans les variables d'environnement lors du démarrage de l'image docker.

Zack Morris · Answer

Cela m'est arrivé dans Laravel Homestead (Vagrant après une panique du noyau sous Mac OS Sierra 10.12.4 (16E195):

$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 14.04.3 LTS Release: 14.04 Codename: trusty $ mysql -V mysql Ver 14.14 Distrib 5.7.9, for Linux (x86_64) using EditLine wrapper

Voici quelques ressources que vous pouvez essayer, bien que aucune des options de réparation ne fonctionne pour moi :

https://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html

https://forums.mysql.com/read.php?22,603093,604631#msg-604631

https://support.plesk.com/hc/en-us/articles/213939865-How-to-fix-InnoDB-corruption-cases-for-the-MySQL-database

J'ai essayé d'ajouter la récupération de force à la configuration mysql (commencez à 1 et augmentez progressivement car des nombres supposément plus élevés peuvent provoquer une corruption permanente):

Sudo nano /etc/mysql/my.cnf

[mysqld] innodb_force_recovery = 1 #innodb-read-only=1 #innodb_purge_threads=0 #key_buffer_size=16M #event-scheduler=disabled

Dans une autre fenêtre, exécutez:

tail -f /var/log/mysql/error.log

Essayez ensuite de redémarrer mysqld avec les différentes options activées:

Sudo /etc/init.d/mysql restart

S'il expire, vous pouvez forcer le redémarrage des processus mysql avec:

# process id is first column with number, just ignore lines with grep because they list the process running 'grep mysql' ps aux | grep mysql Sudo kill -9 <process-id> Sudo /etc/init.d/mysql restart

Si cela fonctionne, le journal affichera quelque chose comme:

Version: '5.7.9' socket: '/var/run/mysqld/mysqld.sock' port: 3306 MySQL Community Server (GPL)

S'il échoue, le journal affichera quelque chose comme:

InnoDB: Assertion failure in thread 140049488692992 in file log0recv.cc line 1420

Au pire, j'ai essayé de supprimer les bases de données susceptibles d'être corrompues:

Sudo ls -alt /var/lib/mysql

Il s'est avéré que la base de données sur laquelle je travaillais était la plus récemment modifiée en haut de la liste. Heureusement, j'ai eu un vidage SQL pour ce jour-là, j'ai donc pu le supprimer:

Sudo rm -rf /var/lib/mysql/<database_name>

J'ai laissé tous les autres fichiers et mysql a quand même pu démarrer.

MISE À JOUR: assurez-vous de désactiver innodb_force_recovery = 1 Une fois que mysql fonctionne à nouveau, sinon vous obtiendrez des erreurs lorsque vous tenterez de modifier des bases de données et des tables.

Ensuite, j'ai recréé la base de données avec Sequel Pro, réimporté mes données et j'ai pu continuer sans avoir à jeter toutes les bases de données de mes autres projets.

À l'avenir, je dois supposer que toute base de données mysql peut être corrompue et essayer de garder des sauvegardes quotidiennes et faire documenter ou coder le script de récréation de la base de données dans mes outils d'intégration continue.