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


252

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

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

Ответы:


473

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

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

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

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


2
Можно ли увеличить этот лимит за 99 999 секунд? DBMS connection read time outПоле принимает только до 5 цифр, и установки поля до 0 эквивалентен параметра по умолчанию (600 секунд). (Windows 7 64-bit Ultimate, MySQL Workbench 5.2.47 CE)
Франк Дернонкурт

2
После stackoverflow.com/q/16877574/395857 эта проблема теперь решена ( bugs.mysql.com/bug.php?id=69395 )
Франк Дернонкур

4
снимите флажок ограничить строки в меню «Правка» → «Настройки» → «SQL-запросы»
Jon

7
После перезапуска снова отображается ошибка 2013, даже если время чтения установлено на 6000, так что это не похоже на решение.
Давик

4
Не забудьте перезапустить Workbench и закрыть все открытые окна запросов!
pimbrouwers

32

Запуск сервера БД с опцией comandline net_read_timeout/ wait_timeoutи подходящего значения (в секундах) - например: --net_read_timeout=100.

Для справки смотрите здесь и здесь .


1
Это правильно, но на самом деле мне помог ответ с
большим

6
Как мне предоставить этот параметр в командной строке? Когда я пытаюсь подключиться к БД: mysql -u root -p --net_read_timeout = 60 или когда я пытаюсь запустить службу? sudo service mysql start? В обоих местах выдает ошибку: неизвестная переменная 'net_read_timeout'
Викас Гоэль

@VikasGoel Это параметр на стороне сервера. То есть mysqld.
Хлоя

29

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

[mysqld]
max_allowed_packet=16M

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

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

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


Это была именно моя проблема. Я импортировал резервную копию базы данных из файла, и MySQL Workbench сообщал об этой ошибке 2013 года, за которой следовало «Операция завершилась неудачно с кодом выхода 1». Оказывается, в резервной копии были большие столбцы больших двоичных объектов, превышающие по умолчанию максимальный размер MySQL max_allowed_packet 4M. Увеличение это исправило это. (MySQL 5.6 и Workbench 6.2.3). Спасибо!
Залби

Это было исправление для меня тоже. Хотя я установил его на 256M для машины с Windows.
smoore4

Имел 16M, получал эту ошибку с файлом импорта несколько раз, менял на 32M и потом работал.
hakre

15

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

innodb_buffer_pool_size = 64M

пример:

key_buffer              = 16M
max_allowed_packet      = 16M
thread_stack            = 192K
thread_cache_size       = 8
innodb_buffer_pool_size = 64M

6
Вы уверены, что имя файла /etc/mysql/cnfправильное? Не должно ли это быть /etc/my.cnf?
Питер Варга

12
SET @@local.net_read_timeout=360;

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

SET @@global.net_read_timeout=360;

Что такое 360? Миллисек, секунды, минуты?
MasterJoe2

10

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

  1. Обычно это указывает на проблему с сетевым подключением, и вы должны проверить состояние вашей сети, если эта ошибка возникает часто
  2. Иногда форма «во время запроса» возникает, когда миллионы строк отправляются как часть одного или нескольких запросов.
  3. В более редких случаях это может произойти, когда клиент пытается установить исходное соединение с сервером.

Подробнее читайте >>

Причина 2:

SET GLOBAL interactive_timeout=60;

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

Причина 3:

SET GLOBAL connect_timeout=60;

2 дает мне эту ошибку - код: 1227. Доступ запрещен; вам нужна (хотя бы одна из) привилегий SUPER для этой операции
MasterJoe2

9

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

max_allowed_packet

net_write_timeout

net_read_timeout

MySQL док


8

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


Это действительно помогает мне. Значение «interactive_timeout» в my.cnf было установлено на 100, это слишком мало. после того, как я изменил его на 3600 с (или любое
другое

7

Просто выполните обновление MySQL, которое перестроит механизм innoDB вместе с перестроением многих таблиц, необходимых для правильного функционирования MySQL, таких как performance_schema, information_schemaи т. Д.

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

sudo mysql_upgrade -u root -p

Ошибка не появлялась до MySQL Workbench 6.1.4 (и только через некоторое время) и также возникает на 6.1.6 (хотя и только после нескольких использований), поэтому я не уверен, что восстановление нескольких серверов является исправлением для проблема, которая только недавно появилась на одном графическом интерфейсе.
Давик

Это исправило мою проблему. Я только что использовал Ansible для настройки базы данных поверх существующей, и все пошло наперекосяк. Выполнение этой команды восстановило все в рабочем состоянии.
Jubz

4

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

1. Control-click your connection and choose Connection Properties.
2. Under Advanced tab, set the Socket Timeout (sec) to a larger value.

4

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


3

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

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


3

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

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

  • увеличить net_buffer_length внутри mysql -> это потребует перезагрузки сервера
  • создать дамп с --skip-extended-insert, для каждой вставки используется одна строка -> хотя эти дампы намного приятнее читать, это не подходит для больших дампов> 1 ГБ, потому что это имеет тенденцию быть очень медленным
  • создать дамп с расширенными вставками (который используется по умолчанию), но ограничить net-buffer_length, например, --net-buffer_length NR_OF_BYTESгде NR_OF_BYTES меньше, чем net_buffer_length сервера -> Я думаю, что это лучшее решение, хотя медленнее перезапуск сервера не требуется.

Я использовал следующую команду mysqldump: mysqldump --skip-comments --set-charset --default-character-set=utf8 --single-transaction --net-buffer_length 4096 DBX > dumpfile


2

Я получил ту же проблему при загрузке файла .csv. Преобразовал файл в .sql.

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

mysql -u <user> -p -D <DB name> < file.sql

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


2

Если все остальные решения здесь не сработают - проверьте системный журнал (/ var / log / syslog или аналогичный), чтобы убедиться, что во время запроса серверу не хватает памяти.

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


2

В моем случае установка интервала ожидания соединения до 6000 или выше не работала.

Я просто сделал то, что говорит верстак, что я могу сделать.

Максимальный период времени, в течение которого запрос может вернуть данные из СУБД. Установите 0, чтобы пропустить тайм-аут чтения.

В настройках Mac -> Редактор SQL -> Перейти в MySQL Session -> установить интервал ожидания чтения соединения равным 0.

И это работает 😄


1

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

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

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

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


1

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



0

Перейти к:

Правка -> Настройки -> Редактор SQL

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


0

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


0

У меня была та же проблема - но для меня решением был пользователь БД со слишком строгими разрешениями. Я должен был позволить Executeспособность на mysqlстоле. После того, как я позволил, у меня больше не было сбрасываемых соединений.



0

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

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

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


0

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

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


0

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

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

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

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

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

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


0

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

  1. Многократные запросы показывают потерянное соединение?
  2. как вы используете set query в MySQL?
  3. как удалить + обновить запрос одновременно?

ответы:

  1. Всегда пытайтесь удалить определитель, поскольку MySQL создает свой собственный определитель, и если несколько таблиц, задействованных для обновления, пытаются сделать один запрос, так как иногда несколько запросов показывают потерянное соединение
  2. Всегда устанавливайте значение сверху, но после УДАЛИТЬ, если его условие не включает значение SET.
  3. Используйте УДАЛИТЬ ПЕРВЫЕ, ТОГДА ОБНОВЛЕНИЯ, ЕСЛИ ОБА ИХ ОПЕРАЦИИ ВЫПОЛНЕНЫ НА РАЗНЫХ СТОЛБАХ

-1

проверить о

OOM on /var/log/messages ,
modify innodb_buffer_pool_size value ; when load data , use 50% of os mem ; 

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


-1

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

mysql_upgrade --password В документации говорится, что «mysql_upgrade должен выполняться при каждом обновлении MySQL».

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.