MySQL Workbench отключает соединение в режиме ожидания

Я использую MySQL Workbench 6.3 на своей OS X 10.9.5 для управления несколькими облачными базами данных (размещенными на Rackspace), и я получаю следующую проблему:

При неактивном состоянии в течение 5 минут возникают следующие проблемы:

Я не могу выполнить какой-либо запрос (ошибка 2013: потерянное соединение с сервером MySQL во время запроса)
при попытке просмотреть таблицы в моем db, я получаю такие сообщения, как "Таблицы не могут быть извлечены", "Невозможно отобразить виды" и т.д.
при обновлении левой панели, я получаю код ошибки: сервер MySQL 2006 ушел "

Так что в основном связь ушла.

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

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

Интервал продолжительности подключения к СУБД (в секундах): 600
Время ожидания подключения к СУБД (в секундах): 600
Время подключения к СУБД (в секундах): 60

Обратите внимание, что эта проблема происходит ровно через 5 минут бездействия! Если я запускаю два запроса в течение 4'59 минут, он работает отлично. Также мои коллеги, которые подключаются к одной базе данных на своем Workbench, не имеют этой проблемы.

Есть ли у кого-нибудь решение для этого?

Ответ 1

Перейдите в Edit → Preferences → SQL Editor, и там вы увидите:

DBMS connection keep-alive interval (in seconds): 600
DBMS connection read time out (in seconds): 600
DBMS connection time out (in seconds): 60

Интервал продолжительности подключения к СУБД означает, как часто Workbench отправляет запрос keep-alive на сервер, чтобы поддерживать соединение.

С 5 минут == 300 секунд, установить интервал продолжительности обслуживания соединения СУБД < 300 (например, 250)

Это будет означать "отправлять запрос keep-alive каждые 250 секунд". Нажмите "ОК".

Затем закройте MySQL Workbench и перезапустите его, чтобы изменения вступили в силу.

Если вы используете стандартный метод TCP/IP через SSH, также может быть полезно настроить ssh ServerAliveInterval.

Ответ 2

Эта ошибка существует во всех версиях MySQL Workbench за 6.0 (в это время: 6.1, 6.2 и 6.3 есть ошибка).

Переход к MySQL Workbench 6.0.x кажется единственным способом устранить эту проблему.

Загрузить MySQL Workbench 6.0.x: http://dev.mysql.com/downloads/workbench/6.0.html

Ответ 3

FWIW: после рекомендации Kosh я изменил настройки следующим образом и, похоже, устранил проблему на WB 6.3, работающем на Ubuntu 16:

DBMS connection keep-alive interval (in seconds): 60
DBMS connection read time out (in seconds): 60
DBMS connection time out (in seconds): 30

Это может быть излишним, но он работает.

Ответ 4

Kosh Very Answer не работал у меня, поэтому я нашел другое решение для этого:

измените max_allowed_packet в файле my.ini. (C:\ProgramData\MySQL\MySQL Server 5.6)

max_allowed_packet = 16M

теперь перезапустите службу MySQL, как только вы закончите.

Ответ 5

Он решил меня, установив tcp_keepalive_time на 120 секунд на Ubuntu 14.04, размещенном на Windows Azure

Постоянный контроль TCP на балансировщике нагрузки Azure по умолчанию составляет 240 секунд, что может привести к бесшумному отключению соединений, если TCP keepalive на ваших Azure-системах больше этого значения. Вы должны установить tcp_keepalive_time на 120, чтобы улучшить эту проблему.

Чтобы проверить tcp_keepalive_time
cat/proc/sys/net/ipv4/tcp_keepalive_time

7200 (по умолчанию 2 часа)

2.set значение от 2 часов до 120 секунд.

sudo sysctl -w net.ipv4.tcp_keepalive_time = 120

net.ipv4.tcp_keepalive_time = 120

перепроверьте значение после изменения.
cat/proc/sys/net/ipv4/tcp_keepalive_time

120

4.Установите значение в файле sysctl, чтобы сохранить значение даже после перезагрузки.

vi/etc/sysctl.conf

Нажмите я (чтобы вставить в файл) net.ipv4.tcp_keepalive_time = 120 (добавьте эту строку в конец файла) : wq (Сохранить и выйти)

Ответ 6

Kosh Very - правильный ответ. Для тех, кто не смог заставить его работать, вот еще одно решение:

Где мне нужно изменить огромную таблицу (удалить или добавить столбец или такой), выполнить запрос по терминалу:

Подключить: mysql -u myusername -p
Вам будет предложено ввести пароль
Запустите длинный запрос (ы), который вам нужен. Примечание: для записи запроса в терминале требуется для каждого из них указать точку с запятой (;). Пример: ALTER TABLE mydb.mytable DROP COLUMN mycol;

Ответ 7

Это заставило меня думать месяцами. Мои подключения были к серверу Hostgator. Я подключился и мог бы редактировать таблицу всего за 10 секунд после подключения, тогда я бы сделал, скажем, фиксацию таблицы, и таблица изменилась бы на "Только для чтения" с помощью мыши-сообщения "Не удалось определить уникальный идентификатор строки (сервер MySQL ушел) или" (Потерянное соединение с сервером MySQL во время запроса).

Решение было, как и в других рекомендациях здесь, УМЕНЬШИТЬ настройку keep-alive. В моем случае он должен был спуститься до 10 секунд (очевидно, Hostgator, если он довольно скуден с их пропускной способностью!)

Сначала я попытался уменьшить SSH KeepAlive (в разделе "Настройки/Другие/Таймауты" ), но это не сработало.

Что привело к уменьшению DBMS connection keep-alive interval (в разделе Preferences/SQL Editor/MySQL Session). Мне пришлось преодолевать все это до 10, пока связь не останется стабильной. Ваш хост может быть другим.

Наконец, больше не "Обновить все", подождите, что-нибудь сделайте, промойте и повторите.