MySQL сервер ушел (ошибка № 2006) - PullRequest
Новая
       11

MySQL сервер ушел (ошибка № 2006)

2 голосов
/ 02 февраля 2012

Запуск Django 1.3 через wsgi на apache 2.2.9 / Debian и использование mysql 5.0.51a я столкнулся со следующей проблемой, как в развернутой установке django, так и на обоих серверах разработки, на которых мы работали, используя 2 базы данных.

Для каждого пользователя определенная функция приводила к 2006: сервер пропал ошибка. Следующая за последней функция, вызываемая до того, как что-то пойдет не так, находится в потоке, например: 

 t = threading.Thread(target = logic.report,
                     args = [proj_info, userdata]
                     )
 t.setDaemon(True)
 t.start()

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

Ошибка, которую возвратил Django (через браузер и, конечно, я забыл оставить эту вкладку открытой для дополнительной информации), указала на что-то, происходящее в 14:15:18, так что вот какой-то mysql.log 

120202 14:15:18    3449 Connect     beta@localhost on beta2db
           3449 Query       SET NAMES utf8
           3449 Query       set autocommit=0
           3449 Query       SELECT `auth_user`.`id`, `auth_user`.`username`, `auth_user`.`first_name`, `auth_user`.`last_name`, `auth_user`.`email`, `auth_user`.`password`, `auth_user`.`is_staff`, `auth_user`.`is_active`, `auth_user`.`is_superuser`, `auth_user`.`last_login`, `auth_user`.`date_joined` FROM `auth_user` WHERE `auth_user`.`id` = 3
           3449 Query       SELECT `insight_test_run`.`id`, `insight_test_run`.`rawfile`, `insight_test_run`.`koekfile`, `insight_test_run`.`measure_date`, `insight_test_run`.`test_id`, `insight_test_run`.`subject_id`, `insight_test_run`.`quality` FROM `insight_test_run` WHERE `insight_test_run`.`id` = 514
           3449 Query       SELECT `insight_project`.`id`, `insight_project`.`client`, `insight_project`.`description`, `insight_project`.`directory` FROM `insight_project` INNER JOIN `insight_project_test_run` ON (`insight_project`.`id` = `insight_project_test_run`.`project_id`) WHERE `insight_project_test_run`.`test_run_id` = 514
           3449 Query       SELECT `auth_user`.`id`, `auth_user`.`username`, `auth_user`.`first_name`, `auth_user`.`last_name`, `auth_user`.`email`, `auth_user`.`password`, `auth_user`.`is_staff`, `auth_user`.`is_active`, `auth_user`.`is_superuser`, `auth_user`.`last_login`, `auth_user`.`date_joined` FROM `auth_user` INNER JOIN `insight_project_user` ON (`auth_user`.`id` = `insight_project_user`.`user_id`) WHERE `insight_project_user`.`project_id` = 6
           3449 Query       SELECT `django_content_type`.`app_label`, `auth_permission`.`codename` FROM `auth_permission` INNER JOIN `auth_group_permissions` ON (`auth_permission`.`id` = `auth_group_permissions`.`permission_id`) INNER JOIN `auth_group` ON (`auth_group_permissions`.`group_id` = `auth_group`.`id`) INNER JOIN `auth_user_groups` ON (`auth_group`.`id` = `auth_user_groups`.`group_id`) INNER JOIN `django_content_type` ON (`auth_permission`.`content_type_id` = `django_content_type`.`id`) WHERE `auth_user_groups`.`user_id` = 3
           3449 Query       rollback
           3449 Query       SELECT `insight_subject`.`id`, `insight_subject`.`name`, `insight_subject`.`nice_name`, `insight_subject`.`handedness`, `insight_subject`.`birthday`, `insight_subject`.`gender`, `insight_subject`.`education`, `insight_subject`.`eyecorrection`, `insight_subject`.`extra` FROM `insight_subject` WHERE `insight_subject`.`id` = 10000456
           3449 Query       SELECT `insight_test`.`id`, `insight_test`.`description`, `insight_test`.`level_id`, `insight_test`.`name` FROM `insight_test` WHERE `insight_test`.`id` = 1
           3449 Query       SELECT `insight_test_level`.`id`, `insight_test_level`.`description`, `insight_test_level`.`official_name` FROM `insight_test_level` WHERE `insight_test_level`.`id` = 1
           3449 Quit

Вот немного журнала apache (/var/log/apache2/error.log):

[Thu Feb 02 14:17:00 2012] [error] Exception in thread Thread-2:
[Thu Feb 02 14:17:00 2012] [error] Traceback (most recent call last):
[Thu Feb 02 14:17:00 2012] [error]   File "/usr/local/lib/python2.7/threading.py", line 530, in __bootstrap_inner
[Thu Feb 02 14:17:00 2012] [error]     self.run()
[Thu Feb 02 14:17:00 2012] [error]   File "/usr/local/lib/python2.7/threading.py", line 483, in run
[Thu Feb 02 14:17:00 2012] [error]     self.__target(*self.__args, **self.__kwargs)
[Thu Feb 02 14:17:00 2012] [error]   File "/usr/local/www/wsgi-scripts/portal/ovl_webinterface/insight/logic.py", line 50, in report
[Thu Feb 02 14:17:00 2012] [error]     reportfile = ovl.report.make_report(django_test_run_id = j, img = trunfo['img'], text_style = trunfo['style'], anonymous = anon)
[Thu Feb 02 14:17:00 2012] [error]   File "/usr/local/lib/python2.7/site-packages/ovl_analystT/reporting.py", line 90, in make_report
[Thu Feb 02 14:17:00 2012] [error]     info = dbman.gather_all_test_run_info(django_test_run_id = django_test_run_id)
[Thu Feb 02 14:17:00 2012] [error]   File "/usr/local/lib/python2.7/site-packages/ovl_analystT/dbconnector.py", line 802, in gather_all_test_run_info
[Thu Feb 02 14:17:00 2012] [error]     test_run = self.get_table_rows2(table = 'test_run', convert_to_one = True, django_id = django_test_run_id)
[Thu Feb 02 14:17:00 2012] [error]   File "/usr/local/lib/python2.7/site-packages/warehouseT/manager.py", line 213, in get_table_rows2
[Thu Feb 02 14:17:00 2012] [error]     cols = kwargs.pop('columns',self.get_table_column_names(table))#if columns are specified (using keyword 'columns') it only loads those.
[Thu Feb 02 14:17:00 2012] [error]   File "/usr/local/lib/python2.7/site-packages/warehouseT/manager.py", line 116, in get_table_column_names
[Thu Feb 02 14:17:00 2012] [error]     res = self.execute('''DESCRIBE %s'''%(table))#this function is so basic.. it should present no trouble, so no debug stuff.
[Thu Feb 02 14:17:00 2012] [error]   File "/usr/local/lib/python2.7/site-packages/warehouseT/manager.py", line 91, in execute
[Thu Feb 02 14:17:00 2012] [error]     self.cursor.execute(cmd)#this may raise warnings which we need to catch
[Thu Feb 02 14:17:00 2012] [error]   File "build/bdist.linux-x86_64/egg/MySQLdb/cursors.py", line 174, in execute
[Thu Feb 02 14:17:00 2012] [error]     self.errorhandler(self, exc, value)
[Thu Feb 02 14:17:00 2012] [error]   File "build/bdist.linux-x86_64/egg/MySQLdb/connections.py", line 36, in defaulterrorhandler
[Thu Feb 02 14:17:00 2012] [error]     raise errorclass, errorvalue
[Thu Feb 02 14:17:00 2012] [error] OperationalError: (2006, 'MySQL server has gone away')

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

Так что, по сути, это ошибка в моем собственном фрагменте кода (который снова работал много и много раз без сбоев), который останавливается mysql.

Я думаю, что журнал mysql выглядит нормально. Я просматривал строки перед теми, которые я публикую, но я не узнал ничего странного, но я не читаю их каждый день. Локальный вход в MySQL-сервер с использованием пользователя root, а также разных пользователей не представляет никакой проблемы. Все, что я ожидал, я смог сделать. Я не пробовал ничего как пользователь www-data, так как, честно говоря, не знаю, как войти в систему. Кроме того, django использует другое имя пользователя для входа на mysql-сервер.

Перезапуск mysql-сервера, безрезультатно. Перезапуск сервера разработки apache2 и django, а также сервера mysql, безрезультатно. Через полчаса все было хорошо ..

Я понимаю, что почти ничего не даю вам. Я хотел бы опубликовать еще немного, но, как я уже упоминал, я закрыл страницу с ошибкой Django. И я не могу воспроизвести эту ошибку, которая немного пугает. Эта ошибка происходила последовательно не менее четверти часа, но, возможно, три четверти часа. Потом все снова заработало, и я не знаю почему. На мой неопытный взгляд, я не знаю, что изменилось за это время, как в apache2, так и в базе данных.

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

Может кто-нибудь помочь мне с объяснением, почему это произошло и что нужно сделать, чтобы защититься от этой ошибки 2006 года?

1 Ответ

2 голосов
/ 08 марта 2012

Так что на разных сайтах я обнаружил, что эта ошибка возникает, когда соединение открыто в течение длительного времени.Я проигнорировал это, потому что думал, что это не применимо к моей ситуации.После долгих размышлений я переписал код для автоматического повторного подключения при возникновении этой ошибки, а затем повторил попытку, но он не чувствовал себя правильным .Затем я обнаружил, что мой код действительно сохранял открытое соединение в течение длительного времени, без необходимости как такового.Объекты, которые я использовал для доступа к базе данных, были созданы на разных уровнях модулей, поэтому я думаю, что они были созданы только после перезапуска apache.Неудивительно, что соединение прошло несколько дней спустя ..

Итак, теперь я создаю объекты базы данных только внутри функций, которые в них нуждаются, и с 2006 года у меня не было проблем с ошибкой: D.Проблема была между стулом и клавиатурой все время ..

...