유휴 상태일 때 MySQL Workbench 연결이 끊어짐

유휴 상태일 때 MySQL Workbench 연결이 끊어짐

OS X 10.9.5에서 MySQL Workbench 6.3을 사용하여 여러 클라우드 데이터베이스(Rackspace에서 호스팅)를 관리하고 있는데 다음과 같은 문제가 발생합니다.

5분 동안 비활성 상태이면 다음과 같은 문제가 발생합니다.

• 쿼리를 실행할 수 없습니다(오류 2013: 쿼리 중 MySQL 서버에 대한 연결 끊김).
• db에서 테이블을 검색하려고 하면 "테이블을 가져올 수 없음", "뷰를 가져올 수 없음" 등의 메시지가 나타납니다.
• 왼쪽 패널을 새로 고치면 "Error Code: 2006 MySQL 서버가 사라졌습니다"라는 메시지가 나타납니다.

그래서 기본적으로 연결이 끊겼습니다.

5분 동안 활동을 하지 않은 후에 발생하기 때문에 정말 짜증납니다.따라서 매번 연결을 닫고 다시 열어야 합니다.

저도 해봤습니다.MySQL Workbench: 연결을 유지하는 방법은 아무것도 바뀌지 않았습니다.Workbench Preferences 탭에서 다음과 같은 설정이 있습니다.

• DBMS 연결 Keep-Alive 간격(초): 600
• DBMS 연결 읽기 시간 초과(초): 600
• DBMS 연결 시간 초과(초): 60

이 문제는 5분 동안 작동하지 않은 상태에서 정확히 발생합니다!4분 59초 간격으로 두 개의 쿼리를 실행하면 완벽하게 작동합니다.또한 Workbench에서 동일한 데이터베이스에 연결하는 동료들은 이러한 문제를 겪지 않습니다.

이것에 대한 해결책이 있는 사람?

편집 -> 기본 설정 -> 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

DBMS 연결 keep-alive 간격은 Workbench가 연결을 유지하기 위해 keep-alive 요청을 서버로 보내는 빈도를 의미합니다.

5분 == 300초부터 DBMS 연결 유지 alive 간격 < 300 설정 (예: 250)

이것은 "250초마다 킵 얼라이브 요청을 전송하라"는 의미입니다.[확인]을 누릅니다.

그런 다음 MySQL Workbench를 종료하고 다시 시작하여 변경 사항을 적용합니다.

Standard TCP/IP over SSH 연결 방법을 사용하는 경우 ssh ServerAliveInterval을 구성하는 것도 도움이 됩니다.

이 버그는 6.0 이후의 MySQL Workbench의 모든 버전에 존재합니다(현재: 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

FWIW: Kosh의 추천에 따라 다음과 같이 설정을 변경했는데 Ubuntu 16에서 실행되는 WB 6.3의 문제를 없앤 것 같습니다.

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

과잉 살상일 수도 있지만 효과는 있습니다.

Windows Azure에서 호스팅하는 Ubuntu 14.04에서 tcp_keepalive_time을 120초로 설정하여 해결했습니다.

Azure 로드 밸런서의 TCP keepalive는 기본적으로 240초이므로, Azure 시스템의 TCP keepalive가 이 값보다 크면 연결이 자동으로 끊어질 수 있습니다.이 문제를 개선하려면 tcp_keepalive_time을 120으로 설정해야 합니다.

1. tcp_keepalive_time을 확인하려면 다음과 같이 하십시오.

   cat/proc/sys/넷/ipv4/tcp_keepalive_time

7200(기본 2시간)

2. 값을 2시간에서 120초 사이로 설정합니다.

sudo sysctl -wnet. ipv4. tcp_keepalive_time=120

net.ipv4.tcp_keepalive_time = 120

3. 변경 후 값을 다시 확인합니다.

   cat/proc/sys/넷/ipv4/tcp_keepalive_time

120

4. 재부팅 후에도 sysctl 파일의 값이 그대로 유지되도록 설정합니다.

vi /etc/ sysctl.conf

i (파일에 삽입하려면) net. ipv4. tcp_keepalive_time = 120 (파일 하단에 이 줄 추가) :wq(저장 후 종료)

이것 때문에 몇 달 동안 정신이 나갔습니다.제가 호스트게이터 서버에 접속했습니다.연결 후 10초 정도만 테이블을 편집할 수 있으면 테이블 커밋을 수행하면 테이블이 "독서 전용"으로 바뀌고 마우스 오버 메시지가 나타납니다. "유일한 행 식별자를 확인할 수 없음(MySQL 서버가 사라짐)" 또는 "(쿼리 중 MySQL 서버와의 연결이 끊어짐)"입니다.

여기에 나와 있는 다른 제안에 따르면, 해결책은 킵 얼라이브 설정을 줄이는 것이었습니다.저 같은 경우에는 10대로 떨어져야 했습니다. (대역폭이 상당히 형편없다면 Hostgator!)

처음에는 줄이려고 했습니다.SSH KeepAlive(기본 설정/기타/타임아웃에서) 이 작업이 수행되지 않았습니다.

무엇이 그 비결이었는가 하면,DBMS connection keep-alive interval(Preferences/SQL Editor/MySQL Session에서).연결이 안정적으로 유지될 때까지 10대까지 가져가야 했습니다.호스트가 다를 수 있습니다.

마지막으로, "모두 새로 고침"을 더 이상 하지 말고, 기다렸다가, 무언가를 하고, 헹구고, 반복합니다.

Kosh Very's Answer는 제게 적합하지 않아서 이에 대한 다른 해결책을 찾았습니다.

max_allowed_packet를 변경합니다.my.iniMy(C:\ProgramData\MySQL\MySQL 서버 5.6)

max_allowed_packet=16M

이제 MySQL 서비스를 다시 시작합니다.

Kosh Very's가 정답입니다.이를 실행할 수 없었던 사람들을 위한 또 다른 해결책은 다음과 같습니다.

거대한 테이블(드롭 또는 추가 열 등)을 변경해야 하는 경우 터미널별로 쿼리를 실행해야 합니다.

1. 연결:mysql -u myusername -p

2. 암호를 입력하라는 메시지가 나타납니다.

3. 필요한 오래 걸리는 쿼리를 실행합니다.참고: 터미널에 쿼리를 작성하려면 각각의 쿼리에 대한 종료 세미콜론(;)이 필요합니다.예:ALTER TABLE mydb.mytable DROP COLUMN mycol;

언급URL : https://stackoverflow.com/questions/31811517/mysql-workbench-drops-connection-when-idle