MySQL plante ("Certains pointeurs peuvent être invalides et provoquer l'annulation de la sauvegarde")

Question

J'ai une base de données MySQL de 5 Go appelée "tweets", à partir de laquelle j'ai besoin d'accéder à la table "searchresults". Mais lorsque j'effectue une requête ou crée une sauvegarde, le serveur MySQL (fonctionnant sur Windows 10) se bloque tout le temps avec la même erreur sur la même ligne.

Par exemple, si je tente de vider la base de données avec la commande suivante:

C:\xampp\mysql\bin>mysqldump.exe --user root --force tweets > D:\secondtry.sql 

Je reçois le message d'erreur suivant dans la fenêtre cmd.exe avec exactement le même rang, encore et encore:

mysqldump.exe: Error 2013: Lost connection to MySQL server during query when dumping table `searchresults` at row: 5222907 

mysqldump.exe: Couldn't execute 'SELECT engine FROM INFORMATION_SCHEMA.TABLES WHERE table_name = 'stats'': MySQL server has gone away (2006) 

mysqldump.exe: Couldn't execute 'SET SQL_QUOTE_SHOW_CREATE=1': MySQL server has gone away (2006) 

mysqldump.exe: Couldn't execute 'SELECT `COLUMN_NAME` AS `Field`, `COLUMN_TYPE` AS `Type`, `IS_NULLABLE` AS `Null`, `COLUMN_KEY` AS `Key`, `COLUMN_DEFAULT` AS `Default`, `EXTRA` AS `Extra`, `COLUMN_COMMENT` AS `Comment` FROM `INFORMATION_SCHEMA`.`COLUMNS` WHERE TABLE_SCHEMA = 'tweets' AND TABLE_NAME = 'stats'': MySQL server has gone away (2006) 

mysqldump.exe: Couldn't execute 'UNLOCK TABLES': MySQL server has gone away (2006) 

et dans le mysql_error.log je reçois le message suivant et le serveur se ferme vers le bas:

Server version: 10.1.8-MariaDB <br/> key_buffer_size=16777216 <br/> read_buffer_size=262144 <br/> max_used_connections=1 <br/> max_threads=1001 <br/> thread_count=1 <br/> It is possible that mysqld could use up to <br/> key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = <br/> 787099 K bytes of memory Hope that's ok; if not, decrease some <br/> variables in the equation. 

Thread pointer: 0x0x5b93168 <br/> Attempting backtrace. You can use the <br/> following information to find out where mysqld died. If you see no <br/> messages after this, something went terribly wrong... <br/> mysqld.exe!my_parameter_handler() <br/> mysqld.exe!my_mb_ctype_mb()<br/> mysqld.exe!??0Global_read_lock@@QAE@XZ()<br/> mysqld.exe!??0Global_read_lock@@QAE@XZ()<br/> mysqld.exe!?store_record_for_lookup@Stat_table@@IAEXXZ()<br/> mysqld.exe!??0Global_read_lock@@QAE@XZ()<br/> mysqld.exe!??0Global_read_lock@@QAE@XZ()<br/> mysqld.exe!??0Global_read_lock@@QAE@XZ()<br/> mysqld.exe!?store_record_for_lookup@Stat_table@@IAEXXZ()<br/> mysqld.exe!?store_record_for_lookup@Stat_table@@IAEXXZ()<br/> mysqld.exe!?ha_rnd_next@handler@@QAEHPAE@Z()<br/> mysqld.exe!?rr_sequential@@YAHPAUREAD_RECORD@@@Z()<br/> mysqld.exe!?sub_select@@YA? AW4enum_nested_loop_state@@PAVJOIN@@PAUst_join_table@@_N@Z() <br/> mysqld.exe!?setup_end_select_func@@YAP6A?AW4enum_nested_loop_state@@PAVJOIN@@PAUst_join_table@@_N@Z0@Z() <br/> mysqld.exe!?exec_inner@JOIN@@QAEXXZ() <br/> mysqld.exe!?exec@JOIN@@QAEXXZ()<br/> mysqld.exe!?handle_select@@YA_NPAVTHD@@PAULEX@@PAVselect_result@@K@Z()<br/> mysqld.exe!??0Table_scope_and_contents_source_st@@QAE@ABU0@@Z()<br/> mysqld.exe!?mysql_execute_command@@YAHPAVTHD@@@Z()<br/> mysqld.exe!?mysql_parse@@YAXPAVTHD@@PADIPAVParser_state@@@Z()<br/> mysqld.exe!?dispatch_command@@YA_NW4enum_server_command@@PAVTHD@@PADI@Z()<br/> mysqld.exe!?do_command@@YA_NPAVTHD@@@Z()<br/> mysqld.exe!?threadpool_process_request@@YAHPAVTHD@@@Z()<br/> mysqld.exe!?tp_end@@YAXXZ() <br/> KERNEL32.DLL!SetUserGeoID()<br/> ntdll.dll!TpSimpleTryPost() <br/> ntdll.dll!EtwNotificationRegister()<br/> KERNEL32.DLL!BaseThreadInitThunk()<br/> ntdll.dll!RtlUnicodeStringToInteger()<br/> ntdll.dll!RtlUnicodeStringToInteger()<br/> 

Trying to get some variables. Some pointers may be invalid and cause<br/> the dump to abort. Query (0x5b9a908): SELECT /*!40001 SQL_NO_CACHE */<br/> 
* FROM `searchresults` <br/> Connection ID (thread ID): 2 <br/> Status: NOT_KILLED<br/> 

Jusqu'à présent, j'ai essayé:

1. Je mis innodb_force_recovery dans le my.ini à 1 et 6
2. J'utilisé les paramètres "--force", "--skip-insert étendu" et " --hex-blob » pour le mysqldump.exe
3. je PHPMyAdmin, et même essayé MySQL Workbench Microsoft SQL migration Tool pour convertir la base de données dans une base de données MSSQL
4. J'ai augmenté l'option max_allowed_packet dans le my.ini
5. J'ai utilisé un éditeur hexadécimal pour trouver la ligne corrompue dans le fichier .idb pour le supprimer, mais je ne pouvais pas e ce que je dois supprimer
6. Utilisez ma sauvegarde, mais l'erreur est déjà là
7. « réparation d'une table », mais je reçois la réponse suivante: « Le moteur de stockage pour la table ne prend pas en charge la réparation »
8. Reconstruit la table avec "ALTER TABLE searchresults ENGINE = InnoDB;" mais l'erreur se produit pendant la reconstruction.
9. La définition du paramètre innodb_log_file_size dans my.ini au maximum de 4G renvoie la même erreur.
10. Utilisez un autre ordinateur

Je suis assez sûr qu'il ya un ensemble de données corrompues dans la ligne 5222907 ou 5222908 et c'est pourquoi le serveur tombe en panne. Ce serait vraiment bien pour moi de perdre une rangée, si je peux accéder au reste des données par la suite. Je pourrais même perdre les premières lignes 5222908. Mais quand je ne peux pas supprimer les données corrompues. Si j'utilise la requête

DELETE FROM searchresults LIMIT 5222908 

Le serveur se bloque à nouveau.

Je serais très reconnaissant pour tous les conseils sur cette question. Les données sont très importantes pour moi, car j'en ai besoin pour ma thèse de maîtrise, qui va bientôt arriver.

Nous vous remercions de votre temps et de vos efforts!

EDIT: Ceci est ma structure de table (avis, il n'y a pas des clés ou index):

CREATE TABLE `searchresults` (
`id` bigint(20) DEFAULT NULL, 
`user` varchar(50) CHARACTER SET latin1 DEFAULT NULL, 
`createdAt` timestamp NULL DEFAULT NULL, 
`retweetcount` int(11) DEFAULT NULL, 
`favoritecount` int(11) DEFAULT NULL, 
`message` varchar(500) CHARACTER SET latin1 DEFAULT NULL 
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_german1_ci 

EDIT: J'ai utilisé un INSERT INTO comme ceci:

SELECT id INTO OUTFILE 'C:/Temp/allCount.csv' FIELDS TERMINATED BY ',' 
OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\n' FROM searchresults; 

Et selon le Colonne I select (id, retweetcount etc.) Je reçois une quantité différente de lignes. Ils sont toujours inférieurs à 5222907, mais cela signifie que le problème pourrait toujours être lié à un paramètre plutôt qu'à une erreur de corruption. Qu'est-ce que tu penses? Connaissez-vous quelques paramètres supplémentaires que je pourrais ajuster dans la config mysql?

Answer 1

Vous pouvez regarder dans la modification de ces propriétés du serveur mysql:

nano /etc/mysql/my.cnf

query_cache_size=16M 
key_buffer_size=256M 

Ou peut-être même essayer d'augmenter le temps d'exécution autorisée pour la requête du client MySQL :

SET GLOBAL MAX_STATEMENT_TIME=1000; 

avant d'exécuter votre requête.