Сбой MySQL (некоторые указатели могут быть недействительными и привести к прекращению дампа)

У меня есть база данных MySQL объемом 5 ГБ под названием «твиты», из которой мне нужно получить доступ к таблице «результаты поиска». Но когда я выполняю на нем запрос или создаю дамп, сервер MySQL (работающий в Windows 10) все время падает с одной и той же ошибкой в ​​той же строке.

Например, если я попытаюсь сбросить базу данных с помощью следующей команды:

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

Я получаю следующее сообщение об ошибке в окне cmd.exe с одной и той же строкой снова и снова:

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)

и в mysql_error.log я получаю следующее сообщение, и сервер отключается:

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/>

До сих пор я пробовал:

  1. Я установил innodb_force_recovery в my.ini на 1 и 6
  2. Я использовал параметры "--force", "--skip-extended-insert" и "--hex-blob" для mysqldump.exe.
  3. Я использовал PHPMyAdmin, MySQLWorkbench и даже попробовал средство миграции Microsoft SQL для преобразования базы данных в базу данных MSSQL.
  4. Я увеличил параметр max_allowed_packet в файле my.ini.
  5. Я использовал шестнадцатеричный редактор, чтобы найти поврежденную строку в файле .idb, чтобы удалить ее, но я не смог выяснить, что мне нужно удалить.
  6. Используйте мою резервную копию, но ошибка уже там
  7. «Восстановить таблицу», но я получаю следующий ответ: «Подсистема хранения для таблицы не поддерживает восстановление».
  8. Перестроил таблицу с помощью «ALTER TABLE searchresults ENGINE = InnoDB;» но ошибка возникает при восстановлении.
  9. Установка параметра innodb_log_file_size в файле my.ini на максимальное значение 4G вызывает ту же ошибку.
  10. Используйте другой компьютер

Я почти уверен, что в строке 5222907 или 5222908 есть поврежденный набор данных, и поэтому сервер падает. Для меня было бы совершенно нормально потерять одну строку, если бы я потом мог получить доступ к остальным данным. Я мог даже потерять первые 5222908 строк. Но когда я не могу удалить поврежденные данные. Если я использую запрос

DELETE FROM searchresults LIMIT 5222908

Сервер снова падает.

Буду очень признателен за любые советы по этому вопросу. Данные очень важны для меня, потому что они нужны мне для моей магистерской диссертации, которая должна быть завершена очень скоро.

Спасибо за ваше время и усилия!

РЕДАКТИРОВАТЬ: это моя структура таблицы (обратите внимание, нет ключей или индексов):

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

РЕДАКТИРОВАТЬ: я использовал INSERT INTO следующим образом:

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

И в зависимости от выбранного столбца (id, количество ретвитов и т. д.) я получаю разное количество строк. Они всегда ниже 5222907, но это означает, что проблема может быть связана с каким-то параметром, а не с ошибкой повреждения. Что вы думаете? Знаете ли вы какие-то дополнительные параметры, которые я мог бы настроить в конфигурации mysql?


person besserwisser    schedule 02.06.2016    source источник
comment
Взгляните на команду MySQL REPAIR TABLE.... Это хорошо задокументировано.   -  person arkascha    schedule 02.06.2016
comment
отремонтировать стол. если это не сработает, вам придется начать с нуля, а также начать делать более качественные резервные копии.   -  person Marc B    schedule 02.06.2016
comment
Я забыл упомянуть об этом. Я также попытался восстановить таблицу, но получил следующий ответ Механизм хранения для таблицы не поддерживает восстановление.   -  person besserwisser    schedule 02.06.2016
comment
Выключите сервер, сделайте копию всего каталога данных, чтобы иметь возможность вернуться к нему. Лучше поздно, чем никогда. Возможно, вы уже столкнулись с ошибкой чтения здесь, тогда ваш жесткий диск может быть сломан. Запустить снова. У вас есть индекс этой таблицы? Можете ли вы получить доступ к данным перед рассматриваемой строкой? (например, select * from searchresult limit 10)? Знаете ли вы первичный ключ рассматриваемой строки? Можете ли вы получить доступ к данным после проблемной строки (например, `выберите * из результатов поиска, где id = ‹какой-то идентификатор действительно после неработающей строки›?   -  person Solarflare    schedule 02.06.2016
comment
У меня нет индекса или первичного ключа в таблице. Я могу получить доступ к данным с ограничителем лимита. Но когда я пытаюсь получить доступ к данным, которые находятся за разорванной строкой, такой как SELECT * FROM searchresults LIMIT 14000000,1, сервер падает.   -  person besserwisser    schedule 03.06.2016


Ответы (1)


Вы можете изучить изменение этих свойств сервера mysql:

нано /etc/mysql/my.cnf

query_cache_size=16M
key_buffer_size=256M

Или, может быть, даже попробовать увеличить допустимое время выполнения запроса от клиента mysql:

SET GLOBAL MAX_STATEMENT_TIME=1000;

прежде чем выполнить свой запрос.

person Frostidas Noman    schedule 02.06.2016
comment
Ни один из трех вариантов не имеет значения. Я не думаю, что это проблема хранения. Я предполагаю, что это, вероятно, проблема с повреждением данных! - person besserwisser; 02.06.2016