lost connection to mysql server during query что это

Глава 10. Lost connection to MySQL server during query

Вы можете увидеть ошибку Lost connection to MySQL server не только по причине слишком маленького connect_timeout, но и по ряду других причин. В настоящей главе мы рассмотрим эти причины.

Чаще всего error log покажет что произошло:

It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 338301 K
bytes of memory
Hope that’s ok; if not, decrease some variables in the equation.
thd: 0x69e1b00
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong.
stack_bottom = 0x450890f0 thread_stack 0x40000
/users/ssmirnova/blade12/5.1.39/bin/mysqld(my_print_stacktrace+0x2e)[0x8ac81e]
/users/ssmirnova/blade12/5.1.39/bin/mysqld(handle_segfault+0x322)[0x5df502]
/lib64/libpthread.so.0[0x3429e0dd40]
/users/ssmirnova/blade12/5.1.39/bin/mysqld(_ZN6String4copyERKS_+0x16)[0x5d9876]
/users/ssmirnova/blade12/5.1.39/bin/mysqld(_ZN14Item_cache_str5storeEP4Item+0xc9)[0x52ddd9]
/users/ssmirnova/blade12/5.1.39/bin/mysqld(_ZN26select_singlerow_subselect9send_dataER4ListI4ItemE+0x45)[0x5ca145]
/users/ssmirnova/blade12/5.1.39/bin/mysqld[0x6386d1]
/users/ssmirnova/blade12/5.1.39/bin/mysqld[0x64236a]
/users/ssmirnova/blade12/5.1.39/bin/mysqld(_ZN4JOIN4execEv+0x949)[0x658869]
/users/ssmirnova/blade12/5.1.39/bin/mysqld(_ZN30subselect_single_select_engine4execEv+0x36c)[0x596f3c]
/users/ssmirnova/blade12/5.1.39/bin/mysqld(_ZN14Item_subselect4execEv+0x26)[0x595d96]
/users/ssmirnova/blade12/5.1.39/bin/mysqld(_ZN24Item_singlerow_subselect8val_realEv+0xd)[0x595fbd]
/users/ssmirnova/blade12/5.1.39/bin/mysqld(_ZN14Arg_comparator18compare_real_fixedEv+0x39)[0x561b89]
/users/ssmirnova/blade12/5.1.39/bin/mysqld(_ZN12Item_func_ne7val_intEv+0x23)[0x568fb3]
/users/ssmirnova/blade12/5.1.39/bin/mysqld(_ZN4JOIN8optimizeEv+0x12ef)[0x65208f]
/users/ssmirnova/blade12/5.1.39/bin/mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex+0xa0)[0x654850]
/users/ssmirnova/blade12/5.1.39/bin/mysqld(_Z13handle_selectP3THDP6st_lexP13select_resultm+0x16c)[0x65a1cc]
/users/ssmirnova/blade12/5.1.39/bin/mysqld[0x5ecbda]
/users/ssmirnova/blade12/5.1.39/bin/mysqld(_Z21mysql_execute_commandP3THD+0x602)[0x5efdd2]
/users/ssmirnova/blade12/5.1.39/bin/mysqld(_Z11mysql_parseP3THDPKcjPS2_+0x357)[0x5f52f7]
/users/ssmirnova/blade12/5.1.39/bin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0xe93)[0x5f6193]
/users/ssmirnova/blade12/5.1.39/bin/mysqld(_Z10do_commandP3THD+0xe6)[0x5f6a56]
/users/ssmirnova/blade12/5.1.39/bin/mysqld(handle_one_connection+0x246)[0x5e93f6]
/lib64/libpthread.so.0[0x3429e061b5]
/lib64/libc.so.6(clone+0x6d)[0x34292cd39d]`)
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
thd->query at 0x6a39e60 = select 1 from `t1` where `c0` <> (select geometrycollectionfromwkb(`c3`) from `t1`)
thd->thread_id=2
thd->killed=NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what

Номера ошибок операционной системы не универсальны и могут отличаться. Если вы хотите быть уверены, что данный код имеет в вашей операционной системе определённое значение или вам встретилась менее распространённая ошибка используйте утилиту perror, которая находится в директории bin директории куда вы установили MySQL. Вот, например, что показывает perror для моей инсталляции MacOSX:

Далее мы видим backtrace (начиная с Attempting backtrace.) Мы вернёмся к backtace позже.

Ещё ниже мы видим запрос, который вызвал эту проблему:

Проблема в запросе

Попытаемся воспроизвести в mysql cli

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

Для этого посмотрим backtrace

Он содержит следующие вызовы: Item_subselect и Item_singlerow_subselect. Отсюда даже не заглядывая в код MySQL мы можем сделать вывод, что виноват подзапрос.

Попробуем переписать запрос

MySQL сервер работает нормально! Мы можем пользоваться переписанным запросом до тех пор, пока баг не будет исправлен.

Приём 18: всегда используйте error log

Но иногда в error log нет нужной информации

Тот же запрос, но на Mac-е

key_buffer_size=8384512
read_buffer_size=131072
max_used_connections=1
max_connections=100
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 225784 K

Как видим, ни backtrace, ни запроса в error log нет. Что же делать?

В этом случае, как и раньше, нам поможет general query log. MySQL сначала пишет запрос в general query log и только потом выполняет его. Поэтому вполне логично использовать этот метод для повторяющихся проблемных запросов.

Запускаем тест. После перезапуска сервера проверяем general query log:

Запрос, вызвавший крушение, обнаружен!

Приём 19: используйте general query log если error log не содержит информации о причинах крушения сервера.

При использовании этого приёма существует вероятность, что таблица mysql.general_log будет повреждена во время крушения MySQL сервера. В этом случае попробуйте запись в файл.

Также существует вероятность, что MySQL сервер перестанет работать во время записи запроса в general query log. В таком случае пользуйтесь либо логами вашего приложения, либо прокси.

Пример, который мы только что рассмотрели, произошёл из бага MySQL сервера. Но MySQL сервер может быть аварийно остановлен и по причине нехватки ресурсов в системе.

Первое, на что стоит обратить внимание это RAM

Цитата из реального лога:

То есть MySQL может использовать до 20G RAM! Сейчас мощные машины, но стоит проверить действительно ли у вас 20G RAM.

Приём 20: всегда проверяйте достаточно ли у вас RAM для выделенных буферов.

Также обратите внимание на значение переменной max_connections.

В предыдущем примере max_connections=2048. Это достаточно много. Проверьте, хватит ли у вас ресурсов на такое количество одновременных соединений.

Я встречала в практике случаи, когда пользователи устанавливали значение max_connections значительно больше, чем их сервера могли обслужить. Это приводило к непредсказуемым крушениям MySQL сервера при резко возросших нагрузках на обслуживаемые веб-ресурсы.

Приём 21: устанавливайте значение max_connections таким какое вы сможете обслужить.

Также MySQL сервер может испытывать нехватку других ресурсов. Обычно информация об ошибке содержится в error log. Анализируйте эту информацию и устраните проблему.

Однако не всегда сам MySQL сервер виноват в нехватке ресурсов. Может так случиться, что их заняло другое приложение. В таком случае используйте системные средства для мониторинга, чтобы выявить виновника.

Приём 22: используйте средства мониторинга вашей операционной системой чтобы установить что потребляет избыточное количество ресурсов, которое приводит к крушению MySQL сервера.

Как мы ранее рассмотрели сообщение Lost connection to MySQL server может также обозначать timeout. Если error log не содержит других ошибок или вы подозреваете именно этот случай, добавьте опцию log_warnings=2 в конфигурационный файл и проверьте error log после получения сообщения.

Приём 23: Используйте опцию log_warnings=2 чтобы отследить имеются ли у вас отклонённые соединения.

Иногда ошибка повторяется только при конкурентных запросах. Используйте дополнительное програмное обеспечение и general log, чтобы понять каких именно. Я не буду здесь останавливаться на данной теме подробнее, поскольку она достаточно сложна и требует индивидуального решения.

Читайте также: bitmoji что это такое

Источник

Глава 10. Lost connection to MySQL server during query

Вы можете увидеть ошибку « Lost connection to MySQL server» не только по причине слишком маленького connect_timeout, но и по ряду других причин. В настоящей главе мы рассмотрим эти причины.

Чаще всего error log покажет что произошло:

Также вы можете получить ошибку наподобие этой:

Далее мы видим backtrace (начиная с «Attempting backtrace.») Мы вернёмся к backtrace позже.

Ещё ниже мы видим запрос, который вызвал эту проблему:

Проблема в запросе

Попытаемся воспроизвести в mysql cli

Для этого посмотрим backtrace

Он содержит следующие вызовы: Item_subselect и Item_singlerow_subselect. Отсюда – даже не заглядывая в код MySQL – мы можем сделать вывод, что «виноват» подзапрос.

Попробуем переписать запрос

Приём №18: всегда используйте error log

Но иногда в error log нет нужной информации

Тот же запрос, но на Mac-е

Как видим, ни backtrace, ни запроса в error log нет. Что же делать?

Запускаем тест. После перезапуска сервера проверяем general query log:

Запрос, вызвавший крушение, обнаружен!

Приём №19: используйте general query log если error log не содержит информации о причинах крушения сервера.

Первое, на что стоит обратить внимание – это RAM

Цитата из реального лога:

То есть MySQL может использовать до 20G RAM! Сейчас мощные машины, но стоит проверить действительно ли у вас 20G RAM.

Приём №20: всегда проверяйте достаточно ли у вас RAM для выделенных буферов.

Также обратите внимание на значение переменной max_connections.

Приём №21: устанавливайте значение max_connections таким какое вы сможете обслужить.

Приём №22: используйте средства мониторинга вашей операционной системой чтобы установить что потребляет избыточное количество ресурсов, которое приводит к крушению MySQL сервера.

Как мы ранее рассмотрели сообщение «Lost connection to MySQL server» может также обозначать timeout. Если error log не содержит других ошибок или вы подозреваете именно этот случай, добавьте опцию log_warnings=2 в конфигурационный файл и проверьте error log после получения сообщения.

Приём №23: Используйте опцию log_warnings=2 чтобы отследить имеются ли у вас отклонённые соединения.

Источник

Как исправить ошибку: Lost connection to MySQL server during query?

Mysql 5.7.23
Ubuntu 16.04.1

Пробую подключиться к MySQL. При любом запросе к одной таблице выдается ошибка:
Lost connection to MySQL server during query?

Пробовал разное решение проблемы. В частности увеличивал значения mysql:

До таблицы так и не удалось ни разу достучаться.
Может есть какая-то возможность ее воскресить? Спасибо

Сложный 5 комментариев

Роман Мирр, Бэкапа нет. Так бы уже восстановил) Будет уроком.

Дмитрий Гуляев, насчёт виртуальной машины ясно. А параметры хост машины есть?

В общем, я обновил свой ответ. Это тяжелый случай, по-моему.

Файлы СУБД были попорчены в результате этого сбоя.

В частности увеличивал значения mysql

Вот сюда-то ходили, читали?

Видно что-то навернулось с файлами БД и также ошибка повреждения памяти.

Добавлено
Судя по всему, произошёл серьезный сбой в QEMU либо вызван сбоем в хост-машине. В результате во время работы СУБД файлы БД, включая служебные файлы, были повреждены (как минимум, файлы в директории /var/lib/mysql ). Стоит проверить также целостность самой ОС.

Рекомендую объявить посетителям о проблеме, а тем временем обратиться к специалистам по восстановлению MySQL + InnoDB, поскольку хорошего бекапа не было.

Имеет смысл создать TAR архив со сжатием директории /var/lib/mysql с надеждой на последующее восстановление данных.

1. сделать копию /var/lib/mysql на другой накопитель

Спасибо за развернутый ответ!
У меня, к счастью, нашелся хоть и не актуальный бэкап, но достаточно новый, чтобы можно развернуть, хоть и без части важных данных. Поэтому восстановительные работы остановил и живу новой жизнью.

В этой утилите, к сожалению, не смог разобраться. Я больше программист, чем сисадмин. Тяжело даются всякие такие штуки)

mysqldump вместо таблицы вернул то же самое:

Источник

Код ошибки: 2013. Потеря соединения с сервером MySQL во время запроса

Я получил код ошибки: 2013. Потеря соединения с сервером MySQL во время ошибки запроса, когда я пытался добавить индекс в таблицу с помощью MySQL Workbench. Я также заметил, что это появляется всякий раз, когда я запускаю длинный запрос.

Можно ли увеличить значение тайм-аута?

Новые версии MySQL WorkBench имеют возможность изменять определенные таймауты.

Для меня это было под Редактировать → Настройки → Редактор SQL → Время ожидания соединения с СУБД (в секундах): 600

Изменено значение до 6000.

Также непроверенные строки предела, поскольку установка предела в каждый раз, когда я хочу искать весь набор данных, становится утомительной.

Если ваш запрос содержит данные BLOB-объектов, эту проблему можно исправить, применив my.ini изменение, предложенное в этом ответе :

По умолчанию это будет 1M (максимально допустимое значение 1024M). Если предоставленное значение не кратно 1024K, оно будет автоматически округлено до ближайшего кратного 1024K.

Для пользователей WAMP: вы найдете флаг в [wampmysqld] разделе.

Добавьте следующее в файл / etc / mysql / cnf:

Предупреждение: следующее не будет работать, когда вы применяете его в удаленном соединении:

Есть три вероятных причины для этого сообщения об ошибке

по умолчанию от 30 секунд до 60 секунд или дольше

Спасибо! Это сработало. Но с обновлениями mysqldb конфигурация стала:

Вы должны установить свойства ‘interactive_timeout’ и ‘wait_timeout’ в файле конфигурации mysql на нужные вам значения.

Введите следующую команду из вашей оболочки:

Я знаю его старый, но на Mac

Измените время ожидания чтения в Edit-> Preferences-> SQL editor-> MySQL session

Попробуйте снять отметки с ограниченных строк в меню «Правка» → «Настройки» → «SQL-запросы».

потому что вы должны установить свойства ‘interactive_timeout’ и ‘wait_timeout’ в файле конфигурации mysql на нужные вам значения.

Если вы столкнулись с этой проблемой во время восстановления большого файла дампа и можете исключить проблему, связанную с сетью (например, выполнением на локальном хосте), моё решение может быть полезным.

Мой mysqldump содержал по крайней мере одну INSERT, которая была слишком большой для mysql, чтобы вычислить. Вы можете просмотреть эту переменную, набрав show variables like «net_buffer_length»; внутри вашего mysql-cli. У вас есть три возможности:

Источник

Код ошибки: 2013. Потерянное соединение с сервером MySQL во время запроса

Я получил код Код ошибки: 2013. Потерянное подключение к MySQL-серверу во время запроса при попытке добавить индекс в таблицу с помощью MySQL Workbench. Я также заметил, что он появляется, когда я запускаю длинный запрос.

Есть ли возможность увеличить значение таймаута?

ОТВЕТЫ

Ответ 1

Новые версии MySQL WorkBench имеют возможность изменять определенные тайм-ауты.

Для меня это было в разделе Редактировать → Настройки → Редактор SQL → Время ожидания подключения к СУБД (в секундах): 600

Изменено значение до 6000.

Также не проверенные предельные строки, как ограничение лимита в каждый раз, когда я хочу искать весь набор данных, становятся утомительными.

Ответ 2

Ответ 3

Если у вашего запроса есть данные blob, эту проблему можно устранить, применив my.ini change как предлагается в этом ответе:

По умолчанию это будет 1M (допустимое максимальное значение равно 1024M). Если заданное значение не кратно 1024 КБ, оно будет автоматически округлено до ближайшего кратного 1024 КБ.

В то время как связанный поток относится к ошибке MySQL 2006 года, установка max_allowed_packet с 1M до 16M исправила ошибку 2013, которая появилась для меня при запуске длинного запроса.

Ответ 4

Добавьте в файл /etc/mysql/cnf следующее:

Ответ 5

Предупреждение. Следующие действия не будут работать, если вы применяете его в удаленном соединении:

Ответ 6

Для этого сообщения об ошибке есть три причины

от значения по умолчанию от 30 секунд до 60 секунд или дольше

Ответ 7

Вы должны установить свойства «interactive_timeout» и «wait_timeout» в файле конфигурации mysql для значений, которые вам нужны.

Ответ 8

Спасибо, это сработало. Но с обновлениями mysqldb настройка стала:

Ответ 9

Выпустите следующую команду из своей оболочки:

Ответ 10

Я знаю его старый, но на mac

Ответ 11

Измените время ожидания чтения в Edit- > Preferences- > SQL-редакторе- > сеансе MySQL

Ответ 12

Попробуйте снять флажки с ограничениями строк в разделе «Редактировать» → «Настройки» → «Запросы SQL»

потому что вы должны установить свойства «interactive_timeout» и «wait_timeout» в конфигурационном файле mysql для значений, которые вам нужны.

Ответ 13

Если вы столкнулись с этой проблемой во время восстановления большого файла дампа и можете исключить проблему, связанную с сетью (например, выполнение на локальном хосте), может оказаться полезным мое решение.

Мой mysqldump провел хотя бы один INSERT, который был слишком большим для вычисления mysql. Вы можете просмотреть эту переменную, набрав show variables like «net_buffer_length»; внутри вашего mysql-cli. У вас есть три возможности:

Ответ 14

Используя команду ниже, мне удается обойти эту проблему.

Надеюсь, это поможет.

Ответ 15

Если эта проблема возникла, когда innodb_buffer_pool_size был установлен слишком близко к физической памяти без настроенного файла подкачки. MySQL рекомендует для определенного сервера базы данных innodb_buffer_pool_size максимум около 80% физической памяти, я установил его около 90%, Ядро убивало процесс mysql. Перемещенный файл innodb_buffer_pool_size возвращается примерно до 80%, и это устраняет проблему.

Ответ 16

Я столкнулся с этой же проблемой. Я считаю, что это происходит, когда у вас есть внешние ключи для больших таблиц (что требует времени).

Я попытался снова запустить инструкцию create table без объявлений внешнего ключа и нашел, что это сработало.

Затем после создания таблицы я добавил ограничения внешнего ключа, используя запрос ALTER TABLE.

Надеюсь, это поможет кому-то.

Ответ 17

Это произошло со мной, потому что мой innodb_buffer_pool_size был установлен больше, чем размер оперативной памяти, доступный на сервере. Из-за этого все из-за этого прерывается, и эта ошибка возникает. Исправление состоит в том, чтобы обновить my.cnf с правильной настройкой для innodb_buffer_pool_size.

Ответ 18

Перейдите в Workbench Edit → Preferences → SQL Editor → Время ожидания подключения к СУБД: до 3000. Ошибка больше не возникает.

Ответ 19

Изменить → Настройки → Редактор SQL

Здесь вы можете увидеть три поля в группе «Сессия MySQL», где теперь вы можете установить новые интервалы подключения (в секундах).

Ответ 20

Оказывается, наше правило брандмауэра блокирует мое подключение к MYSQL. После того, как политика брандмауэра отменена, чтобы разрешить соединение, я смог успешно импортировать схему.

Ответ 21

Ответ 22

Проверьте, установлены ли индексы.

Ответ 23

Я столкнулся с этим при запуске сохраненного proc-, который создавал много строк в таблице в базе данных. Я мог видеть, что ошибка наступила сразу после того, как время пересекло границу 30 секунд.

Я попробовал все предложения в других ответах. Я уверен, что некоторые из них помогли, however-, что действительно заставило его работать для меня, это переход на SequelPro из Workbench.

Я предполагаю, что это была некоторая клиентская связь, которую я не мог обнаружить в Workbench. Может быть, это тоже поможет кому-то другому?

Ответ 24

Если вы используете SQL Work Bench, вы можете попробовать использовать индексирование, добавив индекс в свои таблицы, добавить индекс, нажать на гаечный ключ (гаечный ключ) в таблице, он должен открыть настройку для таблицы, ниже, нажмите на индексный указатель, введите имя индекса и установите индекс для индекса. В столбцах индекса выберите основной столбец в своей таблице.

Сделайте тот же шаг для других первичных ключей на других таблицах.

Ответ 25

Кажется, здесь нет ответа для тех, кто использует SSH для подключения к своей базе данных MySQL. Вам нужно проверить два места, а не 1, как предлагают другие ответы:

Редактирование рабочей среды → Настройки → Редактор SQL → СУБД

Рабочее место Правка → Настройки → SSH → Тайм-ауты

Мои тайм-ауты SSH по умолчанию были установлены очень низкими и вызывали некоторые (но, очевидно, не все) мои проблемы тайм-аута. После, не забудьте перезапустить MySQL Workbench!

Наконец, возможно, стоит обратиться к администратору БД и попросить его увеличить свойства wait_timeout и interactive_timeout в самом mysql через my.conf + mysql restart или выполнить глобальный набор, если перезапуск mysql не является опцией.

Надеюсь это поможет!

Ответ 26

Три вещи, которым нужно следовать и убедитесь:

Ответ 27

Надеюсь, что это поможет

Ответ 28

Это обычно означает, что у вас есть «несовместимости с текущей версией MySQL Server», см. mysql_upgrade. Я столкнулся с этой проблемой и просто должен был работать:

Источник