您的位置: 首页  >  技术问答  >  mysql服务器消失了（错误＃2006）

mysql服务器消失了（错误＃2006）

分类: 技术问答 • 2022-04-17 21:08:29

mysql服务器消失了（错误＃2006）

问题描述：

在Apache 2.2.9/Debian上使用wsgi运行Django 1.3，并使用mysql 5.0.51a在部署的django安装和我们的两个开发服务器中都遇到了以下问题运行，使用2个数据库。mysql服务器消失了（错误＃2006）

对于每个用户，某个功能导致了一个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  [email protected] 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日志看起来很正常。在我发布的内容之前，我已经查看过了，但我没有认出任何奇怪的东西，但是我没有每天阅读它们。 使用root用户以及不同的用户在本地登录到mysql-sever并没有任何问题。我期望能够做的所有事情都能做到。我没有尝试任何用户www-data，因为我坦率地不知道如何登录。另外，django使用另一个用户名登录到mysql服务器。

重新启动mysql服务器，没有结果。重新启动apache2和django开发服务器以及mysql-server，没有结果。半小时后，一切都很好..

我意识到我给你几乎没有什么可以继续下去。我想发布更多，但正如我所提到的，我关闭了Django错误页面。而且我不能重现这个有点令人恐惧的错误。这个错误至少持续了一刻钟，但也许是四分之三个小时。然后，每件事都再次奏效，我不知道为什么。对于我的未经训练的眼睛，没有线索，当时在apache2和数据库中发生了什么变化..

哦，是啊我google了这个，找到了一些关于wait_timeout，发现它的值可能足够高（默认） ，而且只有在MySQL闲聊之后才会离开，而且在刷新页面之后一切都很好。

任何人都可以帮助我为什么发生这种情况，以及如何防止这个2006年的错误？

答

因此，在各个网站，我发现当连接长时间打开时会发生此错误。我忽略了这一点，因为我认为这不适用于我的情况。经过深思熟虑之后，我重写了代码，以便在发生此错误时自动重新连接，然后重试，但感觉不到对。然后我发现我的代码确实长时间保持开放连接，而本身并不是必需的。我用于数据库访问的对象在各个模块级别实例化，所以我猜想它们只有在重新启动apache时才创建。难怪几天之后连接就开始了......

所以现在我只在需要它们的函数中创建数据库对象，并且因为错误2006而没有问题：D。问题发生在椅子和键盘之间......

相关推荐