# Mariadb/mysql : crash à la simple lecture d'une table **URL:** \ **Category:** Support Debian\ **Tags:** mysql\ **Created:** [Octobre 14, 2017, 7:09 UTC](https://www.debian-fr.org/t/mariadb-mysql-crash-a-la-simple-lecture-dune-table/74760 "2017-10-14T19:09:16Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![nico](https://www.debian-fr.org/user_avatar/www.debian-fr.org/nico/32/4003_2.png) [@nico](https://www.debian-fr.org/u/nico)\ **Post date:** [Octobre 14, 2017, 7:09 UTC](https://www.debian-fr.org/t/mariadb-mysql-crash-a-la-simple-lecture-dune-table/74760/1 "2017-10-14T19:09:17Z")
Bonjour à tous, je suis sous debian 9 stretch. j’avais déjà eu des soucis avec une base mysql et des tables innodb que j’avais évoqué dans un sujet précédent. Le serveur mysql-server ne démarrait plus. J’ai contourné le problème en réinstallant tout (merci à PengouinPdt). J’ai pu reprendre mon travail de développement, une paire de commit et test plus tard, j’ai à nouveau des soucis. Je peux travailler normalement tant que je ne touche pas à une table en particulier. Sinon, soit le service mariadb s’arrête, mais apparemment se relance : > MariaDB [vrfdb]\> REPAIR TABLE ligne\_compte; > ERROR 2013 (HY000): Lost connection to MySQL server during query > MariaDB [vrfdb]\> Si je lance la commande mysql sans l’option -A, le processus mysql-server occupe alors un processeur à 100% en non-stop, et à écrire sans discontinu dans le fichier log (le temps que je m’en aperçois, le fichier faisait plusieurs Go) Quelqu’un a-t-il eu une idée ? ---
**Author:** ![jimbo](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/j/d78d45/32.png) [@jimbo](https://www.debian-fr.org/u/jimbo)\ **Post date:** [Octobre 14, 2017, 8:52 UTC](https://www.debian-fr.org/t/mariadb-mysql-crash-a-la-simple-lecture-dune-table/74760/2 "2017-10-14T20:52:18Z")
> [@nico](#): > > Je peux travailler normalement tant que je ne touche pas à une table en particulier. > Sinon, soit le service mariadb s’arrête, mais apparemment se relance : quand tu touche a la table qui pause problème, que disent les log ---
**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\ **Post date:** [Octobre 15, 2017, 4:41 UTC](https://www.debian-fr.org/t/mariadb-mysql-crash-a-la-simple-lecture-dune-table/74760/3 "2017-10-15T04:41:15Z")
> [@nico](#): > > Quelqu’un a-t-il eu une idée ? Si tu as une sauvegarde, tu pourrais commencer déjà par supprimer la table et la réinjecter pour voir si ça ne corrigerai pas le problème. Sinon l’option ‹ check repair › habituelle : [https://dev.mysql.com/doc/refman/5.7/en/rebuilding-tables.html](https://dev.mysql.com/doc/refman/5.7/en/rebuilding-tables.html) ---
**Author:** ![nico](https://www.debian-fr.org/user_avatar/www.debian-fr.org/nico/32/4003_2.png) [@nico](https://www.debian-fr.org/u/nico)\ **Post date:** [Octobre 15, 2017, 2:16 UTC](https://www.debian-fr.org/t/mariadb-mysql-crash-a-la-simple-lecture-dune-table/74760/4 "2017-10-15T14:16:43Z")
Pour les logs il y a un sacré nombre de lignes qui arrivent après un « CHECK TABLE » : > 2017-10-15 16:06:32 7fa003d2d700 InnoDB: uncompressed page, stored checksum in field1 166237931, calculated checksums for field1: crc32 2106467176, innodb 1456091881, none 3735928559, stored checksum in field2 1127261234, calculated checksums for field2: crc32 2106467176, innodb 1127261234, none 3735928559, page LSN 0 9791393, low 4 bytes of LSN at page end 9791393, page number (if stored to page already) 7, space id (if created with \>= MySQL-4.1.1 and stored already) 2 > InnoDB: page type 17855 meaning INDEX > InnoDB: Page may be an index page where index id is 18 > InnoDB: (index « PRIMARY » of table « mysql ».« innodb\_index\_stats ») > 2017-10-15 16:06:32 140325235644160 [Note] InnoDB: It is also possible that your operating system has corrupted its own file cache and rebooting your computer removes the error. If the corrupt page is an index page. You can also try to fix the corruption by dumping, dropping, and reimporting the corrupt table. You can use CHECK TABLE to scan your table for corruption. Please refer to [http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html](http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html) for information about forcing recovery. > 2017-10-15 16:06:32 140325235644160 [ERROR] InnoDB: Database page corruption on disk or a failed file read of tablespace mysql/innodb\_index\_stats page [page id: space=2, page number=7]. You may have to recover from a backup. > 2017-10-15 16:06:32 7fa003d2d700 InnoDB: Page dump in ascii and hex (16384 bytes): > len 16384; hex 09e896eb00000007000000080000000600000000009567a145bf000000000000000000000002000303bd800b00000000000000050000000900000000000000000000000000000000001200000000000000000000000000000000000000000100020020696e66 Puis encore une dizaine ligne en hexa, puis des zéros en continu pendant un nombre de ligne que je n’ai pu compté car cela dépasse la hauteur de mon écran. Puis : > 0000000000000000007001a000634330a432009567a1; asc g E infimum supremum! nvrfdbexception\_secteurPRIMARYn\_leaf\_pages 5 zY Number of leaf pages in the index avrfdbexception\_secteurPRIMARYsize 5 XY Number of pages in the index NvrfdbgrillePRIMARYn\_diff\_pfx01 oY id\_g! ( cvrfdbgrillePRIMARYn\_leaf\_pages =Y Number of leaf pages in the index 0 VvrfdbgrillePRIMARYsize Y Number of pages in the index 8 Uvrfdbligne\_comptePRIMARYn\_diff\_pfx01 , {Y id\_lc! @ ivrfdbligne\_comptePRIMARYn\_leaf\_pages , lY Number of leaf pages in the index H \vrfdbligne\_comptePRIMARYsize , CY Number of pages in the index P vrfdbligne\_grillePRIMARYn\_diff\_pfx01 3 Y ? id\_lg Puis des lignes vides, encore un paquet. Puis enfin : > ``` > p cC0 2 g ; > > ``` > > InnoDB: End of page dump > 2017-10-15 16:06:33 7fa003d2d700 InnoDB: uncompressed page, stored checksum in field1 166237931, calculated checksums for field1: crc32 2106467176, innodb 1456091881, none 3735928559, stored checksum in field2 1127261234, calculated checksums for field2: crc32 2106467176, innodb 1127261234, none 3735928559, page LSN 0 9791393, low 4 bytes of LSN at page end 9791393, page number (if stored to page already) 7, space id (if created with \>= MySQL-4.1.1 and stored already) 2 > InnoDB: page type 17855 meaning INDEX > InnoDB: Page may be an index page where index id is 18 > InnoDB: (index « PRIMARY » of table « mysql ».« innodb\_index\_stats ») > 2017-10-15 16:06:33 140325235644160 [Note] InnoDB: It is also possible that your operating system has corrupted its own file cache and rebooting your computer removes the error. If the corrupt page is an index page. You can also try to fix the corruption by dumping, dropping, and reimporting the corrupt table. You can use CHECK TABLE to scan your table for corruption. Please refer to [http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html](http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html) for information about forcing recovery. > 2017-10-15 16:06:33 140325235644160 [ERROR] InnoDB: Trying to access page number 83881216 in space 0 space name ./ibdata1, which is outside the tablespace bounds. Byte offset 0, len 16384 i/o type 10. > 2017-10-15 16:06:33 7fa003d2d700 InnoDB: Assertion failure in thread 140325235644160 in file ha\_innodb.cc line 21960 > InnoDB: We intentionally generate a memory trap. > InnoDB: Submit a detailed bug report to [http://bugs.mysql.com](http://bugs.mysql.com). > 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](http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html) > InnoDB: about forcing recovery. > 171015 16:06:33 [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 [MariaDB Documentation](https://mariadb.com/kb/en/reporting-bugs) Est-ce que ça vaut le coup de le poster comme ils le suggèrent ? ---
**Author:** ![nico](https://www.debian-fr.org/user_avatar/www.debian-fr.org/nico/32/4003_2.png) [@nico](https://www.debian-fr.org/u/nico)\ **Post date:** [Octobre 15, 2017, 2:30 UTC](https://www.debian-fr.org/t/mariadb-mysql-crash-a-la-simple-lecture-dune-table/74760/5 "2017-10-15T14:30:43Z")
Zut, un DROP TABLE ne fonctionne pas, il fait déconner le serveur autant que les autres commandes sur cette table. Tiens , Tiens ! J’ai regardé dans le répertoire de la base en question dans /var/lib/mysql, et la table qui pose problème n’a pas de fichier à son nom, contrairement aux autres. ---
**Author:** ![josephtux](https://www.debian-fr.org/user_avatar/www.debian-fr.org/josephtux/32/3985_2.png) [@josephtux](https://www.debian-fr.org/u/josephtux)\ **Post date:** [Octobre 15, 2017, 2:38 UTC](https://www.debian-fr.org/t/mariadb-mysql-crash-a-la-simple-lecture-dune-table/74760/6 "2017-10-15T14:38:10Z")
> [@nico](#): > > Puis encore une dizaine ligne en hexa, puis des zéros en continu pendant un nombre de ligne que je n’ai pu compté car cela dépasse la hauteur de mon écran wc le fait. egrep ‹ ^00\* › fichier.log | wc -l pour connaître le nombre de lignes qui ne contiennent que des zéro (modifier le motif d’expression rationnelle de grep selon les besoins …) ---
**Author:** ![nico](https://www.debian-fr.org/user_avatar/www.debian-fr.org/nico/32/4003_2.png) [@nico](https://www.debian-fr.org/u/nico)\ **Post date:** [Octobre 15, 2017, 2:46 UTC](https://www.debian-fr.org/t/mariadb-mysql-crash-a-la-simple-lecture-dune-table/74760/7 "2017-10-15T14:46:11Z")
En fait, ce n’est pas une ligne complète de zéro, ils sont à la suite d’une ligne très longue, mais j’ai réussi à les compter en suivant ta piste : > root@viking:/var/log/mysql# egrep ‹ ^_0{40000}_ › error.log | wc -l > grep: expression rationnelle trop grande > 0 > root@viking:/var/log/mysql# egrep ‹ ^_0{30000}_ › error.log | wc -l > 909 ça fait pas mal