MySQL server has gone away…

Posted by Maciej Suszko on July 29, 2011
Uncategorized

Jeżeli pojawia się taki komunikat, to najprawdopodobniej problem leży po stronie zmiennej wait_timeout. Wartość jej zależy od typu klienta łączącego się do bazy – albo pobierana jest wartość z globalnej zmiennej wait_timeout, ablo z interactive_timeout.

 

Dla przykładu – FreeBSD, MySQL-5.0.92, połączenie z użyciem klienta mysql:

thscd@arsenic:~ $ mysql
mysql> SHOW VARIABLES LIKE 'wait_timeout';
mysql> SHOW GLOBAL VARIABLES LIKE 'wait_timeout';
mysql> SHOW GLOBAL VARIABLES LIKE 'interactive_timeout';

daje odpowiednio wartości:

wait_timeout 28800
wait_timeout 60
interactive_timeout 28800

Natomiast wywołane w postaci skryptu:

#!/bin/sh
mysql -e "SHOW VARIABLES LIKE 'wait_timeout';"
mysql -e "SHOW GLOBAL VARIABLES LIKE 'wait_timeout';"
mysql -e "SHOW GLOBAL VARIABLES LIKE 'interactive_timeout';"

da już inny wynik:

wait_timeout 60
wait_timeout 60
interactive_timeout 28800

… to samo, z użyciem np. Pythona (MySQLdb):

tlhscd@arsenic:~ $ ./test.py
('wait_timeout', '60')
('wait_timeout', '60')
('interactive_timeout', '28800')

 

Jeżeli nie możemy zmienić globalnej wartości, zawsze można ustawiać ją na poziomie sesji, zaraz po ustanowieniu połączenia, na przykład:

SET SESSION wait_timeout=300;

… i jak widać, działa:

tlhscd@arsenic:~ $ ./test.py
('wait_timeout', '300')
('wait_timeout', '60')
('interactive_timeout', '28800')

Tags:

Leave a Reply

Your email address will not be published. Required fields are marked *

Rozwiąż równanie: * Time limit is exhausted. Please reload CAPTCHA.