MySQL server has gone away

MySQL server has gone away is not a Drupal issue. Read on at:
http://dev.mysql.com/doc/refman/5.0/en/gone-away.html

Deleted? It is here. We cannot do anything about this, because if you get "MySQL goes away" it is not a Drupal issue. Read on at the link I provided. No Drupal bug here.

Retitling. I still have the same opinion that this is not a Drupal issue, but this better title will at least allow others to come around and comment.

Cellarstudios: As Gabor previously mentioned, the page at http://dev.mysql.com/doc/refman/5.0/en/gone-away.html has a long list of debugging options and possible causes. I believe that I have seen other issues or forum posts on drupal.org that mentioned this error in relation to the max_allowed_packet variable, discussed in bullet #7 on the page. You might try increasing that setting as described here: http://dev.mysql.com/doc/refman/5.0/en/packet-too-large.html.

Cellarstudios: I'm not sure what the solution is either, but I'm thinking its not likely to be a general bug in Drupal since this problem does not occur systematically with other hosting providers. I did a google search for "godaddy server has gone away site:drupal.org" and there are several posts that may be related to your issue. I didn't scan through them though.

The same "MySQL server has gone away" error appears while updating feeds that have a long loading time with feed aggregator module. Please see: http://drupal.org/node/203326#comment-746922 and followups.

I'm not on godaddy, so that's not a godaddy specific issue.

The error in my case is that a function in drupal runs too long (or rather a feed, that has a long loading time). While loading this feed, the MySQL server closes the connection due to a connection time-out serverside set to 20s. After loading the feed, the aggregator module tries to update the database. This ends in lots of theses "MySQL server has gone away" errors.

Would be interesting to know if in Cellarstudios' case it's a time-out too or something else.

I found a workaround adding "mysqli.reconnect = On" to php.ini, but in my opinion that's not the way it should be solved.
In case of a time-out drupal should just reconnect to the database itself.

I have very similar problems - most of those seem to be related to Update Status module - as turning it off seems to get rid off those.
Didn't have problems with 5.x and contrib Update Status module.

And I wouldn't say it's Godaddy related problem as my projects aren't hosted there.. But anyway - I can't access .ini files either.

I think there are maybe two problems, which result in the same error:

Timeout (in my case): There I think it's a general problem of the drupal database connection handling. This error occurs as soon as a function runs longer than the db connection timeout setting (this may vary from host to host) without db interactions and the host turned of auto-reconnect. This can happen in every module. The solution could be a manual reconnect of the drupal db hanlder or where possible to set auto-reconnect in php.ini.

Large Queries: I'm not sure if this happens. But there may be too large queries by some drupal modules which exceed the query-size limit.

this problem is not just about 6.0. from a few days hunting, I find it appears just about anywhere.

I suggest anyone with this problem should first check with your webhost about wait_timeout setting for mysql. My webhost set it to 3 seconds at first! Now they have changed it to 8 seconds and my little drupal is ok!even with update status on!

In my case setting mysqli.reconnect = On in php.ini helped.

I get the same warning messages with Drupal 5.7 installation, when I want to go into any admin page...

I was connecting with the host (Imhosted), and they tweaked the settings, but the warnings remained...

then they changed the php version back to 4.4.8 and all was working fine...

now they updated again to PHP 5.2.5 and the warnings appear again...

but every thing works even this warnings appear...

due I have no glue about code or programming, I dont know if this is a PHP problem or a MySQL problem...

My host set the PHP back to 4.4.8 and all is working fine again...

so I guess that this problem is about PHP 5.2.5

See also :
MySql : "Warning: MySQL server has gone away" - Tune MySql to resolve this problem

FYI

I have my drupal site hosted on HostICan (www.hostican.com) hosting provider (aka HIC). HIC Team refused to change the parameter of mysql 'max_allowed_package' to increase the buffer size between Drupal and MySQL in a shared environment. They forced me to upgrade to a Virtual Private Server hosting package to allow this config modification.

To let you figure out my drupal site resources usage and help you decide which hosting package you will need to hire when using Drupal on HostICan read the following:

- My site has less than 100 registered users.
- My site has never had more than 15 concurrent users.
- My site AWStats say that from June the 1st to June 26th we've had an average of 141 visits per day with a bandwidth consumption of 160MB per day.

Clearly, in my honest opinion, this is a real little Drupal installation. Therefore we can conclude that HostICan is not prepared to host Drupal sites on their Base Hosting package, be careful.

HostICan has a good system technologies environment, but be carefull if you are trying to mount a "real" drupal site on their hosting. If you hire a Base hosting, you will only be able to "play" with drupal...

Regards

P.s: This post is not to make any preasure on HostICan team nor being dissuasive with new HIC users. My only intention is to inform all of you about what you will need to hire if you plan to build a Drupal site on HIC.

Deleted.

Hi everyone,
I've try all of the above solution for Drupal 6.4 . Seems the problem related to "Update status" module . I'm not yet investigating the code but after I disable this module all of the problem seems gone. I've check my Drupal 5.7 and it didn't have the "Update status" module.

Can someone from the developer side check this problem.

Same problem here, with 6.4.
It seems that it´s about the update module, you´re right!

THANKS!

i also have the same problem with 6.4, and it does seem to be the update status module, my host has increased the max_allowed_packet too to 64 MB and increased the wait_timeout to 60 seconds, any idea how to fix this?

Same problem here.

The problem with "Update Status" module if cron not setup, it will check with Drupal.org website everytime the admin interface is loaded to check wether a new version of Drupal is present. I think this need to be quickly rectify or just disable by default installation.

I've been noticing this recently. I'm on SiteGround. The php_errorlog they dump in my account has been growing large (over 100M!) and my Drupal 6.4 site isn't even live yet (only I have been accessing it). The log is filled with "INSERT into watchdog table" queries. Sometimes the mysql errors show up during a page render. Since I'm on a hosted account I suspect I'll have difficulty getting max_allowed_packet changed, although SiteGround offers to set up your Drupal site so this means they should be held accountable for smooth Drupal operation.

max_allowed_packet is 8M
wait_timeout is 10 seconds

I've turned off the Database logging module for now. I'll try the mysqli.reconnect = On php.ini trick from comment #15 first...

This may also help some people: http://www.phpbuilder.com/board/showthread.php?t=10325179

"So, one problem I was getting using mysqli OO was "Error: MySQL server has gone away". I fixed this by enabling the option in the PHP-CLI php.ini to mysqli.reconnect = On. I've also adjusted my my.cnf file to handle bigger datasets. So the file runs, but takes upto 53-54 seconds to run. I think this is due to a timeout and then reconnection. I can't see why PEAR::DB would be faster than OO mysqli."

I wonder if switching from mysqli to mysql in settings.php would help.

Here's SiteGround's response on the error:

http://kb.siteground.com/article/I_get_MySQL_server_has_gone_away_error_...

This error usually shows when your application tries to execute slow and heavy MySQL queries.

Since our servers are optimized for best security while maintaining top overall performance for all websites hosted on them, our MySQL server limits such queries to prevent server overloads.

If you are on a shared server, the best solution would be to optimize your database for the queries which fail.

Alternatively, you can upgrade your account to a VPS or a dedicated server, where the MySQL server settings can be changed according to your website's requirements.

After adding mysqli.reconnect = On to php.ini, the MySQL errors have stoppd. But every once in awhile I get a White Screen of Death with no indication as to why (nothing in the error log). So I've switched to using mysql instead of mysqli just to see how things go.

I got the error using the mysql driver. But I've also found this:
http://forum.siteground.com/showpost.php?p=21378&postcount=2

Yea, this error was intermittent for me. You can check phpMyAdmin to see when your mysql server was last started. Perhaps it is getting restarted under you too.

I'm setting this to fixed since the original issue was fixed a while ago.

- Arie

FWIW

I am using siteground for two sites and I get the error when update status module is enabled. Switch update status off and the problem goes away. I am using poormanscron.

I was having this issue today in a client server where i had no control nor chance to get the hosting co (a very poor one) to change MySQL settings in a able time, so i figure the following solution:

1 - My main error was related to the cache_update table, with has a BLOB field 'data'... The insert there was taking way longer then the webserver could handle. Only thing i had to use was PhpMyAdmin access, so ....

2 - i Copied the query from the drupal screen:

UPDATE `cache_update` SET `cid` = 'update_project_data',`data` = 0x613a31363a7b733a31333a22616476616e6365645f6865 ...... 313b7d7d,`expire` = 1229625774,`created` = 1229622174,`headers` = '',`serialized` = 1 WHERE  `cache_update`.`cid` = 'update_project_data';

and paste it in a text document. Saved as query.sql

3 - created in the webserver cache_update a row with the values
cid = 'update_project_data'
created = 0,
headers = '',
serialized = 1,
data = NULL
4 - Run the query in the .sql file from the Import option in the phpmyadmin
5 - tada! the error msgs were gone!

Hope this helps, cause i spend some 3 hours struggling with this!

Beer time now!

I just had this problem. It was struggling with 'SELECT * FROM variable' so I hacked the database include file to return FALSE when it was trying to do that query, so it wouldn't get stuck on it.

That let the other queries execute properly, and then I restored the original file.

What a pain!

update_status off - all works fine :)

I seem to have solved it for myself. In a recent MySQL upgrade my host set MySQL's wait_timeout value to 15 to save connections (the default was 28800), and that was causing "MySQL server gone away" errors.

Actually the host's tech support pointed me in the direction of wait_timeout, advising me to "close my MySQL sessions properly", whatever that means.

I had to do a little core hack in the db_connect() functions to change the value at the session (http://drupal.org/node/259580#comment-1511512)

If you can test it and I am right, I wonder if a variable can be added in settings.php for this.

I am reopening this expecting some feedback regarding my last suggestion. I am leaving it to 6.x for now since this is about getting feedback.

Ack, I disable the Update Status module, as well as SysLog, and I still get the same error when trying to run my Mailhandler scripts.

Before closing this, I would expect a comment on #37 and #38 where I reopened it. Not as a courtesy. We are trying to communicate here.

My claim was that Drupal has a problem on some shared hosts which can possibly be fixed.

I have this problem too. It only manifested for me with a recent upgrade to 6.10 from 6.9. I'm about to apply the 6.11 update now.

I've tried all the published "fixes" none of which help at all. I run my own servers and have complete control. My drupal sites work just fine. ONLY /admin presents any problems. Otherwise all sites hosted on these servers are fast and responsive.

Any other ideas to try?

no change with 6.11 update

i am new to drupal. i have 2 sites running using the same code. 1 site is getting this message, the other one is not.

i believe that my problem is related to the content templates module as the site that has the problem has that enabled, and the site that does not have the problem does not have it enabled.

as i would like to test this hypothesis, i would need to turn off this module, but i can not get to the drupal admin page on the site, as i get the mySQL server has gone away error.

is there a file in the database that stores the modules and which ones are on and which ones are off?

while i would love an answer to that question, i did remove the module completely and that did solve my problem.

is there a file in the database that stores the modules and which ones are on and which ones are off?

The system table in the database contains all the modules and their status (1 for on, 0 for off)

Have you tried the solution in post #37 ?

I understand that you guys are looking for solutions.

But without your feedback about the suggested solutions and whether they work or not, this will most likely be labeled "a hosting issue" and will be closed.

sorry about the delay in getting back to these comments. i need to check this page more frequently or figure out my settings so that i get an email generated. but alas, i digress...

danielb, thanks for the answer to the module question.

i have noticed that this problem has resurfaced again. i do not believe that it is now the content template although i do need to look at that a bit closer. i have also read the comments listed in post 37. i have not tried that, but i will. i will also contact my host to see if they have any feedback on this problem.

i will keep you posted on what i find out. it may be a week as i have some other issues to tend to next week. thanks again.

okay. right now it looks like the solution provided in #37 worked for me. thank you! i will post if this problem comes up again.
best.

subscribing

I am receiving the same errors as well and I don't use a shared host.

I just use a laptop I use for development. The laptop has Microsoft Vista Ultimate 64bit, 4 gig ram, and 2 350gb hard drives and I use Wamp with the latest versions of Apache, MySql, and Php. I am using Drupal version 6.12 and about 120 modules all updated to the latest versions. I have disabled all logging and updating modules and I have modified my php.ini and my.ini files as lisited above and I still get the same errors.

I have the site on the 5.8 version using the exact same modules and I have the logging and update modules enabled and I do not get any errors with the v5.x setup.

There is definitely something in the v6.x code that is doing it.

I am trying to move an existing non Drupal site to v6.x. since it offers greater possibilities over v5.x.

I am not very knowledgeable in php, mysql or apache and I am stuck with these errors. I need the modules I have plus about fifty more enabled for the site to run like the non drupal site as it is right now.

What do you mean "as listed above"?
What is your max_allowed_packet and your wait_timeout in my.ini?

You can install: http://drupal.org/project/db_tweaks
and you can try to increase your max_package_size and wait_timeout

This module is a very interesting solution, trying to set the variables with a hook_init. It doesn't seem to work yet on a shared host which has the problem (it tries to give empty values to all the variables, resulting in error messages).

But if it works, it beats what I was trying to do with a global in settings.php used in db_connect, and will solve this issue.

I apologize for my behavior and my tone, I know there is no excuse for that kind of behavior.

The I have been fiddling with the settings and still no luck. I forgot to add that the processor in the laptop is an AMD Turion 64x2, so I know it isn't the laptop resources. I fired up my old dev server from when I worked on .asp sites and I get the same errors on it with both the v5 (infrequent and random) and v6 sites.

The error arises when I try to save any page from editing, adding content, changing default settings and such. I don't get the error(s) when I add modules or a theme, if that helps. All code in the core, extra modules and themes are unmodified.

The settings right now are max_allowed_packet = 8m and the wait_timeout = 60.

I have had to increase the php.ini settings below as well, due to the timing out of MySql while setting up a clean install of the 6.x versions.

max_execution_time = 180
max_input_time = 180
memory_limit = 256M

I am not familiar with Php, MySql, or Apache, I have just recently converted from .asp and .aspx coding. I have a difficult time debugging the errors I get. I like working with Drupal due to the ease of installation of the core package and all the modules. I like how easy it is to add functions, themes and product (or fluff as I like to call it)to a website. I don't want to downgrade to v5.x of the code since v6.x is much easier to configure the menus and such to the customer needs. I really need to get this error figured out and hard coded since I don't trust the customer with leaving things like the db_tweaks settings alone. If the customer where to have an issue, they like to reset the server to original and then reinstall all the software, and then apply backups. This as opposed to just asking for help in resolving an error or two. I have been there before with them, and regrettably will end up fixing things in the future for them (they are family and I can't just tell them to get someone else).

Nothing wrong with your tone. However a general server configuration question is unlikely to be answered here.

Obviously the "tweaks" module is for people who don't have access to their server configuration. Try max_allowed_packet = 24M and maybe wait_timeout = 90 for MySQL.

I have this same problem on 1&1 shared Linux hosting. I'm going to try a few solutions (including the proposed one) and post back here.
Unfortunately I can't try the tweaks module as I can't access my site at all!
Anyhow, here goes!

swiftarrow: remove data from your cache and sessions and check if it will help.
If you have wsod and can't access your website, you can try: http://drupal.org/project/dtools
It could rebuild and clear caches for you if there is any problem, without installing it.

Hi all, my problems were resolved quite painlessly, so I dont know if this is really an issue with core code.
I'm using Drupal 6.12 and about 20 contrib modules, with 1&1's Shared Linux Hosting.

I got "Server gone away" errors when I transferred my site from XAMPP to 1&1. I couldn't even get into the site.

Here's my solution:
create a file called php.ini in the drupal root, with the following:
mysqli.reconnect = On
memory_limit=32M

Note that 32M is not needed, 24 or sometimes 16 should work just fine.
The reconnect directive solves the Database issue. The memory limit gives drupal more space.

Now other problems, such as clean urls, etc, were still preventing me from accessing my site. This is usually 1&1 specific, but i'm putting it here just for similarly afflicted people!
In .htaccess, add the line:
AddType x-mapp-php5 .php

and uncomment
RewriteBase /

Finally make your domain name point to the site root.

voila! And Good Luck!

cog.rusty code worked perfectly for me. I guess Drupal and Drupal module developers should pay more attention to MySQL/PHP errors coming from sharing hosting limitations, as most people use shared hosting for their websites.

The Drupal core settings may include some tweaks like the increasing wait_timeout (cog.rusty's method) etc. It would be nice and will save the day for many people :)) It maybe something like "Advanced settings" or "MySQL settings" or "Hosting limitations tweaks" etc..

I am not sure if I've got this right, but I think that a database connection is made with each page load, and if the queries in a page are many and spread apart in time (for example because of looking for updates) the db connection can be lost. An optional $db_session_wait_timeout global in settings.php might help.

By the way, the shared host where I first encountered the problem has fixed it since, by changing the server's wait_timeout to a more reasonable value. I guess their wait_timeout=15 setting was pathologically low.

You've got lucky. My hosting provider told me, that their setting is even more drastic, wait_timeout=10. They explained it with alot of bad behavior from unprofessional and misconfigured websites, which they can't fight. So they simply solve their DB server's problems radically.
I tried to convince them, that this isn't the right decision, but with no success.
At least I was able to fix it for myself using your way and I'm very thankful, indeed.

I'm at Site5 and what appears to be is their firewall rules preventing communication with certain domains/urls. In my case it is the sitemap submissions to Ask.com (http://submissions.ask.com/).

After unchecked Ask.com in the XML Sitemap module all worked fine.

Now, this may not actually be Site5 fault so much. Perhaps the XML Sitemap module is doing something which makes it hang up on trying to get response from Ask.com?

Given that this issue is well-documented, and a workaround exists (the db_tweaks module), I'm re-closing this issue.

Regarding #38: I don't think core is the right place for workarounds for poorly configured servers. There are many affordable hosts that work well with Drupal, see https://drupal.org/hosting-support

Wait, but is there any answear to this issue?

I have the same problem, but not sure this is hosting provider... Mysql query my last 30 sec in my case... And I'm over just going to admin/ page!
This not happends on my localhost, however on localhost admin/ page loads just 2 seconds...
What is reallt wrong? I have to equall setings on localhost and on online server...

Now I turned off "update status" core module, and this stopped showing... However few hours ago this module was on and there was no such error...
I just found some tip that server online may somehow block the update status working and that's way there is mysql query working so long...

In my case the setting on comment #15 helped too. Thank you!

It did for me, too. But i had to turn off updates anyway. But now cron is capable to run, at least.

Subscribing

We are curing symptoms here.
I think the real problem is that we have too big SQL requests, that would better be chunked. In case of cache_update, this also means that the data should better be chunked in separate table rows (one for each module could do the trick).

I get the error on the modules pages, with a db_query called from _update_cache_set, doing an "UPDATE cache_update ...", with a very long value.

This can be avoided with a good server configuration, but I very much think that Drupal should aim to run without unnecessary server requirements.

Had similar messages after trying to import the pictures:
Warning: MySQL server has gone away query: INSERT INTO watchdog...
Aside changing other my.ini settings I set max_allowed_packet = 2M from 1M and that solved my problem.

I still experience these issues even when I have full control of mysql and php. This is usually while running cron.php which locks cron.php for a few hours (will report failed trying to run again). Eventually it does run without the mysql gone away message.

Hosting at ANhosting with a Cpanel configuration. I ran through a couple posted solutions and ultimately disabling the UPDATE STATUS module is what worked for me.

Same here.

With Update status disable the problem is solved!

Thanks melon - This page (#comment-770663)

I was getting a hundreds of these babies...

Warning: MySQL server has gone away query: INSERT INTO watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) etc, etc, etc... ....

It was only occurring when Update Status module was enabled. Adding that line to my php.ini file has sorted that issue out. Thanks for that. :)

Subscribe

FYI-- I checked out http://dev.mysql.com/doc/refman/5.0/en/gone-away.html
Some good tips.

The thing that fixed it for me was to change my max_allowed_packet to some high number-- currently set to 32M. I'm sure this would require some tuning and to be set as low as possible for a production environment, but since this is just on my dev box, I just need it to work.

hope this helps others of you facing this issue.

Making my web host increase the wait_timeout fixed this for me. It was set to 20 and it was way to low for Drush.

it works using mysqli.reconnect = On. thanks!

It seems an obvious question to me - how can you switch off the Update Status module when you can't access the website?

Willem

OK - worked that out - thru PHPmyadmin! Phew - at least my website is now back on deck!

Willem

A few weeks ago, my provider's server had a problem and we lost about 2 weeks of data. Cron had not run since. I contacted Support and we went back and forth for about a week. I believe something changed on the provider's end and the original command would not run cron any longer. I also updated some modules shortly after the incident. I finally decided to try a completely different command and now sometimes cron will run and sometimes not.

This is the new command:
0 */3 * * * /usr/bin/wget -O - -q -t 1 http://myWebsite.org/cron.php

Now I'm getting ALOT of these error messages - MySQL server has gone away query: INSERT INTO watchdog...(and on and on and on)...

I have tried many different solutions from the above posts and the Internet, but so far none have worked, including alternating these variables on php.ini:

mysqli.reconnect = On;
max_execution_time = 120; // (default 30)
max_input_time = 120; // (default 60)
mysql.connect_timeout = 120; // (default 30)
default_socket_timeout = 300 // (default 60) - Note: haven't tried this yet

wait_timeout = 200; // (default 28800 - Our server setting is 10) This has to be changed on my.cnf to which I do not have access

max_allowed_packet = 32M; // (Max, 1G - Our server setting is 2MB) This has to be changed on my.cnf to which I do not have access

I also disabled my Update Status module to no avail. Now my provider, AN Hosting, has basically told me they will not help any more and have referred me to a web design team--haha! So, what to do?!? I'm being driven insane!

UPDATE March 21, 2011
I found a hack and hacked Drupal 6.20 core which I realize is not ideal. No more problems! Below is the code:

I pasted the hack code above "return $connection;"

In includes/database.mysql.inc, at the end of function db_connect(), under the "SET NAMES" line and above "return $connection;" add:

mysql_query('SET SESSION wait_timeout = 60', $connection);

In includes/database.mysqli.inc, at the end of function db_connect(), under the "SET NAMES" line and above "return $connection;" add:

mysqli_query($connection, 'SET SESSION wait_timeout = 60');

Thanks @grendzy! I will also check out Drupal tweaks.

I believe wait_timeout needs to be set in my.cnf. If you host is unwilling to adjust this value you can try the http://drupal.org/project/drupal_tweaks module.

I recently tried to download a live site and work on a local copy of it. I struggled with this for ages and eventually got it working by changing the following default my.ini setting on a Windows 7 XAMPP configuration :-

#max_allowed_packet = 1M
max_allowed_packet = 32M

Thanks to #76 - craigmc.

Problem solved by disable update status

This issue is too generic and it's mixed by different problems.
So there is general solution:

Please check Drupal Requirements:
http://drupal.org/requirements
Tuning MySQL:
http://drupal.org/node/51263

And other topics:
http://groups.drupal.org/node/13844

If the problem is with watchdog table, disable Syslog module.
If the problem is with cache_menu table, disable Admin Menu module or different menu related modules which you don't use.
If the problem is with cache tables:
- try to disable cache,
- install memcache or different cache methods (like: fastpath_fscache - not recommended)
If you are using Update Status module, follow this issue: #214626: Update Status: MySQL server has gone away query, or raise the new one there.
If it's related to specified module, raise a new one for specified module.

If you are using HeartInternet or GoDaddy, or any other, where MySQL packet limit is 1M:
- check with your provider if you can create my.ini or my.cfg to override you MySQL account settings,
- buy dedicated server,
- change your hosting,
Eventually you can try Drupal Tweaks module to tune some MySQL settings, if you have proper permission on your hosting provider.

etc.