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

157

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

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

Теги:
database
mysql-workbench

26 ответов

285
Лучший ответ

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

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

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

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

  • 1
    Можно ли увеличить этот лимит за 99,999 секунд? Поле DBMS connection read time out принимает только до 5 цифр, а установка поля в 0 эквивалентна параметру по умолчанию (600 секунд). (Windows 7 64-bit Ultimate, MySQL Workbench 5.2.47 CE)
  • 1
    После stackoverflow.com/q/16877574/395857 эта проблема теперь решена ( bugs.mysql.com/bug.php?id=69395 )
Показать ещё 6 комментариев
29

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

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

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

Добавьте в файл /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
  • 2
    Вы уверены, что имя файла /etc/mysql/cnf правильное? /etc/my.cnf это не должно быть /etc/my.cnf ?
14

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

[mysqld]
max_allowed_packet=16M

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

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

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

  • 0
    Это была именно моя проблема. Я импортировал резервную копию базы данных из файла, и MySQL Workbench сообщал об этой ошибке 2013 года, за которой следовало «Операция завершилась неудачно с кодом выхода 1». Получается, что в резервной копии были большие столбцы больших двоичных объектов, превышающие размер по умолчанию для MaxSQL max_allowed_packet 4M. Увеличение это исправило это. (MySQL 5.6 и Workbench 6.2.3). Спасибо!
  • 0
    Это было исправление для меня тоже. Хотя я установил его на 256M для машины с Windows.
Показать ещё 1 комментарий
10
SET @@local.net_read_timeout=360;

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

SET @@global.net_read_timeout=360;
8

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

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

Для более подробной информации >>

Причина 2:

SET GLOBAL interactive_timeout=60;

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

Причина 3:

SET GLOBAL connect_timeout=60;
8

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

max_allowed_packet

net_write_timeout

net_read_timeout

mysql doc

8

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

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

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

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

sudo mysql_upgrade -u root -p
  • 0
    Ошибка не появлялась до MySQL Workbench 6.1.4 (и только через некоторое время) и также возникает на 6.1.6 (хотя и только после нескольких использований), поэтому я не уверен, что восстановление нескольких серверов является исправлением для проблема, которая только недавно появилась на одном графическом интерфейсе.
  • 0
    Это исправило мою проблему. Я только что использовал Ansible для настройки базы данных поверх существующей, и все пошло наперекосяк. Выполнение этой команды восстановило все в рабочем состоянии.
4

Измените время ожидания чтения в Edit- > Preferences- > SQL-редакторе- > сеансе 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

3

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

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

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

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

2

У меня возникла такая же проблема при загрузке CSV файла. Преобразовал файл в .sql.

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

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

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

1

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

1

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

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

1

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

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

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

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

0

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

0

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

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

0

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

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

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

0

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

SELECT *
FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = '<schema>'
0

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

0

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

0

Перейдите к:

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

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

0

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

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

-1

проверить

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

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

Ещё вопросы

Сообщество Overcoder
Наверх
Меню