Mariadb/mysql : crash à la simple lecture d'une table

Support Debian
Tags: #<Tag:0x00007f63f2f5e210>
#1

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 ?

#2

quand tu touche a la table qui pause problème, que disent les log

#3

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

#4

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 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 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.
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.
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 https://mariadb.com/kb/en/reporting-bugs

Est-ce que ça vaut le coup de le poster comme ils le suggèrent ?

#5

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.

#6

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 …)

#7

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